Peter Vessenes [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-01-17 to 2013-08-05
💬 Posted a total of 36 messages
📚 Participated in the following categories: Bitcoin-development, ANNOUNCE
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1ezg54d03a7unwu0fckmlugxulukrg06x7jzx4engngxfg79sfcqsn6r8pt

Profile Code

nprofile1qqsv3y22khc7lwfhw85utdl7yrw07tp58ar0fpr2ue5f5ry50zcyuqgpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgywtydp

Publishing to

relay.nostr.band

Author Public Key

npub1ezg54d03a7unwu0fckmlugxulukrg06x7jzx4engngxfg79sfcqsn6r8pt

Show more details

Last Notes

2023-06-07 15:05:32

- reply

📅 Original date posted:2013-08-05
📝 Original message:Interesting! I will refrain from digging into QC right now, per Alan's
suggestion. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130805/278b1525/attachment.html>

2023-06-07 15:05:30

- reply

📅 Original date posted:2013-08-05
📝 Original message:I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He
told me recently NTRU, which is lattice based, is one of the few (only?)
NIST-recommended QC-resistant algorithms.
We talked over layering on NTRU to Bitcoin last year when I was out that
way; I think such a thing could be done relatively easily from a crypto
standpoint. Of course, there are many, many more questions beyond just the
crypto.
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130804/fd39b084/attachment.html>

2023-06-07 15:04:15

- reply

📅 Original date posted:2013-07-16
📝 Original message:I'm at the Aspen Institute right now talking about Bitcoin and I mentioned
the perils of starting an alt-chain based on proof of work that pool
operators might attack; funny synchronicity!
Peter
On Mon, Jul 15, 2013 at 2:29 PM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jul 15, 2013 at 03:05:52PM +0200, Jorge Timón wrote:
> > One way sacrifice (btc to zerocoin) is a non-issue since there's no
> > modification required for bitcoin and you can't do anything to prevent
> > it anyway.
> > The controversial thing is sacrificing something outside bitcoin's
> > chain and new btc appearing.
>
> Which is why I'm not proposing that.
>
> > On merged mining. It is true that "merged attacking" the other chain
> > is free, but it is still more profitable to just follow the rules and
> > mine the other coin!!
> > If someone considers that something he can sell in a market for btc is
> > "negative value"...well, he's just dammed stupid. Proof of work is
> > designed for rational actors, if you stop assuming miners are more or
> > less rational everything falls apart. It is possible that the "extra
> > value" is too little for some miners to bother. But the extra costs of
> > validating something else are so little compared to chance-hashing
> > that miners not merged mining namecoin right now are just stupid
> > (irrational agents). You can merged mine and sell for btc right away.
>
> You are assuming value is the same for everyone - it's not.
>
> If I mine in a jurisdiction where zerocoin is banned, and the blocks I
> mine are public, the value of zerocoin blocks to me are at best zero.
> Equally it would be easy for the local authorities to ask that I merge
> mine zerocoin blocks to attack the chain - it doesn't cost me anything
> so what's the harm? I may even choose to do so to preserve the value of
> the coins I can mine legally - alt-coins are competition.
>
> Incedentally keep in mind it is likely that in the future pools will not
> allow miners to modify the work units they receive in any way as a means
> of combating block-withholding fraud; there may not be very many people
> willing or able to honestly merge-mine any given chain.
>
> Proof-of-sacrifice can be done in a way that is opaque to the master
> blockchain by creating txouts that look no different from any other
> txout. Hopefully not required, but it would be a good strategy against
> censorship of sacrifice-based chains.
>
> > On prime proof of work...for me it's interseting only because it's
> > moving towards SCIP-based mining but that should be the goal. Like
> > Mark said, "let's cure cancer" while mining. That would end all
> > "mining is wasteful" arguments about this great security system. This
> > would make Ripple's consensus mechanism less attractive. People
> > talking about new scrypts harder to ASIC-mine when that's the elephant
> > in the room...
> > Sorry, I'm going off-topic.
> > SCIP-based merged mining for the win.
>
> SCIP is for now a dream. Give it a few more years and see how the
> technology shakes out.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000582cc323897a582e9368a5c3dfbcdcf73e78b261703e1bd1ba
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130715/d32dcc9b/attachment.html>

2023-06-07 15:04:12

- reply

📅 Original date posted:2013-07-13
📝 Original message:One very real issue for alt-currencies that don't peg to Bitcoin is that
market liquidity is a bitch. By almost all standards current global Bitcoin
liquidity is already very, very low. Too low for many transactions that
come across my desk at least.
There are a lot of reasons for that low liquidity, but to try and float a
new pair for which the likely initial counter-asset is going to be Bitcoin
means minuscule liquidity.
Peter
On Sat, Jul 13, 2013 at 2:53 AM, Jorge Timón <jtimon at monetize.io> wrote:
> Sorry about that.
> Maybe more important, what's wrong with bitcoin and zerocoin being
> different currencies with an exchange rate completely decided by the
> market instead of trying to force 1:1 ???
>
>
> On 7/13/13, Jorge Timón <jtimon at monetize.io> wrote:
> > I'm not sure I understand the whole proposal, but it seems to me that
> > having different characteristics, bitcoins and zerocoins would be
> > different currencies.
> > I don't see the need to peg zerocoins to bitcoins.
> > It is great to have an anonymous p2p currency, maybe some bitcoin
> > users that use bitcoin because of the transparency they allow (public
> > funds expenditures could be more transparent than they have ever been)
> > don't like this hard-fork. Well, maybe this is not the main reason,
> > but I think this could be highly controversial.
> > Maybe everybody likes it, but can you expand more on the
> > justifications to peg the two currencies?
> > If you're requiring one chain look at the othe for validations (miners
> > will have to validate both to mine btc) you don't need the cross-chain
> > contract, you can do it better.
> >
> > Instead of doing this:
> >
> > https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
> >
> > You could do something like this:
> >
> > https://bitcointalk.org/index.php?topic=31643.0
> >
> > This very idea has been proposed recently by othe people, but I can't
> > find where.
> >
> > The problem with this is of course scalabilty. Once you do it for what
> > chain, why not the others?
> > You can't validate 100 chains to mine bitcoin even if they're all
> > merged mined: that's asking miners too much.
> > If zerocoin enjoys this privilege why not, for example?
> >
> > As some of you may know, Mark Friedenbach and I are working on a
> > protocol modification to support issuance of arbitrary assets. Would
> > be something like colored coins but better, we're calling it
> > FreiMarkets. Of course these assets are not p2p like bitcoin or
> > freicoin themselves: they have a centralized issuer.
> > But if you allowed to sacrifice real bitcoins (as opposed to IOUs
> > denominated in BTC like you have, for example, in ripple) so they
> > appear in Freicoin's chain and turn them back, you could have p2p
> > bitcoins inside Freicoin's chain.
> > Maybe ripplers want that too. If FreiMarkets prove to work well on
> > freicoin and be scalable enough, maybe a lot of scamcoins apply the
> > hardfork too and they want to have p2p btc in their chain as well.
> >
> > Maybe I could have explained this without even mentioning FreiMarkets,
> > but my point is that you're asking for a lot like it was nothing.
> > Zerocoin-bitcoin fungibility hardfork is opening a little pandora's
> > box. Are we ready?
> >
> > I was waiting for others to comment and I'm surprised that no one else
> > has made any objection yet. But if no one's going to point out the
> > controvery that is so obvious to me, I feel almost like a
> > responsability to act like a Devil's advocate here.
> > So if you make bitcoin and zerocoin fungible, I want bitcoins to be
> > transferrable to freicoin's chain. And I warn you there will be many
> > more people asking for the same thing on other chains. What criteria
> > will we have to say yes or no?
> > More
> >
> >
> >
> > On 7/12/13, Peter Todd <pete at petertodd.org> wrote:
> >> On Fri, Jul 05, 2013 at 04:01:40PM +0200, Adam Back wrote:
> >>> Do people think that should work? It seems to me it should with
> >>> minimal,
> >>> bitcoin changes. I think the rule for either-or mining should be as
> >>> simple
> >>> as skipping the value / double-spend validation of the blocks that are
> >>> zerocoin mining blocks. Obviously zerocoin blocks can themselves end
> up
> >>> on
> >>> forks, that get resolved, but that fork resolution can perhaps be
> >>> shared?
> >>>
> >>> (Because the fork resolution is simply to accept the longest fork).
> >>
> >> Yeah, there's been a lot of doom and gloom about zerocoin that is
> >> frankly unwarrented. For instance people seem to think it's impossible
> >> to make a blockchain with zerocoin due to the long time it takes to
> >> verify transactions, about 1.5 seconds, and never realize that
> >> verification can be parallelized.
> >>
> >> Anyway the way to do it is to get out of the model of large blocks and
> >> think about individual transactions. Make each transaction into its own
> >> block, and have each transaction refer to the previous one in history.
> >> (zerocoin is inherently linear due to the anonymity)
> >>
> >> Verification does *not* need to be done by every node on every
> >> transaction. Make the act of creating a transaction cost something and
> >> include the previous state of the accumulator as part of a transaction.
> >> Participants verify some subset of all transactions, and should they
> >> find fraud they broadcast a proof. Optionally, but highly recomended,
> >> make it profitable to find fraud, being careful to ensure that it's
> >> never profitable to create fraud then find it yourself.
> >>
> >> Anyway Bitcoin is limited to 7tx/s average so even without probabalistic
> >> verification it'd be perfectly acceptable to just limit transactions to
> >> one every few seconds provided you keep your "blocksize" down to one
> >> transaction so the rate isn't bursty. You're going to want to be
> >> cautious about bandwidth requirements anyway to make sure participants
> >> can stay anonymous.
> >>
> >> As you suggest creating zerocoins from provably sacrificing bitcoins is
> >> the correct approach. The consensus algorithm should be that you
> >> sacrifice zerocoins (specifically fractions there-of - note how I'm
> >> assuming support for non-single-zerocoin amounts) and whatever chain has
> >> the highest total sacrifice wins. One way to think about
> >> proof-of-sacrifice is it's really proof-of-work, transferred. It also
> >> has the *big* advantage that to double-spend, or for that matter 51% the
> >> chain, you have to outspend everyone with a stake in the viability of
> >> the blockchain: they can sacrifice their zerocoins to combat you. In the
> >> case of a double-spend to rip off an online merchant the total amount
> >> you could profit is the same as the total amount they would rationally
> >> spend to stop you, and soon there will be collateral damage too
> >> increasing the amount third-parties are willing to sacrifice to stop
> >> you. You can't win.
> >>
> >> Of course, this does mean that even unsuccesful sacrifices need to be
> >> costly. You can make this acceptable to users by allowing a sacrifice to
> >> be reused, but only for the exact same transaction it was originally
> >> committed to.
> >>
> >> Sacrifices in this manner are *not* proof of stake. You really are
> >> giving up something by publishing the information that proves you made
> >> the sacrifice as that information can always be included in the
> >> consensus thereby taking away a limited resource. (your zerocoins) It's
> >> more heavily dependent on jam-free networks, and doesn't play nice with
> >> SPV, but zero-knowledge proofs will may help the latter. (you've got
> >> Bitcoin itself to act as a random beacon remember)
> >>
> >> Speaking of, another similar approach is to take advantage of how a
> >> Bitcoin sacrifice can be made publicly visible. Create a txout of some
> >> value like the following:
> >>
> >> OP_RETURN <prev-ztc-blockhash> <blockhash> <ztc-created>
> >>
> >> Now even if you fail to publish your blocks, at least the whole world
> >> knows how much they need to outspend to be sure you can't 51% attack the
> >> network. This approach and not-btc sacrifices can go hand in hand too,
> >> especially if nodes follow rules where they consider btc txout
> >> sacrifices as "fixed" and only subject to change by the bitcoin
> >> blockchain re-organizing. Advantages and disadvantages to both
> >> approaches. (remember that visible tx's can be censored by miners)
> >>
> >> Sacrifice to mining fees may be acceptable in the future too, but only
> >> if OP_DEPTH is implemented so as to not give Bitcoin miners bad
> >> incentives. (the sacrificed coins should go to fees *months* or even
> >> *years* after they have been sacrificed)
> >>
> >> Turning zerocoins back into Bitcoins is just supply and demand: sell
> >> them. You'll always lose a bit given by definition the maximum exchange
> >> rate is 1:1, but anonymity may be worth it. Others have written about
> >> cross-chain trading protocols, and I'll point out they are easier to
> >> implement if one chain has full visibility into what's happening on the
> >> other; zerocoin is most likely to be implemented as an extension to the
> >> bitcoin client itself.
> >>
> >> Finally if the transaction rate is too slow there's nothing wrong with
> >> running multiple parallel zerocoin blockchains, although given the
> >> usecase of moving your funds through zerocoin for anonymity, and using
> >> the clean coins that come out the other side, there's no reason to think
> >> the zerocoin chain transaction rate needs to be especially high anyway.
> >>
> >> --
> >> 'peter'[:-1]@petertodd.org
> >> 0000000000000013b2f7ee77027f583b765ad9811dfe3d0adc801e295fd9acdf
> >>
> >
> >
> > --
> > Jorge Timón
> >
> > http://freico.in/
> >
>
>
> --
> Jorge Timón
>
> http://freico.in/
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
900 Winslow Way East / SUITE 100 / Bainbridge Island, WA 98110
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130713/8d91701d/attachment.html>

2023-06-07 15:02:48

- reply

📅 Original date posted:2013-06-05
📝 Original message:So, this
http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
article got posted today, noting that FinCEN thinks irrevocable
payments
are money laundering tools.
I will hold my thoughts about the net social good of rent-seeking large
corporations taking money from consumers over fraudulent reversals.
Actually, I won't, I just said it.
At any rate, it got me thinking, can we layer on revocability somehow
without any protocol change, as an opt-in?
My initial scheme is a trusted (hah) escrow service that issues time
promises for signing. If it doesn't receive a cancel message, it will sign
at the end of the time.
The addresses would be listed by the escrow service, or in an open
registry, so you could see if you were going to have a delay period when
you saw a transaction go out.
This seems sort of poor to me, it imagines that mythical thing, a trusted
escrow service, and is vulnerable to griefing, but I thought I'd see if
some of the brighter minds than me can come up with a layer-on approach
here.
When I think about it, I can imagine that I would put a good number of my
coins in a one day reversible system, because I would have warning if
someone wanted to try and spend them, and could do something about it. I'm
not sure if it gets me anything over a standard escrow arrangement, though.
Peter
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130605/a980c720/attachment.html>

2023-06-07 15:02:06

- reply

📅 Original date posted:2013-05-19
📝 Original message:I think this is a very interesting idea. As Bitcoiners, we often stuff
things into the 'alt chain' bucket in our heads; I wonder if this idea
works better as a curing period, essentially an extended version of the
current 100 block wait for mined coins.
An alternate setup comes to mind; I can imagine this working as a sort of
gift economy; people pay real BTC for merge-mined "beta BTC" as a way to
support development. There is no doubt a more elegant and practical
solution that might have different economic and crypto characteristics.
On Sun, May 19, 2013 at 6:23 AM, Adam Back <adam at cypherspace.org> wrote:
> Is there a way to experiment with new features - eg committed coins - that
> doesnt involve an altcoin in the conventional sense, and also doesnt impose
> a big testing burden on bitcoin main which is a security and testing risk?
>
> eg lets say some form of merged mine where an alt-coin lets call it
> bitcoin-staging? where the coins are the same coins as on bitcoin, the
> mining power goes to bitcoin main, so some aspect of merged mining, but no
> native mining. and ability to use bitcoins by locking them on bitcoin to
> move them to bitcoin-staging and vice versa (ie exchange them 1:1
> cryptographically, no exchange).
>
> Did anyone figure anything like that out? Seems vaguely doable and
> maybe productive. The only people with coins at risk of defects in a new
> feature, or insufficiently well tested novel feature are people with coins
> on bitcoin-staging.
>
> Yes I know about bitcoin-test this is not it. I mean a real live system,
> with live value, but that is intentionally wanting to avoid forking
> bitcoins
> parameters, nor value, nor mindshare dillution. In this way something
> potentially interesting could move forward faster, and be les risky to the
> main bitcoin network. eg particularly defenses against
>
> It might also be a more real world test test (after bitcoin-test) because
> some parameters are different on test, and some issues may not manifest
> without more real activity.
>
> Then also bitcoin could cherry pick interesting patches and merge them
> after
> extensive real-world validation with real-money at stake (by early
> adopters).
>
> Adam
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Are you coming to Bitcoin2013 <http://bitcoin2013.com> in San Jose In May?
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130519/64712563/attachment.html>

2023-06-07 11:37:56

- reply

📅 Original date posted:2013-03-12
📝 Original message:Thanks Chris.
Yep, looks like an honest-ish user managed to accidentally get one tx into
one chain and another into the other.
I think I'd cautiously say that if OKPay gets their cash back, or freezes
his balance nobody is out BTC for last night, (instead just time and
effort).
I'm doing a little FUD-fighting right now, but will try and pick up a bit
more if necessary tonight after my flight lands. I think this is mostly
over the heads of a lot of our typical media contacts, though.
Peter
On Tue, Mar 12, 2013 at 12:53 PM, Christian Decker <
decker.christian at gmail.com> wrote:
> Just a quick and dirty check if something bad actually happened. 430
> transactions that were confirmed in the alt-chain, are not confirmed
> in the true blockchain. The good news is that as far as I can tell
> most of them are low volume transactions destined for SD.
>
> 7 transactions were true double spends, or to be more precise
> transactions in which an conflicting transaction was confirmed in the
> new chain (with their respective amount):
>
> 12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195 261 BTC
> cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af 0.06 BTC
> 7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96 0.01 BTC
> 355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e 0.05 BTC
> b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a 0.61 BTC
> 138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6 1.62 BTC
> a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90 0.81
>
> So the one transaction that really hurt was the one published on
> BitcoinTalk. We're not yet out of the woods as some of the 423
> transactions still have a chance of being doublespent, but looks like
> it's not that bad after all.
>
> Cheers,
> Chris
>
> P.S.: For a complete list of transactions see http://pastebin.com/wctJU3Ln
> --
> Christian Decker
>
>
> On Tue, Mar 12, 2013 at 7:39 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
> > On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
> >> On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes <peter at coinlab.com>
> wrote:
> >>> Can some enterprising soul determine if there were any double-spend
> attempts?
> >>> I'm assuming no, and if that's the case, we should talk about that
> publicly.
> > [snip]
> >> I agree it would be good to confirm no one was ripped off, even though
> >> we can't say there weren't any attempts.
> >
> > https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_mar
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130312/4b6ea7e8/attachment.html>

2023-06-07 11:37:43

- reply

📅 Original date posted:2013-03-12
📝 Original message:Can some enterprising soul determine if there were any double-spend
attempts?
I'm assuming no, and if that's the case, we should talk about that publicly.
Either way, I think it's generally another test well done by everyone;
people pitched in on PR, tech, communication, yay Bitcoin!
On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner <etotheipi at gmail.com> wrote:
> On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr <luke at dashjr.org> wrote:
>
>>
>>
>> I think we should be careful not to downplay the reality either.
>> For a number of hours, transactions could have received up to N
>> confirmations
>> and then still been reversed. While we could contact the bigger payment
>> processors, I saw people still trying to buy/sell on OTC, whom could have
>> been
>> scammed even by taking standard precautions.
>>
>>
> I don't want to misrepresent what happened, but how much of that was
> really a risk? The block was rejected, but the transactions were not. Any
> valid transactions to hit the network would get added to everyone's memory
> pool and mined in both chains. Thus all nodes would still reject
> double-spend attempts. As far as I understood it, you would've had to have
> majority mining power on one of the chains (and both had non-negligible
> computing power on them), so double-spending still required an exceptional
> amount of resources -- just not the normal 50% that is normally needed.
> Perhaps... 10%? But how many people can even have 10%? In addition to
> that, a victim needs to be found that hasn't seen the alert, is willing to
> execute a large transaction, and is on the wrong side of the chain.
>
> Is this incorrect? Yes, there was less resources needed to execute an
> attack -- but it still required a very powerful attacker, way outside the
> scope of "regular users."
>
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130312/0e69d2ec/attachment.html>

2023-06-07 11:33:32

- reply

📅 Original date posted:2013-02-25
📝 Original message:We've been toying with the idea of a 'dead' button, one that issues a bunch
of pre-generated txs sending stuff out to a previously secured 'backup' set
of addresses (we don't think in terms of wallets, just keypairs).
In this scenario, you have a long-term storage address (or set of them),
and if you need to hit the panic button, previously signed transactions
send value over to your emergency storage.
If you've mucked around sending / receiving with your long-term storage,
you'd only catch some BTC, not necessarily all, but what's nice is the
panic transaction leaking has lower security requirements than your private
keys -- worst case it's out, and you've got to deal with stuff in emergency
storage, as opposed to losing all your coins.
You could pair this with a server that checks if 'safe' addresses have
'unauthorized' transactions showing up on the blockchain, and you'd have a
reasonable automated security layer. Maybe. :)
I'm interested in thoughts on this approach as well.
Jorge -- I respectfully disagree with you, there are a number of enterprise
scenarios where your method is not appropriate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130225/c4c50ba1/attachment.html>

2023-06-07 10:42:22

- reply

📅 Original date posted:2012-11-28
📝 Original message:Jeff,
This rocks. Thank you!
Peter
On Wed, Nov 28, 2012 at 3:26 AM, Mike Hearn <mike at plan99.net> wrote:
> Cool, will check it out soon.
>
> > libccoin should work on Windows. picocoin will work on Windows,
> > but be a bit less secure than other platforms due to lack of fork.
>
> FYI, Windows has quite good sandboxing support. You could implement
> the same thing later with Win32 if you want.
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121128/f02d5160/attachment.html>

2023-06-07 10:34:10

- reply

📅 Original date posted:2012-10-03
📝 Original message:My reply-all forward was blocked (over 40k), sigh. I figured I'd spammed
the list enough for one night.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121003/42270bf4/attachment.html>

2023-06-07 10:33:53

- reply

📅 Original date posted:2012-10-02
📝 Original message:I meant sent twice, a.
No double-spends that I'm aware of. Sorry for the loose verbiage!
Peter
On Tue, Oct 2, 2012 at 11:07 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Tue, Oct 2, 2012 at 1:52 PM, Peter Vessenes <peter at coinlab.com> wrote:
> > This is small, but an interesting tidbit from BTC Foundation payments;
> > roughly 3-5% of our initial members double-spent. WOW, that's terrible.
>
> To be specific, do you mean
>
> a) paid twice
> or
> b) sent BF coins, then sent the same coins elsewhere
> ?
>
> Double-spend is a specific technical term....
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121002/e448bd63/attachment.html>

2023-06-07 10:33:47

- reply

📅 Original date posted:2012-10-02
📝 Original message:There are tons of scenarios, some discussed here on this list previously,
which would benefit from out of band messages and notes.
This is small, but an interesting tidbit from BTC Foundation payments;
roughly 3-5% of our initial members double-spent. WOW, that's terrible.
I presume that's because they use web wallets without double-click
prevention. But, seriously! A tiny UI issue that's a big deal in an
irrevocable payment system.
On Tue, Oct 2, 2012 at 10:43 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> I agree we need a payment protocol, but instead of thinking of all of the
> things we might possibly want I would like to solve a few boring problems
> that we have right now.
>
> Absolutely critical:
>
> + Bitcoin addresses by themselves are insecure against man-in-the-middle
> attacks. We need a payment protocol so if you get a donation link for
> "Bitcoin Foundation" in an email message and click on it you can be
> reasonably certain that your coins will actually go to the Foundation and
> not some hacker at your ISP that modified the email message.
>
>
I'm trying but can't think of a lightweight solution to this off the top of
my head. Not that that proves much.
> + After sending payment I should have a receipt that proves I followed the
> payee's instructions, so if the payee says they never received the funds I
> can prove that it wasn't my fault.
>
>
+ Protocol for gathering signatures from multiple devices
> (extension/variation of the basic payment protocol, I think).
>
> With the foundation trying to operate without bank accounts, I think it
comes into clarity for me just how innovative and incredibly awesome this
would be for financial controls for companies. Imagine the bookkeeper
inputting payments, and the owner (or 2 of 3 owners) approving them. I can
even imagine large member groups having 2/3 or majority spend rules.
When we talk about stuff like this, I come back around to thinking there
should be many different GUIs -- this use case is more business-y, it's
stuff like this that I always think about the bitcoin testing project
helping provide -- a standard backend that a bookkeeping GUI could go on
top of..
> Not absolutely necessary, but I think v1 should have it anyway:
>
> + Where-to-send-refund information included with payments, so
> overpayments/refunds can be handled efficiently and displayed intelligently
> in the customer's wallet.
>
>
> Everything else I think can wait.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121002/46787c97/attachment.html>

2023-06-07 10:33:28

- reply

📅 Original date posted:2012-10-03
📝 Original message:And, finally, when I say "Ditto to above" I mean "I have no idea", not
"nope". Double oops.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121002/72c1d5e1/attachment.html>

2023-06-07 10:33:15

- reply

📅 Original date posted:2012-10-01
📝 Original message:I'm a big proponent of a testing project.
I think if one could self organize that Gavin and team wanted to bless we
could put up some BTC as bounties or funding. We won't have our heads
around the foundation budget for a few more weeks, but self-organization is
often slower than budgeting. :)
This is just my opinion, but I would like very, very much to move the
current specification into unit tests so that anyone could validate their
alternate bitcoin implementation. This is a lot of work, some of which has
been done, much of which hasn't.
So, my two cents, plus an offer to bring it up at our next budgeting
meeting.
Peter
On Mon, Oct 1, 2012 at 7:28 AM, steve <steve at mistfpga.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/10/2012 14:52, Arklan Uth Oslin wrote:
> > Hi guys.
> >
> > So, as I mentioned on the bitcointalk.org forums thread about the
> > foundation, I want to get involved in the QA side of bitcoin
> > development. I've done functional testing in the video game
> > industry for years.
>
> Nice one, I worked in games for quite a few years. (before getting
> into finance then pentesting) there are about 6 keen testers now.
> maybe we should get a bitcoin-test mailing list, where we can discuss
> stuff without disturbing the dev team.
>
> > I've read all the messages in this thread, but I'm left unclear
> > how I can most effectively and quickly being helping out. Could I
> > get a bit of a directional nudge?
>
> Great question... for me I feel structure is the most important thing
> to sort out first. However we desperately need detailed testcases for
> the release of a new version. - Not too much on the change log stuff,
> more on the noddy stuff (as gavin points out below), downloading and
> making sure it works on a non dev machine, make sure the wallet isnt
> overwritten, etc.) doing games qa I imagine this would be an ideal
> place for you to start. I have a MSDN and TechNet licence so if you
> need some reference ms virtual machines I can help you out.
>
> However we need some testcase software. Please check out what was
> done on bettermeans for the stuff I was planning out...
>
> It details everything from recompense and testcases. bettermeans kinda
> died a death though...
>
> check out:
>
> Bitcoin over all-
> https://secure.bettermeans.com/projects/4180/wiki/Page_index
> discussion
> https://secure.bettermeans.com/projects/4180/boards
>
> 0.7
> https://secure.bettermeans.com/projects/4256/boards
> and
> https://secure.bettermeans.com/projects/4256/wiki
>
> I still have the testcases, but until we get some proper testcase
> software I am loathed to publish them in a half arsed format. (they
> worked well on bettermeans, then just vanished one day...) what
> testcase software are you familiar with?
>
> apart from that, what do you feel you can do for the project? how long
> have you been involved in bitcoin? It may well be worth reading up
> all the dev stuff on the wiki so you can get you head around how the
> bitcoin protocol is different from the daemon and qt client. What do
> you think you can and will enjoy doing? What is your skill set in
> regard to networking, crypto and operating systems. (not that you need
> any, in any we still want and need you. :)
>
> there really is room for you to do whatever role you want, and as
> little or as much as you want - however funding is now a very tricky
> issue. so much so that I am not sure I want anything to do with
> it(distribution of coin based on work.). - I just paid for some logo
> spec work out of my own pocket (for example). I have some testers i
> know irl who are willing to work for coin.
>
> NOTE: This response has nothing to do with the bitcoin foundation. I
> am not a member of the foundation. I do not speak for them or even
> probably with them. I am still trying to work out how much qa the
> foundation should be responsible for, and/how it is supposed to work.
> I think the games cert process would be ideal for this. This however
> this a discussion that probably wont have my involvement. (personally
> I believe that the foundation should publish requirements with example
> code and testcases for each aspect of the reference client. (on
> reference platforms - I do not expect many to agree with this though)
>
> As a side note, what happens to the donations to the bitcoin testing
> project? do they get moved over to the foundation? this question is
> bigger than this email. as far as I know they are all on an address
> Gavin holds. Actually I would like to be involved in any discussions
> that would impact QA, does this mean I need to join the foundation or
> just go lone wolf?
>
> tbh I dont really understand foundations. I always thought they were
> just a tax dodge.
>
> Sorry for the long message. :)
>
> >
> > Arklan
> >
> > ---------- As long as there is light, the darkness holds no fear.
> > And yet, even in the deepest black, there is life. - Arklan Uth
> > Oslin
> >
> > I want to leave this world the same way I came into it: backwards
> > and on fire. - Arklan Uth Oslin
> >
> >
> >
> > On Sat, Sep 29, 2012 at 12:26 PM, steve <steve at mistfpga.net>
> > wrote:
> >
> > Hi Gavin,
> >
> > Sorry for the delayed response, I wanted to take a couple of days
> > to reflect on your email.
> >
> > On 26/09/2012 19:09, Gavin Andresen wrote:
> >
> >
> > And their are other methods too.
> >
> >
> >
> > The GUI::Test package for perl will allow this to be greatly
> > automated. (I have done this before on the localisation of
> > photoshop.)
> >
> >
> >
> > this why we need detailed testscripts and plans. so we know what
> > has and hasnt been done. The more boring the task the more work
> > that needs to go into testcase development. This is the area I see
> > as my greatest failing last time. I have a large number of virtual
> > machines and should have at least this work. But we need very
> > detailed testcases. with decent testplans just downloading the
> > software, syncing the block chain, syncing an existing wallet,
> > rescanning the blockchain and verifying the balance would cover a
> > large number of tests. The idea behind having lots of very
> > specific testcases is you get to see what tests have not been run.
> >
> >
> >
> > I understand your concern, however I have taken a couple of days
> > to reflect on this and I still strongly feel that in order to make
> > sure that this sticks, and is still useful in 1 years time we need
> > to lay proper foundations. Those foundations are not word
> > documents, spreadsheets, etc. they are selecting the right tools
> > for the job.
> >
> > We can gain so much benefit from using 3rd party software.
> > (bettermeans would rock if it wasnt rotting)
> >
> > I am sure you could do your coding work just using vi, but an sdk
> > makes it much easier and allows you to work in a more productive
> > manner.
> >
> > I have had a couple of off list emails with some testers and they
> > also feel that it is very important to make sure we have a sound
> > foundation (mantis is so much more than just a bug reporting tool,
> > I see the bug reporting functionality as secondary to the main test
> > run functionality - but it doesnt have to be mantis based, we do
> > need workflow and testcase software though - and proper software
> > for this is much better than just a massive google doc.) however I
> > am checking out some other software that has been recommended. It
> > will be very hard to change 'the process' once we have something we
> > are used too (just look at the current resistance) I promise
> > nothing will change for the dev team. But test does need other
> > tools, and processes.
> >
> > If you feel that strongly that I am going about this the wrong way,
> > I am happy to step back and let someone else sort it out (I will
> > still do all the testing I possibly can). I would feel that this
> > would be a real shame and we have the chance to setup requirements
> > to functionality to tests all with traceability. why not do it
> > right from the start?
> >
> > I will open up my vps' somepoint over the next few days and you
> > can see what I mean. I will setup a fake git project, and sort out
> > the interactions.
> >
> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> How fast is your code?
> >> 3 out of 4 devs don\\\'t know how their code performs in
> >> production. Find out how slow your code is with AppDynamics
> >> Lite. http://ad.doubleclick.net/clk;262219672;13503038;z?
> >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> Got visibility?
> > Most devs has no idea what their production app looks like. Find
> > out how fast your code is with AppDynamics Lite.
> > http://ad.doubleclick.net/clk;262219671;13503038;y?
> > http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> >
> >
> >
> > _______________________________________________ Bitcoin-development
> > mailing list Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJQaaieAAoJEFvEB9dQFvtQUi0H/3Eh72DqxwBt6AeNos/hJNqQ
> ZowMNFRupJQM301EJ7SPQmcnVuc3RF2Jw//ckpAqdpkqhHCgGO9HX/q+Ic2A9erQ
> CfKbUOwQgqKuLQTZ8eT5UMh969Uw8PMazo711d2I23etU0VhSK/MvjB5IiYIq5fB
> RJdCEluwvACaiftqfm4RA9HXXJGMnsZtlSWjVQCkg2FyYZKfpctEFdGCg6R8IaP7
> ypyglR7TfygcjhUMHeWkQQCP2m2gBOHpx9H99uNBosF+6pLBhCiGUrwVkl8HUiiN
> 4YfhsvoRQ0BWNgvO9wH1H4EyyZtJsE7S926BNkhd4uewWGV/qe8gML+uJRstPDg=
> =L66i
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121001/bf75a1eb/attachment.html>

2023-06-07 10:30:59

- reply

📅 Original date posted:2012-09-13
📝 Original message:I like this idea, although I would say the blockchain should go in
/var/lib/bitcoin by default, right? I'm just a longtime LInux guy, not a
formal sysadmin, though.
Peter
On Fri, Sep 14, 2012 at 11:15 AM, grarpamp <grarpamp at gmail.com> wrote:
> I mentioned this somewhere a while ago.
> It is enough of a sysadmin problem to warrant a feature ticket.
> Open one on github for it.
> XDGBDS is not canon. So don't hardcode said paths.
> All paths should be specifiable in bitcoin the config file, whose
> location should itself be specifiable on the command line.
>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120914/2b3f898d/attachment.html>

2023-06-07 10:26:23

- reply

📅 Original date posted:2012-07-29
📝 Original message:This is a good idea. I think I can come up with the cash, I will
follow up with gavin.
Sent from my smartphone!
On Jul 29, 2012, at 7:18 PM, Mike Hearn <mike at plan99.net> wrote:
> MacOS X 10.8 makes application signing borderline mandatory, in that
> you cannot run unsigned apps unless you tweak your settings via the
> control panel. You must sign with a certificate issued by Apple via
> their "identified developer" program.
>
> Windows allows but does not require signing. However, anti-virus
> systems tend to use signers with good reputation as a whitelisting
> signal. Signing Bitcoin releases makes sense because it may lead to,
> at minimum, higher performance if AV engines ignore file reads/writes
> by Bitcoin. And it can also shield us from false positives. You only
> need to see the mess that the mining tools world has become to
> understand why this is important.
>
> As I don't take part in the release process, I can't help out with
> this directly, but I believe it's important and would be willing to
> throw some money in towards buying the signing certs for both
> platforms. I guess Gavin would be the final signer.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 10:24:23

- reply

📅 Original date posted:2012-07-24
📝 Original message:I think it would be great to have more nonce space with less merkle
calculation; keeping track of all possible versions of a block already
takes real RAM, real computation. Being able to change one bit in the
header and send out a new block for checking would ease our pool server
work by a real amount, somewhat on the work generation side, but also on
the checking old work side; we'll have a lot fewer unique transaction /
coinbase sets to hold on to for checking when we get back a solution.
Peter
On Tue, Jul 24, 2012 at 4:58 PM, Mike Hearn <mike at plan99.net> wrote:
> > That'd be 7 bytes of nonce in the block header, which is
> > 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes
> >
> > So: the changes for version 2 blocks would be "has height in the
> > coinbase, and has a 1-byte version number with a 3-byte extranonce."
>
> I don't understand why more nonce bits are necessary. Is it really
> impossible for a multi-core CPU to keep up with the merkle root
> re-calculation and keep an ASIC miner fed, or is this working around a
> performance bottleneck somewhere else?
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120724/e4232c5c/attachment.html>

2023-06-07 10:20:03

- reply

📅 Original date posted:2012-07-06
📝 Original message:On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes <peter at coinlab.com> wrote:
> > The proposal is simple, and it's a small change for miners, I imagine.
> >
> > My question is: why?
> >
> > I worry about stuffing too many requirements on the coinbase. I suppose
> > the coinbase is easily extendible if we run out of bytes, but I think I'd
> > like to see some more discussion / good / bad type cases for making this
> > change. What do we get over just the prev_hash by doing this?
>
> With the existing setup (sans height in coinbase), you might not have
> unique transactions, with all that entails.
>
> Yes, I've experienced that myself, actually.
> > Anyway, some background would be great; if I missed it, I'm happy to go
> > read up, but I didn't see any links on the wiki.
>
> Gavin wrote some notes on upgrades and BIP16 lessons-learned at
> https://gist.github.com/2355445
>
> This is a super coherent and excellent writeup. I may come back with more
thoughts, I want to let it percolate. Thanks!
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120706/a1b1e1dc/attachment.html>

2023-06-07 10:19:44

- reply

📅 Original date posted:2012-07-06
📝 Original message:So,
The proposal is simple, and it's a small change for miners, I imagine.
My question is: why?
I worry about stuffing too many requirements on the coinbase. I suppose the
coinbase is easily extendible if we run out of bytes, but I think I'd like
to see some more discussion / good / bad type cases for making this change.
What do we get over just the prev_hash by doing this?
If this is just a voting mechanism for moving to v2 blocks, that's cool,
but it would be nice to codify voting in the coinbase a bit? Maybe? We've
now once voted with /p2sh/ and this is a different mechanism now, if I
understand it properly.
Anyway, some background would be great; if I missed it, I'm happy to go
read up, but I didn't see any links on the wiki.
Peter
On Fri, Jul 6, 2012 at 8:10 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> Please review and comment...
>
> Block v2, Height in Coinbase
> https://en.bitcoin.it/wiki/BIP_0034
>
> BIP: 34
> Title: Block v2, Height in Coinbase
> Author: Gavin Andresen <gavinandresen at gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2012-07-06
>
> Abstract
>
> Bitcoin blocks and transactions are versioned binary structures. Both
> currently use version 1. This BIP introduces an upgrade path for
> versioned transactions and blocks. A unique nonce is added to newly
> produced coinbase transactions, and blocks are updated to version 2.
>
>
> Motivation
>
> 1. Clarify and exercise the mechanism whereby the bitcoin network
> collectively consents to upgrade transaction or block binary
> structures, rules and behaviors.
>
> 2. Enforce block and transaction uniqueness, and assist unconnected
> block validation.
>
>
> Specification
>
> 1. Treat transactions with a version greater than 1 as non-standard
> (official Satoshi client will not mine or relay them).
>
> 2. Add height as the first item in the coinbase transaction's
> scriptSig, and increase block version to 2. The format of the height
> is "serialized CScript" -- first byte is number of bytes in the number
> (will be 0x03 on main net for the next 300 or so years), following
> bytes are little-endian representation of the number.
>
> 3. 75% rule: If 750 of the last 1,000 blocks are version 2 or
> greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)
>
> 4. 95% rule ("Point of no return"): If 950 of the last 1,000 blocks
> are version 2 or greater, reject all version 1 blocks. (testnet3: 75
> of last 100)
>
>
> Backward compatibility
>
> All older clients are compatible with this change. Users and merchants
> should not be impacted. Miners are strongly recommended to upgrade to
> version 2 blocks. Once 95% of the miners have upgraded to version 2,
> the remainder will be orphaned if they fail to upgrade.
>
>
> Implementation
>
> https://github.com/bitcoin/bitcoin/pull/1525 and
> https://github.com/bitcoin/bitcoin/pull/1526
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120706/cc73c259/attachment.html>

2023-06-07 10:14:37

- reply

📅 Original date posted:2012-06-15
📝 Original message:Hi all,
I've been wondering about whether it would be possible to wipe out the GUI
completely from the satoshi client, and reimplement any necessary data
requests as RPC calls, allowing us to fork -QT and other GUIs over and
(hopefully) dramatically simplifying the codebase that you all have to work
on.
Any thoughts about this? Once a week at least I find myself wanting to find
ways to help speed up development, this seems like it could be a big win.
Peter
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120615/79d6e61a/attachment.html>

2023-06-07 10:13:39

- reply

📅 Original date posted:2012-06-14
📝 Original message:This is super cool!
I have a feature request: it would be awesome to be able to provide private
keys at the command line with the signature, turning the client into a
wallet-less signature machine.
Peter
On Thu, Jun 14, 2012 at 9:22 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> I submitted a pull request yesterday that implements low-level "raw"
> transaction, and am looking for feedback on the API and help with
> trying to test/break it.
> ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120614/3dde553e/attachment.html>

2023-06-07 10:11:31

- reply

📅 Original date posted:2012-06-03
📝 Original message:On Sat, Jun 2, 2012 at 8:52 PM, Luke-Jr <luke at dashjr.org> wrote:
> Analysis, comments, constructive criticism, etc welcome for the following:
>
> ==Background==
> At present, an attacker can harm a pool by intentionally NOT submitting
> shares
> that are also valid blocks. All pools are vulnerable to this attack,
> whether
> centralized or decentralized and regardless of reward system used. The
> attack's effectiveness is proportional to ratio of the attacker's hashrate
> to
> the rest of the pool.
>
>
I'm unclear on the economics of this attack; we spent a bit of time talking
about it a few months ago at CoinLab and decided not to worry about it for
right now.
Does it have asymmetric payoff for an attacker, that is, over time does it
pay them more to spend their hashes attacking than just mining?
My gut is that it pays less well than mining, meaning I think this is
likely a small problem in the aggregate, and certainly not something we
should try and fork the blockchain for until there's real pain.
Consider, for instance, whether it pays better than just mining bitcoins
and spending those on 'bonuses' for getting users to switch from a pool you
hate.
Watson, I don't believe the attack signature you mention is a factor here,
since the pool controls the merkle, only that pool will benefit from block
submission. The nonce / coinbase combo is worthless otherwise, and so this
attack is just in brief "get lucky, but don't submit."
So, can anyone enlighten me as to some actual estimates of badness for this
attack?
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120603/40300cbd/attachment.html>

2023-06-07 10:10:47

- reply

📅 Original date posted:2012-05-29
📝 Original message:I see. That is undeniably more secure and "bitcoin-y" than my suggestion.
It's also really a lot more work, especially in that it requires extra
linkages between codebases that in my mind are largely separate.
I'm just one voice, but I persist in believing that the 'lighter' solution,
especially for something that may not be a particularly big problem in the
bitcoin world is good -- it carries much less technical implementation debt
going forward, and has a lower risk of sort of seizing up development with
additional necessary code to worry about for those implementing to-spec
clients.
If that lighter solution turns out to be gameable, or has problems that
require the full force of the bitcoin network and concepts, that would be
the time to implement the improved version. That's just my approach,
however. I worry that building in any additional requirements to the
protocol or codebase adds significant cost to the network as a whole over
the next 10 years.
Peter
On Tue, May 29, 2012 at 11:39 AM, Luke-Jr <luke at dashjr.org> wrote:
> On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote:
> > I suppose I mean that I don't understand how to reverse that into a URL
> > when one is presented only with a block, or perhaps a coinbase in a
> > transaction.
>
> A new message can be added to the p2p relay network, similar to tx and
> alert
> broadcasts, that allow miners to publish/update their policy URI signed by
> the
> key in question. Counter-DDoS rules could decline to relay or store URIs
> for
> keys that haven't been published in - or achieved statistical significance
> in
> - the last N blocks.
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120529/dc488769/attachment.html>

2023-06-07 10:10:41

- reply

📅 Original date posted:2012-05-29
📝 Original message:I suppose I mean that I don't understand how to reverse that into a URL
when one is presented only with a block, or perhaps a coinbase in a
transaction.
Best,
Peter
On Tue, May 29, 2012 at 11:34 AM, Luke-Jr <luke at dashjr.org> wrote:
> On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
> > I don't understand what the 20 byte keyhash is. Can you elucidate?
>
> 20 byte keyhashes are a fundamental building block of the Bitcoin protocol.
>
> ripemd160(sha256(ecdsaPubKey))
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120529/576c8f78/attachment.html>

2023-06-07 10:10:35

- reply

📅 Original date posted:2012-05-29
📝 Original message:I disagree with a bunch of your points, but I'll wait on others to comment,
except I will say that I don't understand what the 20 byte keyhash is. Can
you elucidate?
I am assuming major mining folks have written their own coinbasing
facilities, but perhaps this is not the case -- if so, I agree that some
work is necessary for such miners.
Finally I will just comment that I am guided by the general perspective
that many things about bitcoins are opt-in; therefore it makes sense to me
put difficult work onto those who are motivated to do it, and keep things
as easy as possible for the 'maybes' to participate -- hence small
courtesies like allowing text/plain or text/html.
Peter
On Tue, May 29, 2012 at 11:18 AM, Luke-Jr <luke at dashjr.org> wrote:
> On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote:
> > 1) Germane to the original conversation, anything hard to implement will
> > not get implemented by miners.
>
> Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch,
> anything modifying the coinbase is hard to implement.
>
> > 2) Coinbase is hard-limited to 100 bytes; this has to include space for
> > voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
> > good plan.
>
> Rather, I would suggest a 20 byte keyhash, which allows the owner to
> broadcast
> a full URI out-of-band.
>
> > 1) They shall prepend \mi: to the url to designate it as a url for miner
> > info, and append a trailing \ to the url
>
> How about a simple prefix to the fixed-size keyhash?
> Perhaps "MFR=" (Mining Fee Rules)
>
> > 2) The url given in the coinbase shall have http:// prepended to it
> before
> > processing.
>
> I would recommend miners use https, with a specified SSL keyhash in the URI
> (so we don't need to pay for a "proper" SSL cert).
>
> > 3) The destination may be a redirect (to allow short URLs), or may
> deliver
> > content
>
> Clients should simply be required to follow the relevant HTTP
> specification.
>
> > 4) The content-type returned by the final site post-redirect shall be
> > either (preferred text/json) or text/plain or text/html
>
> text/plain and text/html are just wrong and don't make any sense here.
>
> > Inre: Luke's complaint about JSON, it is the language of the web. There
> is
> > no easier format for both computers and humans to read, and in this case,
> > it includes extensibility, which is nice, since we have no idea how
> miners
> > will wish to divvy up their services; I think one would need to make a
> > strong case against JSON for a specific reason to not choose it by
> default.
>
> Bitcoin isn't "the web", it's a complicated script-based cryptocurrency.
> Everything in the Bitcoin protocol requires a computer's interpretation for
> humans, and there's no reason to stray from this default. Also, JSON is not
> extensible in any of the ways needed for this specific purpose.
>
> > 4) The text of the document delivered shall be a JSON format dictionary,
> > and shall include at minimum the following fields: 'min_fee',
> 'pool_name',
> > and 'last_modified' Optional fields can be determined over time as
> > necessary by the mining community
>
> Last Modified and other caching rules are dealt with in the relevant HTTP
> specification...
>
> > 5) The Service Level Agreement isn't binding, but miners who implement it
> > are expected to make a best efforts attempt to follow it.
>
> While it doesn't make sense to give it the full legal force of a contract,
> I
> think it should be expressed as a "MUST" in the BIP.
>
> > Generally a miner would occasionally publish the \mi:\ when they had
> > updated their SLA, or just every so often, but the canonical location
> would
> > be the final destination URL from the redirects.
>
> The coinbase advertisement MUST be part of every coinbase mined by the
> miner,
> or there's no reliable way to prove which blocks are theirs.
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120529/c679f7af/attachment.html>

2023-06-07 10:10:22

- reply

📅 Original date posted:2012-05-29
📝 Original message:OK, I have a few thoughts on this:
1) Germane to the original conversation, anything hard to implement will
not get implemented by miners.
2) Coinbase is hard-limited to 100 bytes; this has to include space for
voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
good plan.
3) I'm a little fuzzy on the details of BIP governance; but I'm happy to
write one up and get my thoughts down, or someone who's more familiar could
do it, I suppose.
I propose the following spec:
periodically a miner may choose to publish a url through their coinbase as
follows:
1) They shall prepend \mi: to the url to designate it as a url for miner
info, and append a trailing \ to the url
2) The url given in the coinbase shall have http:// prepended to it before
processing.
3) The destination may be a redirect (to allow short URLs), or may deliver
content
4) The content-type returned by the final site post-redirect shall be
either (preferred text/json) or text/plain or text/html
4) The text of the document delivered shall be a JSON format dictionary,
and shall include at minimum the following fields: 'min_fee', 'pool_name',
and 'last_modified' Optional fields can be determined over time as
necessary by the mining community
5) The Service Level Agreement isn't binding, but miners who implement it
are expected to make a best efforts attempt to follow it.
So a valid coinbase could be:
/P2SH/\mi:goo.gl/mr2D\extra_nonce:2110
Generally a miner would occasionally publish the \mi:\ when they had
updated their SLA, or just every so often, but the canonical location would
be the final destination URL from the redirects.
Inre: Luke's complaint about JSON, it is the language of the web. There is
no easier format for both computers and humans to read, and in this case,
it includes extensibility, which is nice, since we have no idea how miners
will wish to divvy up their services; I think one would need to make a
strong case against JSON for a specific reason to not choose it by default.
Thoughts welcome!
Best,
Peter
On Tue, May 29, 2012 at 10:47 AM, Luke-Jr <luke at dashjr.org> wrote:
> On Tuesday, May 29, 2012 8:52:49 AM Michael Grønager wrote:
> > The format of the sla.php page should then be specified too - but it
> could
> > be a json-rpc call returning a json object like (as result): {
> > sla_version: "0.1",
> > accept_no_fee_tx: false,
> > min_fee: 50000,
> > big_tx_fee: 10000, // extra fee pr kb
> > }
> > I guess miners could work out a more suitable set of fees...
>
> Please not JSON, and not hard-coded logic. Bitcoin already has a secure
> scripting system - perhaps we can decide on an initial stack format and
> run a
> script retrieved from the URI?
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120529/134da980/attachment.html>

2023-06-07 10:10:12

- reply

📅 Original date posted:2012-05-28
📝 Original message:One of the issues here though is that it would be nice if miners published
their own tx rules -- it might be hard to impute them from data.
I had started a thread about this on bitcoin.org some time ago, and I don't
recall what the general outcome was.
I had imagined an open service whereby a miner could publish a short string
in their conbase tying to the service and the service would have different
metadata, including the miner's transaction guarantees.
We offered to host this before, and would still be willing to host such a
service.
Peter
On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas <moon at justmoon.de> wrote:
> Zooko is spot on - slower confirmations will give people a reason to set
> higher fees. As soon as fees reach a level where they matter, even
> botnet operators will be looking into ways of including transactions for
> some extra profit.
>
> In the meantime slightly slower confirmations aren't a problem. Consider
> that even if it takes four blocks to get your transaction included
> instead of one, once it is included, you still benefit from every new
> block in terms of security. So if you're looking for six confirmations
> for example, even a three block delay will only be a 50% delay for you.
> And of course there are techniques for instant transactions which
> continue to be refined and improved.
>
> As for the proposed solutions: Punishing 1-tx blocks is complete and
> utter nonsense. It's trivial to include a bogus second transaction.
>
> Any additional challenges towards miners like hashes of the previous
> block are at best useless. If I was running a botnet, I'd just grab that
> hash from a website (pretty good chance Blockchain.info will have it :P)
> or mining pool or wherever and keep going undeterred. At worst they may
> affect scalability one day. You might imagine a peer-to-peer network of
> miners who for cost reasons don't download all blocks anymore, but
> verify only a percentage of them at random. They might then exchange
> messages about invalid blocks including a proof (invalid tx, merkle
> branch) why the block is invalid. This is just one idea, the point is
> that assumptions about what a legitimate miner looks like may not always
> hold in the future.
>
> Finally, there is an ethical aspect as well. If a miner wishes not to
> include my transaction that is his choice. He has no more an obligation
> to sell his service to me than I have to buy it from him. If I really,
> really want him to include my transaction I will have to offer to pay more.
>
> If we as developers think that confirmations are too slow or that more
> blocks should include transactions, then the right measures would be:
>
> - Educating users about the relationship between confirmation speed and
> fees
> - Raising the default transaction fee
>
> Every market has a supply curve, so it is economically to be expected
> that there will be some miners who don't include transactions, simply
> because they are at that end of the supply curve where it is not worth
> it for them to sell their service. All markets must have a certain
> tension - there must be miners who don't include transactions for there
> to be users who want their transactions included more quickly. In other
> words there must be somebody not confirming if confirmations are to have
> value. If you interfere with that all you'll accomplish is keep
> transaction fees below market level, which will make the transition from
> inflation-financed hashing to transaction-financed hashing more painful
> and disruptive.
>
> Cheers,
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120528/23cf542d/attachment.html>

2023-06-07 10:09:58

- reply

📅 Original date posted:2012-05-25
📝 Original message:We just implemented our own mining tool, soup-to-nuts, and I would say that
the likely motivation for what I presume are botnet owners is just economic.
It's a lot more work to make sure your merkleing and keeping up-to-date are
happening than it is to just get an 80 byte header from a central server,
and re-calc a single transaction merkle client-side.
Not to mention the extra work to keep track of what version of
getmemorypool output you're receiving work for in a broadly distributed
pool.
For what it's worth, we did this extra engineering work since we care about
Bitcoin, but if I just wanted to pull value out of the ecosystem, we would
have skipped it.
The only solutions to this are economic solutions -- making such 'cheater'
blocks less valuable, or increasing the value of the transactions.
Also note that botnet operators likely care, in the end, about fiat
currency, so going to 25 btc per block in what I think of as transaction
fee subsidies won't necessarily impact this -- it's a matter of what
happens to exchange rates vs generation rates that will matter.
I think we also have to moderate this consideration against the rights (and
arguable benefits) of someone wanting to build an express-delivery mining
service, one that will provide provably faster certification for those
adding a transaction fee of, say, 1 btc.
My own experience now in the MMO world is that we have to carefully
understand how we deal with griefers who control massive resources (compute
or gold-farmers). It may not be a winning battle to choose a solution which
harms the rest of the network in exchange for harming the griefers.
This is definitely out of the box, but one solution might be to change the
difficulty calculations to just ignore 1tx blocks; that would minimize
impact on others to a great extent, and would let someone set up an express
block service if they chose. I guess we'd have to settle on whether or not
such blocks counted towards the issuance countdown as well. Or, we could
allow only 1/10 generation fees on such blocks.
Peter
On Fri, May 25, 2012 at 9:44 AM, Alan Reiner <etotheipi at gmail.com> wrote:
> I like the concept except that it only works if every node connected to
> the miner enforces the rule (if it works). Once any one of the nodes
> forwards the block, other nodes see it coming from a node that can pass
> the challenge.
>
> I don't think any solution based on node queries will succeed, especially
> if it requires spontaneous super-majority-of-nodes acceptance. I think
> it's gotta be based on the block itself and each nodes' own info.
>
> If you could spontaneously get all miners to agree not to build off of
> anti-social blocks (however that is defined) , it would have a chance of
> making a difference, but individual miners would have an advantage
> building off the antisocial block because they only need to produce one to
> create the longest chain (and collect reward) while the miners following
> the rules need two blocks.
>
> --Sent from my overpriced smartphone
> On May 25, 2012 3:48 AM, "Christian Decker" <decker.christian at gmail.com>
> wrote:
>
>> How about a simple proof of work test? This one though does not ask for
>> CPU work but asks the miner for a random old transaction. If the miner
>> really stores the entire blockchain he will not have any problem answering
>> to that getdata request, whereas a botnet would have to ask someone else
>> for it, which could be detected if the response time deviates too much from
>> what has been previously measured (compare it against getdata for the block
>> they advertise). It's not perfect but it allows an estimate of whether it
>> is a chainless miner.
>>
>> Regards,
>> Chris
>> --
>> Christian Decker
>>
>>
>>
>> On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
>>
>>> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke at dashjr.org> wrote:
>>> > Block times are not accurate enough for that.
>>>
>>> The times in your log are very accurate, assuming your system clock is
>>> remotely accurate.
>>>
>>> --
>>> Jeff Garzik
>>> exMULTI, Inc.
>>> jgarzik at exmulti.com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120525/c9f827d7/attachment.html>

2023-06-07 10:08:50

- reply

📅 Original date posted:2012-05-16
📝 Original message:Thanks for this, Amir.
My initial reactions:
1) This is cool and useful (but see 3)
2) This is significantly less secure than validating an entire blockchain;
it's certainly worth working out some use cases here in more detail than
just a sample conversation. More on this below
3) What about discovery? Will a client now have the chance to look for
NODE_STRATIZED clients on IRC? How do you envision a stratized server
decides which transactions to relay/store? Or is it just a caching layer in
front of a high quality blockchain service? If it is just a caching
service, the question of cache hits / misses is an interesting one as well.
4) What are the economic motivations to run a stratized server? Other than
cheating people of course.
5) Seems like a 'send me everything for this source address' is going to
save a lot of roundtrip conversations for what I imagine the most common
request will be.
Inre: majority agreement on transactions, and even balances, it would be
nice to work out some theoretical security / cost / value calculations for
the following scenarios:
Likely value and cost to someone of subverting / lying about
1) An n-confirmation transaction, n > 0
2) A 0 confirmation transaction
3) A NODE_STRATIZED transaction chain for a client with m connections to
NODE_STRATIZED servers
4) An address balance request for a client with m connections to
NODE_BALANCE_INFO (I made this name up) servers
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120516/c36915f7/attachment.html>

2023-06-07 10:05:38

- reply

📅 Original date posted:2012-04-30
📝 Original message:Blocks already checksum; they hash to a low number.
Also inre: block headers, you are furnished with a previous hash in the
first 80 bytes of the block. You can always cut the connection at that
moment if you've already seen the block headers.
Peter
On Mon, Apr 30, 2012 at 1:02 PM, Zell Faze <zellfaze at yahoo.com> wrote:
> Although quite true, I actually agree though that there should be some
> sort of checksum for the blocks. Bandwidth may not be a bottleneck now (or
> ever), but it may be at some point. This change will help Bitcoin scale.
>
> ------------------------
> "It stopped being just a website a long time ago. For many of us, most of
> us, Wikipedia has become an indispensable part of our daily lives."
> — Jimmy Wales, Founder of Wikipedia
> Help protect it now. Please make a donation today:
> http://www.wikimediafoundation.org/wiki/Donate
>
>
>
> --- On Mon, 4/30/12, Amir Taaki <zgenjix at yahoo.com> wrote:
>
> > From: Amir Taaki <zgenjix at yahoo.com>
> > Subject: Re: [Bitcoin-development] BIP to improve the availability of
> blocks
> > To: "bitcoin-development at lists.sourceforge.net" <
> bitcoin-development at lists.sourceforge.net>
> > Date: Monday, April 30, 2012, 3:11 PM
> > This is optimisation where it isn't
> > needed. Bandwidth is not the bottleneck of the Bitcoin
> > system. It is the immense time needed to validate the
> > blockchain.
> >
> > And clients should never send blocks first. They always send
> > an inv packet, then you request the block. It is a
> > disruptive change and brings little.
> >
> > We don't need to optimise every aspect of Bitcoin :) Just
> > focus on the big bits that matter, while keeping everything
> > working with minimal changes.
> >
> > For instance say we did this and to maintain backwards
> > compatible, we introduced a new message called "hash+block".
> > Now there are 2 code branches that must be maintained -
> > urgh.
> >
> >
> > ________________________________
> > From: Wladimir <laanwj at gmail.com>
> > To: Rebroad (sourceforge) <rebroad+sourceforge.net at gmail.com>
> >
> > Cc: bitcoin-development at lists.sourceforge.net
> >
> > Sent: Monday, April 30, 2012 7:26 PM
> > Subject: Re: [Bitcoin-development] BIP to improve the
> > availability of blocks
> >
> >
> > On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge)
> > <rebroad+sourceforge.net at gmail.com>
> > wrote:
> >
> >
> > >My proposal is that in addition to the size (which is
> > advertised in
> > >the header), the hash is also advertised in the header
> > (of a block).
> > >This would help nodes to determine whether they wanted
> > to reject the
> > >download. (e.g. if it already had a block matching that
> > hash). This of
> > >course wouldn't prevent a rogue node from sending an
> > incorrect hash,
> > >but this would aid in saving bandwidth amongst behaving
> > nodes.
> > >
> >
> > I suppose it would make sense for clients to be able to
> > reject blocks that they already have, if that's not
> > currently possible.
> >
> >
> > The other part of the proposal is to allow nodes to request
> > upload and
> > >download blocks that have already been partially
> > downloaded.
> > >
> > >This could be done by modifying the existing methods of
> > upload,
> > >download, or by adding a new method, perhaps even using
> > HTTP/HTTPS or
> > >something similar. This would also help nodes to obtain
> > the blockchain
> > >who have restrictive ISPs, especially if they are being
> > served on port
> > >80 or 443. This could perhaps also allow web caches to
> > keep caches of
> > >the blockchain, thereby making it also more available
> > also.
> > >
> >
> > You don't need a BIP if you want to somehow fetch the
> > (initial) block chain
> > outside the bitcoin protocol. You could download it from
> > some http
> > server or even pass it along on an USB stick. Then with a
> > simple client change you can import it:
> https://github.com/bitcoin/bitcoin/pull/883 .
> >
> >
> > Currently, without this functionality, nodes with
> > restrictive (or
> > >slow) internet have some options, such as going via a
> > tor proxy, but
> > >due to the latency, the problem with multiple receptions
> > of the same
> > >block still occur.
> > >
> >
> > If you're behind such a slow internet connection, and
> > concerned about
> > every bit of bandwidth, it is better to run a lightweight
> > node. For example, Electrum.
> >
> > Even if you could reduce the wasted bandwidth a bit by
> > puzzling
> > around with partial blocks, the download will still be
> > substantial (and that's going to get worse before it gets
> > better).
> >
> > Wladimir
> >
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's
> > security and
> > threat landscape has changed and how IT managers can
> > respond. Discussions
> > will include endpoint security, mobile security and the
> > latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's
> > security and
> > threat landscape has changed and how IT managers can
> > respond. Discussions
> > will include endpoint security, mobile security and the
> > latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120430/6ef5f65b/attachment.html>

2023-06-07 10:05:03

- reply

📅 Original date posted:2012-04-26
📝 Original message:These are interesting thoughts, karma for bitcoins essentially.
I would like CoinLab to publish a 'cost of subverting 1-n transactions with
90% probability' metric soon, and I think it would help everyone to
understand what that number is.
When we started out, you probably needed to wait 5 blocks for $10 or $20 of
bitcoin value transfer.
Now, I'd happily accept a $1k transaction with 1 confirmation.
More difficulty shortens the safe time we can transact large volumes in,
which is good for the network.
I'm not sure of the current implementation of replacement transactions, can
anyone on the core team speak to this? Can I replace transactions, or is
that part of the spec unimplemented or deprecated right now?
Peter
On Thu, Apr 26, 2012 at 8:49 AM, Peter Todd <pete at petertodd.org> wrote:
> It recently occured to me that we can use the public nature of the block
> chain to create trusted identities, for a specific form of trust.
>
> Lets suppose Alice has some bitcoins held at bitcoin address A. She
> wants to establish trust in the "identity" associated with the ECC
> keypair associated with A, for instance for the purpose of having other
> users trust her not to attempt to double spend. Since the trust she
> seeks is financial in nature, she can do this by valuing the identity
> associated with A, by delibrately throwing away resources. A simple way
> to do this would of course be to transfer coins to a null address,
> provably incurring a cost to her.
>
> A more socially responsible way would be for her to create a series of
> transactions that happen to have large, and equal, transaction fees.
> Bitcoin makes the assumption that no one entity controls more than 50%
> of the network, so if she makes n of these transactions consecutively,
> each spending m BTC to transaction fees, there is a high probability
> that she has given up at least n/2 * m BTC of value. This of course is
> all public knowledge, recorded in the block chain. It also increases the
> transaction fees for miners, which will be very important for the
> network in the future.
>
> Now Bob can easily examine the block chain, and upon verifying Alice's
> trust purchase, can decide to accept a zero-confirmation transaction at
> face value. If Alice breaks that promise, he simply publishes her signed
> transaction proving that Alice is a fraudster, and future Bob's will
> distrust Alice's trusted identity, thus destroying the value needed to
> create it.
>
> In effect, we now have a distributed green address system.
>
> Now Alice could try to mount a double-spend attack on a whole bunch of
> people at once, hoping to have them all accept the transaction. However
> as it is the "just trust them" model works pretty well already.
>
>
> A good usecase for this idea, beyond the obvious fast payments
> application, is a distributed anonymizer. Alice can now publish her
> request to anonymize coins, and other trusted identities can make their
> bids. If Alice accepts a bid from Bob, she will want Bob to send her the
> anonymized coins *prior* to her transaction going through, thus breaking
> the temporal connection between the transactions. Now Alice can give Bob
> the signed payment transaction, and Bob can submit his payment
> transaction to the network first, knowing that Alice isn't going to try
> to rip him off. Bob can also have a trusted identity which signed the
> contract for the anonymizer transaction, and similarly if he rips Alice
> off, she can publish it for the world to see.
>
> A more subtle effect, is this makes sybil attacks more difficult. To
> pretend to be a thousand identities is going to now require 1,000 * n
> coins, and attempting to pull this attack off inherently strengthens the
> bitcoin network. Obviously we can apply this principle to other things
> like tor nodes as well.
>
> --
> http://petertodd.org 'peter'[:-1]@petertodd.org
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJPmW6EAAoJEH+rEUJn5PoEZfEH/ixptlMX9MzP71bCHMkj7YN1
> y6GEkc1vNhyHu01NX77vzSqR4trbVnWJeJ5hH8EB5tgYRwmI17XoQW6Iz8yEXXgO
> JqUKCTBBexGE+F5RfBkizJ9ap5wXwVrAOIMy/KurSdST+PWMXIPQFaGark01uKcG
> M4VXg3U9fc/0Zz1QyKpRTI5O7ZSBqPzEh/Xf4TujR39nUtaI5mkT/bmA3+Te7oRT
> 34QO7ryF7U001Xz2VJCfm9AE8mPPZjMavLTs/XvPSqTdliVCZpjGGHzcJ2BPrni5
> LEPBsBBxNsuwFGjnRobQwrkPtmYGFntseMLzCJ3iGXWYwedssBg2LLOx9QaXG04=
> =PftQ
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ <https://plus.google.com/112885659993091300749>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120426/cd25bb9f/attachment.html>

2023-06-07 10:03:42

- reply

📅 Original date posted:2012-04-12
📝 Original message:I agree that it would be nice if the protocol stayed stateless.
I also think we should try and keep in our heads the aggregate
bitcoin-universe cost of implementing any protocol change; even a very
small change, something that truly only takes one hour of time from each
bitcoin node client developer to implement, test and bugfix (hah!) Has a
cost in the (tens?) of thousands of USD added up across those who need to
understand, implement, discuss, etc.
Peter
On Thu, Apr 12, 2012 at 10:24 AM, Amir Taaki <zgenjix at yahoo.com> wrote:
> Jeff elaborated the problems very well, but I just want to add this:
>
> Your change is essentially relying (trusting) the server to track a piece
> of information (your state). Anytime you start depending on another node in
> some way, it is opening yourself up to be exploited. Nodes should be doing
> their owning state maintainance, not relying on external parties.
>
>
> I am very much against the change. As someone who has implemented the
> complete bitcoin protocol, I had no problems implementing the blockchain
> download. In fact, I dislike that nodes have to store the last inventory
> they sent as part of a getblocks in order to trigger the next round. It's
> be better if there was no state whatsoever.
>
> ________________________________
> From: Jeff Garzik <jgarzik at exmulti.com>
> To: sirk390 at gmail.com
> Cc: bitcoin-development at lists.sourceforge.net
> Sent: Thursday, April 12, 2012 6:12 PM
> Subject: Re: [Bitcoin-development] Adding request/reply id in messages
>
> On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <sirk390 at gmail.com> wrote:
> > Hi,
> >
> > I would like to discuss the following bitcoin protocol improvement
> proposal:
> >
> > Adding request/reply id in all messages (in the message header,
> > based on what was done for the "checksum" field)
> >
> > The original reason is that I found it very hard to implement robust
> > blockchain downloading as we are missing context information:
> > The download protocol relies on the other peer sending one (or more)
> "inv"
> > reponse(s) to "getblocks" and sending the "hashContinue".
> > But if the other peer doesn't send a response to getblock, send a partial
> > response to getblocks, mixes it with some unrelated blocks inventories
> > or doesn't send the "hashContinue" it is very hard to detect and handle
> > (e.g. ban the peer and switch to another). This could cause some DoS
> > attacks by misbehaving peers.
>
> If the peer is misbehaving, then disconnect. Your protocol change
> does not offer any clear benefits in this area, as these sorts of
> attacks/misbehaviors/bugs are still just as possible, and just as
> damaging (or not).
>
> Just disconnect the strange peer!
>
> > The problems are that 1/ we don't know how many "inv" messages to wait
> for
> > after "getblocks" and 2/ we don't know how to distinguish between result
> of
> > "getblocks" and spontaneous "inv" notifications.
> > The same is true for "addr" messages (it is both a notification and
> reply)
> > but this is less of a problem as a lack of response to getaddr
> > doesn't constitute a DoS.
> >
> > The idea would be to add a new "requestid" field in messages and define
> the
> > following:
>
>
> Stateless protocols have a lot of value. They are easiest to
> implement, and easier to prove correct. Existing clients like
> ArtForz' half-a-node, variants of which are deployed all over the
> place in bitcoin-land, rely on the stateless-ness to one degree or
> another.
>
> Stateful protocols, too, have their problems as well. One must add
> code to help remain "synchronized" between local and remote states,
> which your suggested change only hints at. NFSv4 and RPC have a long
> history of dealing with stateful-ness issues. Obviously bitcoin P2P
> is nowhere near as complex, but the history of NFS development offers
> several lessons applicable to your proposed change.
>
> Overall, IMO your listed reasons for needing this major change
> (stateless->stateful) do not really justify the change. Handling
> initial block download can be accomplished in a number of ways, and
> peer(s) may crash or return odd results. You must handle these cases
> properly, regardless of the presence of req/reply id's.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120412/d5e6f96d/attachment.html>

2023-06-07 10:02:45

- reply

📅 Original date posted:2012-04-03
📝 Original message:I don't think it's minimally invasive to layer PGP's web of trust on top of
Bitcoin, in fact, the opposite.
>From a certain angle, bitcoin exists as a sort of answer / alternate
solution to the web of trust. Digital cash with an existing web of trust in
place was a working concept in the mid-1990s, courtesy of David Chaum, I
believe.
I totally agree on the kitchen sink concern; I would personally like to see
something like a one-year required discussion period on all non-security
changes proposed to the blockchain protocol. We know almost nothing about
how bitcoin will be used over the next 20 years; I believe it's a mistake
to bulk up the protocol too rapidly right now.
There's a famous phrase from the founder of Lotus about Lotus' engineering
process: "add lightness." The equivalent for protocol design might be "add
simplicity." I'd like to see us adding simplicity for now, getting a core
set of tests together for alternate implementations like libbitcoin, and
thinking hard about the dangers of cruft over a 10+ year period when it
comes to a technology which will necessarily include a complete history of
every crufty decision embodied in transaction histories.
Peter
On Tue, Apr 3, 2012 at 1:42 PM, Wladimir <laanwj at gmail.com> wrote:
>
> On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr <luke at dashjr.org> wrote:
>
>> On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
>> > We should avoid reinventing the wheel, if we can. I think we should
>> > extend existing standards whenever possible.
>>
>> I wonder if it's possible to make sigs compatible with PGP/EC ?
>>
>
> Or we could take a step back, further into "don't reinvent the wheel"
> territory. Why not simply make use of PGP(/EC) to sign and verify messages?
> It has many advantages, like an already existing web-of-trust and keyserver
> infrastructure.
>
> I still feel like this is sign message stuff is dragging the kitchen sink
> into Bitcoin. It's fine for logging into a website, what you use it for,
> but anything that approaches signing email (such as S/MIME implementations
> and handling different character encodings) is going too far IMO.
>
> Wladimir
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120403/9e40ceb3/attachment.html>

2023-06-07 03:14:26

- reply

📅 Original date posted:2012-03-22
📝 Original message:This conversation reminds me that I'd like to see a comprehensive list of
tests that alt processors / generators can run against.
I haven't looked in the client code for some time, but does that exist now?
That would be a nice 'I want to help' early project, getting together
inputs and expected outputs / stack states for implementers to check
against.
As it is right now, we've split our codebase a bit; we rely on the client
to check the validity of a transaction, the balance of a given address, and
converse with the network, but we have written most of our own code for
stuff like block gen; I expect we will also do that for transaction
creation.
Peter
2012/3/22 Michael Grønager <gronager at ceptacle.com>
> What you list below was actually the plan - just havn't gotten there yet,
> but it will be dead easy.
>
> /M
>
>
> On 22/03/2012, at 11:50, Martinx - ジェームズ wrote:
>
> > Michael,
> >
> > Since libcoin is "chain agnostic", I was wondering if the project can
> be used like this:
> >
> > When I install it with "make install", I would like to have something
> like this:
> >
> > Regular file: /usr/local/bin/libcoincore # or whatever you like
> >
> > Symlink -> Regular file
> >
> > /usr/local/bit/bitcoind -> /usr/local/bin/libcoincore # bitcoind is a
> symlink to libcoincore
> >
> > /usr/local/bit/litecoind -> /usr/local/bin/libcoincore # litecoind is
> a symlink to libcoincore
> >
> > /usr/local/bit/devcoind -> /usr/local/bin/libcoincore # devcoind is a
> symlink to libcoincore
> >
> > /usr/local/bit/namecoind -> /usr/local/bin/libcoincore # devcoind is
> a symlink to libcoincore
> >
> > ...and so on...
> >
> > So, libcoincore will interpret the ARGV[0] and, for each string, it
> will initiate the appropriate internal functions...
> >
> > I don't know if Libcoin already does something like that... I'm not a
> developer/code reader... Just a small nerd with big ideas... ^_^
> >
> > Thanks!
> > Thiago
> >
> > 2012/2/28 Michael Grønager <gronager at ceptacle.com>
> > Hi again - and thanks for testing and finding this!
> >
> > I have fixed the bug you reported:
> >
> > The culprit was an implicit string constructor for the ChainAddress that
> caused creation of a not fully initialized ChainAddress. The right way to
> do it is using chain::getAddress(string) as the ChainAddress is chain
> specific.
> >
> > A git pull will fix it ;)
> >
> > Cheers,
> >
> > Michael
> >
> >
> > On 27/02/2012, at 20:03, Martinx - ジェームズ wrote:
> >
> > > AWESOME!! Thank you!!
> > >
> > > Anyway, I found a new problem... lol
> > >
> > > /usr/local/bin/bitcoind getinfo #okay
> > > {
> > > "version" : 40001,
> > > "blocks" : 168753,
> > > "connections" : 8,
> > > "difficulty" : 1376302.26788638,
> > > "testnet" : false
> > > }
> > >
> > > /usr/local/bin/bitcoind getaccountaddress "" # okay...
> > > 1J4vNcvEdeCuLH4yvyoC2gxFEF4zquoJ87
> > >
> > > /usr/local/bin/bitcoind listaccounts # NOT okay...
> > > {
> > > }
> > >
> > > /usr/local/bin/bitcoind getaccountaddress "teste" # okay
> > > 1E6pGh6AAtuJdFXheZMp1zdYmvdqAQn9QT
> > >
> > > /usr/local/bin/bitcoind listaccounts # NOT okay...
> > > {
> > > "teste" : 0.00000000
> > > }
> > >
> > > Where is my default account listed at "listaccounts" output?!
> > >
> > > Best,
> > > Thiago
> > >
> > > 2012/2/26 Michael Grønager <gronager at ceptacle.com>
> > > And if you do an update now "help" is there too ;)
> > >
> > > /M
> > >
> > > On 25/02/2012, at 03:11, Martinx - ジェームズ wrote:
> > >
> > >> Thank you!!!
> > >>
> > >> It is all working now! Except "help"...
> > >>
> > >> Nice work Michael!!
> > >>
> > >> Best,
> > >> Thiago
> > >>
> > >> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
> > >> OK - didn't took the weekend:
> > >>
> > >> support for "port" is on github now :)
> > >>
> > >> Only took two lines:
> > >>
> > >> ("port", value<unsigned short>(&port)->default_value(8333),
> "Listen on specified port for the p2p protocol")
> > >>
> > >> and using the port option in the Node constructor (was there already):
> > >>
> > >> Node node(chain, data_dir, args.count("nolisten") ? "" :
> "0.0.0.0", lexical_cast<string>(port)); // it is also here we specify the
> use of a proxy!
> > >>
> > >> /M
> > >>
> > >>
> > >>
> > >> On 24/02/2012, at 19:49, Martinx - ジェームズ wrote:
> > >>
> > >>> Hi Michael,
> > >>>
> > >>> Thank you for your attention!
> > >>>
> > >>> Now, I'm trying to start libcoin's bitcoind using high ports but, it
> always try to listen at 8332, no matter what I "say"...
> > >>>
> > >>> Look:
> > >>>
> > >>> $ cat .bitcoin/bitcoin.conf
> > >>> server=1
> > >>> daemon=1
> > >>> rpcuser=libcoin
> > >>> rpcpassword=LibCoin13
> > >>> rpcport=10332
> > >>> port=10333
> > >>>
> > >>> But:
> > >>>
> > >>> /usr/local/bin/bitcoind
> > >>> Error: Address already in use
> > >>>
> > >>> terminate called after throwing an instance of 'DbException'
> > >>> what(): DbEnv::close: Invalid argument
> > >>> Aborted
> > >>>
> > >>> When I "strace it", I can see:
> > >>>
> > >>> ...
> > >>> bind(12, {sa_family=AF_INET, sin_port=htons(8333),
> sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
> > >>> ...
> > >>>
> > >>> I already tried:
> > >>>
> > >>> /usr/local/bin/bitcoind --rpcport 10332
> > >>> /usr/local/bin/bitcoind --rpcport=10332
> > >>>
> > >>> Without success...
> > >>>
> > >>> Thanks again!
> > >>> Thiago
> > >>>
> > >>> 2012/2/24 Michael Grønager <gronager at ceptacle.com>
> > >>> Hi Thiago,
> > >>>
> > >>> Forgot to comment on the two latter:
> > >>>
> > >>>> $ bitcoind getaccountaddress ""
> > >>>> HTTP error code: 401
> > >>>> Error: couldn't parse reply from server
> > >>>>
> > >>>> $ bitcoind listaccounts
> > >>>> HTTP error code: 401
> > >>>> Error: couldn't parse reply from server
> > >>>>
> > >>>
> > >>> 401 = permission denied - you need to setup username / password
> either on the commandline or in the bicoin.conf file to access those
> commands...
> > >>>
> > >>> See in the bitcoind.cpp file for commands that you can use with and
> without auth...
> > >>>
> > >>> Those that contains an "auth" requires auth:
> > >>>
> > >>> server.registerMethod(method_ptr(new GetBalance(wallet)), auth);
> > >>>
> > >>> As opposed to:
> > >>>
> > >>> server.registerMethod(method_ptr(new GetInfo(node)));
> > >>>
> > >>> auth is defined by:
> > >>>
> > >>> Auth auth(rpc_user, rpc_pass); // if rpc_user and rpc_pass are
> not set, all authenticated methods becomes disallowed.
> > >>>
> > >>> so you just experience the case explained in the comment ;) I admit
> that the output could be more readable, though!
> > >>>
> > >>> /M
> > >>>
> > >>>
> > >>>>
> > >>>> Any tips?! lol
> > >>>>
> > >>>> Thanks!
> > >>>> Thiago
> > >>>>
> > >>>> 2012/2/23 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
> > >>>> AWESOME!!!
> > >>>>
> > >>>> I can compile libcoin at my Ubuntu 11.10... I just need to install:
> > >>>>
> > >>>> sudo aptitude install libboost1.46-all-dev
> > >>>>
> > >>>> ...alongside with another already installed dependencies, and now
> it works!!
> > >>>>
> > >>>> Thank you!
> > >>>> Thiago
> > >>>>
> > >>>> 2012/2/23 Michael Grønager <gronager at ceptacle.com>
> > >>>> Hi Martinx,
> > >>>>
> > >>>> Another note:
> > >>>>
> > >>>> boost 1.42 and openssl 1.0 has a conflict (you will see it when you
> try to compile coinHTTP with that specific combination: sslv2 has been
> removed from openssl, but boost still references it.)
> > >>>>
> > >>>> You should do a :
> > >>>>
> > >>>> sudo apt-get upgrade libboost-dev-all
> > >>>>
> > >>>> to get the 1.46.1 library
> > >>>>
> > >>>> /M
> > >>>>
> > >>>>
> > >>>> On 23/02/2012, at 18:31, Martinx - ジェームズ wrote:
> > >>>>
> > >>>>> Hi Michael!
> > >>>>>
> > >>>>> Thank you for libcoin! It is a awesome evolution for Bitcoin and
> for the CryptoCurrencies as a hole... Thanks!!!
> > >>>>>
> > >>>>> Anyway, I am unable to compile libcoin under my Ubuntu 11.04. At
> this machine, I have compiled and running Bitcoin (from sources), Namecoin,
> Devcoin, Litecoin, IXcoin and I0coin, all from sources but, when I try to
> compile libcoin, I got:
> > >>>>>
> > >>>>> ----
> > >>>>> user at desk:~/libcoin$ ./configure
> > >>>>> -- The C compiler identification is GNU
> > >>>>> -- The CXX compiler identification is GNU
> > >>>>> -- Check for working C compiler: /usr/bin/gcc
> > >>>>> -- Check for working C compiler: /usr/bin/gcc -- works
> > >>>>> -- Detecting C compiler ABI info
> > >>>>> -- Detecting C compiler ABI info - done
> > >>>>> -- Check for working CXX compiler: /usr/bin/c++
> > >>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
> > >>>>> -- Detecting CXX compiler ABI info
> > >>>>> -- Detecting CXX compiler ABI info - done
> > >>>>> -- Looking for include files CMAKE_HAVE_PTHREAD_H
> > >>>>> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
> > >>>>> -- Looking for pthread_create in pthreads
> > >>>>> -- Looking for pthread_create in pthreads - not found
> > >>>>> -- Looking for pthread_create in pthread
> > >>>>> -- Looking for pthread_create in pthread - found
> > >>>>> -- Found Threads: TRUE
> > >>>>> -- Looking for XOpenDisplay in
> /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
> > >>>>> -- Looking for XOpenDisplay in
> /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
> > >>>>> -- Looking for gethostbyname
> > >>>>> -- Looking for gethostbyname - found
> > >>>>> -- Looking for connect
> > >>>>> -- Looking for connect - found
> > >>>>> -- Looking for remove
> > >>>>> -- Looking for remove - found
> > >>>>> -- Looking for shmat
> > >>>>> -- Looking for shmat - found
> > >>>>> -- Looking for IceConnectionNumber in ICE
> > >>>>> -- Looking for IceConnectionNumber in ICE - found
> > >>>>> -- Found X11: /usr/lib/i386-linux-gnu/libX11.so
> > >>>>> -- Boost version: 1.42.0
> > >>>>> -- Found the following Boost libraries:
> > >>>>> -- date_time
> > >>>>> -- regex
> > >>>>> -- filesystem
> > >>>>> -- system
> > >>>>> -- program_options
> > >>>>> -- thread
> > >>>>> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so
> > >>>>> -- Looking for Q_WS_X11
> > >>>>> -- Looking for Q_WS_X11 - found
> > >>>>> -- Looking for Q_WS_WIN
> > >>>>> -- Looking for Q_WS_WIN - not found.
> > >>>>> -- Looking for Q_WS_QWS
> > >>>>> -- Looking for Q_WS_QWS - not found.
> > >>>>> -- Looking for Q_WS_MAC
> > >>>>> -- Looking for Q_WS_MAC - not found.
> > >>>>> -- Found Qt-Version 4.7.2 (using /usr/bin/qmake)
> > >>>>> -- Found wxWidgets: TRUE
> > >>>>>
> > >>>>> The build system is configured to install libraries to
> /usr/local/lib
> > >>>>> Your applications may not be able to find your installed libraries
> unless you:
> > >>>>> set your LD_LIBRARY_PATH (user specific) or
> > >>>>> update your ld.so configuration (system wide)
> > >>>>> You have an ld.so.conf.d directory on your system, so if you wish
> to ensure that
> > >>>>> applications find the installed libcoin libraries, system wide,
> you could install an
> > >>>>> libcoin specific ld.so configuration with:
> > >>>>> sudo make install_ld_conf
> > >>>>>
> > >>>>> -- Configuring done
> > >>>>> -- Generating done
> > >>>>> -- Build files have been written to: /home/user/libcoin
> > >>>>> ----
> > >>>>>
> > >>>>> Now I tried make, without success:
> > >>>>>
> > >>>>> ----
> > >>>>> .....
> > >>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xf):
> undefined reference to `BN_init'
> > >>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x1e):
> undefined reference to `BN_copy'
> > >>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x38):
> undefined reference to `BN_set_negative'
> > >>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0x4f):
> undefined reference to `BN_clear_free'
> > >>>>> Script.cpp:(.text._ZngRK7CBigNum[operator-(CBigNum const&)]+0xd3):
> undefined reference to `BN_clear_free'
> > >>>>> ../../lib/libcoin.a(Script.o): In function `operator<<(CBigNum
> const&, unsigned int)':
> > >>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&,
> unsigned int)]+0x16): undefined reference to `BN_init'
> > >>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&,
> unsigned int)]+0x2c): undefined reference to `BN_lshift'
> > >>>>> Script.cpp:(.text._ZlsRK7CBigNumj[operator<<(CBigNum const&,
> unsigned int)]+0xad): undefined reference to `BN_clear_free'
> > >>>>> ../../lib/libcoin.a(Script.o): In function `operator>>(CBigNum
> const&, unsigned int)':
> > >>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&,
> unsigned int)]+0xf): undefined reference to `BN_init'
> > >>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&,
> unsigned int)]+0x1e): undefined reference to `BN_copy'
> > >>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&,
> unsigned int)]+0x47): undefined reference to `BN_clear_free'
> > >>>>> Script.cpp:(.text._ZrsRK7CBigNumj[operator>>(CBigNum const&,
> unsigned int)]+0xcb): undefined reference to `BN_clear_free'
> > >>>>> ../../lib/libcoin.a(Script.o): In function `operator!=(CBigNum
> const&, CBigNum const&)':
> > >>>>> Script.cpp:(.text._ZneRK7CBigNumS1_[operator!=(CBigNum const&,
> CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> > >>>>> ../../lib/libcoin.a(Script.o): In function `operator>(CBigNum
> const&, CBigNum const&)':
> > >>>>> Script.cpp:(.text._ZgtRK7CBigNumS1_[operator>(CBigNum const&,
> CBigNum const&)]+0x14): undefined reference to `BN_cmp'
> > >>>>> ../../lib/libcoin.a(Script.o): In function `uint256
> Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned
> char, std::allocator<unsigned char> > >
> >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char,
> std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned
> char*, std::vector<unsigned char, std::allocator<unsigned char> > >)':
> > >>>>>
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256
> Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned
> char, std::allocator<unsigned char> > >
> >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char,
> std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned
> char*, std::vector<unsigned char, std::allocator<unsigned char> >
> >)]+0x6d): undefined reference to `SHA256'
> > >>>>>
> Script.cpp:(.text._Z4HashIN9__gnu_cxx17__normal_iteratorIPhSt6vectorIhSaIhEEEEE7uint256T_S8_[uint256
> Hash<__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned
> char, std::allocator<unsigned char> > >
> >(__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char,
> std::allocator<unsigned char> > >, __gnu_cxx::__normal_iterator<unsigned
> char*, std::vector<unsigned char, std::allocator<unsigned char> >
> >)]+0xb8): undefined reference to `SHA256'
> > >>>>> collect2: ld returned 1 exit status
> > >>>>> make[2]: *** [bin/bitcoind] Error 1
> > >>>>> make[1]: ***
> [applications/bitcoind/CMakeFiles/app_bitcoind.dir/all] Error 2
> > >>>>> make: *** [all] Error 2
> > >>>>> -----
> > >>>>>
> > >>>>> What can I do?!
> > >>>>>
> > >>>>> Best,
> > >>>>> Thiago
> > >>>>>
> > >>>>>
> > >>>>> On 1 February 2012 12:18, Michael Grønager <gronager at ceptacle.com>
> wrote:
> > >>>>> Dear Bitcoiners,
> > >>>>>
> > >>>>> libcoin is now in a state ready for its first release, which I
> would like to share with you!
> > >>>>>
> > >>>>> === libcoin is a crypto currency library based on the
> bitcoin/bitcoin "Satoshi" client. ===
> > >>>>>
> > >>>>> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the
> release of the first version of the crypto currency library "libcoin" based
> on the bitcoin/bitcoin "Satoshi" client.
> > >>>>>
> > >>>>> libcoin also maintains a version of bitcoind that is a 100%
> compatible drop-in replacement of the bitcoin/bitcoind client: You can use
> it on the same computer on the same files and you can call it with the same
> scripts. And you can easily extend it without touching the basic bitcoin
> source files.
> > >>>>>
> > >>>>> The libcoin/bitcoind client downloads the entire block chain 3.5
> times faster than the bitcoin/bitcoind client. This is less than 90 minutes
> on a modern laptop!
> > >>>>>
> > >>>>> In libcoin, the Satoshi client code has been completely
> refactored, properly encapsulating classes, removing all globals, moving
> from threads and mutexes to a pure asynchronous approach. Functionalities
> have been divided into logical units and libraries, minimizing dependencies
> for e.g. thin clients.
> > >>>>>
> > >>>>> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin,
> litecoin, ...) specific settings are maintained from a single class (Chain)
> and hence experiments with chain settings, mining, security and digital
> currencies for research and educational purposes are easily accessible. See
> the ponzicoin example for how you define your own chain.
> > >>>>>
> > >>>>> The build system of libcoin is based on CMake and supports builds
> of static and dynamic libraries on Linux, Mac OS X, and Windows.
> > >>>>>
> > >>>>> The libcoin license is LGPL v. 3. This mean that you can use it in
> open source as well as in commercial projects, but improvements should go
> back into the libcoin library.
> > >>>>>
> > >>>>> ======
> > >>>>>
> > >>>>> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
> > >>>>>
> > >>>>> Join libcoin on twitter: http://twitter.com/libcoin
> > >>>>>
> > >>>>> Download "libcoin Satoshi release":
> http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
> > >>>>>
> > >>>>> Best regards,
> > >>>>>
> > >>>>> Michael Gronager, PhD
> > >>>>> Director, Ceptacle
> > >>>>> Jens Juels Gade 33
> > >>>>> 2100 Copenhagen E
> > >>>>> Mobile: +45 31 45 14 01
> > >>>>> E-mail: gronager at ceptacle.com
> > >>>>> Web: http://www.ceptacle.com/
> > >>>>>
> > >>>>>
> > >>>>>
> ------------------------------------------------------------------------------
> > >>>>> Keep Your Developer Skills Current with LearnDevNow!
> > >>>>> The most comprehensive online learning library for Microsoft
> developers
> > >>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
> MVC3,
> > >>>>> Metro Style Apps, more. Free future releases when you subscribe
> now!
> > >>>>> http://p.sf.net/sfu/learndevnow-d2d
> > >>>>> _______________________________________________
> > >>>>> Bitcoin-development mailing list
> > >>>>> Bitcoin-development at lists.sourceforge.net
> > >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >>>>>
> > >>>>
> > >>>> Michael Gronager, PhD
> > >>>> Director, Ceptacle
> > >>>> Jens Juels Gade 33
> > >>>> 2100 Copenhagen E
> > >>>> Mobile: +45 31 45 14 01
> > >>>> E-mail: gronager at ceptacle.com
> > >>>> Web: http://www.ceptacle.com/
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >> Michael Gronager, PhD
> > >> Director, Ceptacle
> > >> Jens Juels Gade 33
> > >> 2100 Copenhagen E
> > >> Mobile: +45 31 45 14 01
> > >> E-mail: gronager at ceptacle.com
> > >> Web: http://www.ceptacle.com/
> > >>
> > >>
> > >
> > > Michael Gronager, PhD
> > > Director, Ceptacle
> > > Jens Juels Gade 33
> > > 2100 Copenhagen E
> > > Mobile: +45 31 45 14 01
> > > E-mail: gronager at ceptacle.com
> > > Web: http://www.ceptacle.com/
> > >
> > >
> >
> > Michael Gronager, PhD
> > Director, Ceptacle
> > Jens Juels Gade 33
> > 2100 Copenhagen E
> > Mobile: +45 31 45 14 01
> > E-mail: gronager at ceptacle.com
> > Web: http://www.ceptacle.com/
> >
> >
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120322/337a4904/attachment.html>

2023-06-07 02:56:56

- reply

📅 Original date posted:2012-01-17
📝 Original message:It seems to me that the internet as a whole has got this one covered. I say
this as someone who thinks that BitCoin needs to choose its battles and
craft its reputation extremely carefully; this isn't the most important
fight for BitCoin, nor the most deadly.
I do think SOPA and PIPA could impact bitcoin, what if, for instance,
copyrighted material made its way into the blockchain?
Already the DMCA would make it hard for someone publishing blocks online to
do anything but cease under a DMCA request. SOPA, at least, would go
farther and allow the US to cut all access to 'offending' sites elsewhere
in the world.
At any rate, I don't think these bills are 'aimed at' BitCoin, and the
companies with the most stake are taking the threat quite seriously.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120117/d31607be/attachment.html>