Re: [Bitcoin-development] Duplicate transactions vulnerability
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille wrote: > Hello all, > > I've written about it in BIP30[2]. There is a patch for the reference > client, which has been tested and verified to make the attack > impossible. The change is backward compatible in the same way BIP16 > is: if a supermajority of mining power implements it, old clients can > continue to function without risk. After getting responses from Deepbit, bitcoin.cz (slush), MtRed, Bitlc and BTCmine, it looks like march 15 is a reasonable deployment date for the security update described in BIP 30. I have created patches for: * git master: https://github.com/sipa/bitcoin/tree/nooverwritetx * v0.4.0: https://github.com/sipa/bitcoin/tree/nooverwritetx_v0.4.0 * v0.3.24: https://github.com/sipa/bitcoin/tree/nooverwritetx_v0.3.24 * v0.3.24+vinced: https://github.com/sipa/bitcoin/tree/nooverwritetx_v0.3.24+vinced * v0.3.19: https://github.com/sipa/bitcoin/tree/nooverwritetx_v0.3.19 I've asked pool operators to upgrade, and confirm when they have done so. If you are a miner or pool operator, and have the ability to upgrade, please do so as well. Thanks, -- Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille wrote: > I've written about it in BIP30[2]. There is a patch for the reference > client, which has been tested and verified to make the attack > impossible. The change is backward compatible in the same way BIP16 > is: if a supermajority of mining power implements it, old clients can > continue to function without risk. After some private discussion, Ben Reeves pointed out two potential small weaknesses in the proposed patch, which seem viable to me. First: disconnecting the same coinbase transaction twice would fail, as EraseTxIndex will not find anything the second time. This is extremely hard to pull off, as it requires reverting a chain of at least 120 blocks long. Still, the fix is very easy imho: allow EraseTxIndex to fail. Second: assume the following order of events: block with coinbase A is created, 120 blocks later, A:0 is spent in transaction B. Then, a dupe of A is created, and another 120 blocks are waited. At this point, A:0 and B:0 are still spendable. Now a block is created with two transactions: first C which spends B:0, followed by a dupe of B. This dupe is accepted, as its former instance is completely spent now. However, if this last block is disconnected again, B:0 is not spendable anymore, causing a risk for chain split. Ben suggested moving the check for dupes up, turning the new network rule into: Blocks are not allowed to contain transactions whose hash matches that of an earlier transaction in the same chain, unless that transaction was already completely spent before said block. I've updated the patch, and will update the BIP soon. What do you all think? Can we still move forward with deploying this? -- Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
>I am not following you here, can you explain what you're thinking? If I mine a duplicate coinbase of an old block (whether spent or not) if that block is then invalidated DisconnectBlock() will erase both the coinbase of the new block and of the old block. This leaves the blockchain is in an inconsistent state because with the coinbase missing the old block will no longer pass CheckBlock(). When affected clients are restarted LoadBlockIndex() will try and verify all blocks in the main chain, failing at the block with the missing coinbase. 1) If an attacker was to do this with an early block it would force all affected clients to redownload the majority of the blockchain. 2) If the attacker was able to do this on a block after the March 1st deadline (future block A). If they mined a fake copy of block A (block B) with the same coinbase but a different hash clients who received block B before block A will refuse to accept block A because of the unspent duplicate coinbase in block B. The attacker can then fork the chain at this point despite the real chain being longer. I am just think out load here so I could be wrong, but maybe it would be better to go for the full block height fix now? On Thu, Mar 1, 2012 at 2:27 PM, Gregory Maxwell wrote: > On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves wrote: >> One more thing to add. The implementation in the reference patch fixes >> the blockchain forking issue however by still allowing spent coinbases >> to be disconnected patched clients are still vulnerable to blockchain >> corruption. While not an immediate issue it would mean >> LoadBlockIndex() would error on restart and could cause problems for >> new clients during the initial blockchain download. > > I am not following you here, can you explain what you're thinking? > >> Is there a reason not to disallow duplicate coinbases entirely? > > Because this would make it impossible for nodes to prune the vaules. > They'd all forever have to keep a set of all the coinbase hashes in > order to perform the test. The height-in-coinbase BIP will make > duplicates effectively impossible to create, which is a much more > clean behavior. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Thu, Mar 01, 2012 at 01:09:02PM +, Ben Reeves wrote: > One more thing to add. The implementation in the reference patch fixes > the blockchain forking issue however by still allowing spent coinbases > to be disconnected patched clients are still vulnerable to blockchain > corruption. While not an immediate issue it would mean > LoadBlockIndex() would error on restart and could cause problems for > new clients during the initial blockchain download. I don't understand this. > Is there a reason not to disallow duplicate coinbases entirely? Just disallowing duplicate coinbases is possible, but it requires keeping a set of all coinbases transaction around until infinity. That's not really a problem, but it can be avoided. One very reasonable proposed solution is adding the block height to the coinbase. However, as coinbases are used for all kinds of things already, this is harder to roll out network-wide. Hence, first this "emergency" solution that already prevents (afaik) all practical attacks, and in a later step forcing unique coinbases, so that transactions can be assumed to be unique identifiable by their hash again. -- Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves wrote: > One more thing to add. The implementation in the reference patch fixes > the blockchain forking issue however by still allowing spent coinbases > to be disconnected patched clients are still vulnerable to blockchain > corruption. While not an immediate issue it would mean > LoadBlockIndex() would error on restart and could cause problems for > new clients during the initial blockchain download. I am not following you here, can you explain what you're thinking? > Is there a reason not to disallow duplicate coinbases entirely? Because this would make it impossible for nodes to prune the vaules. They'd all forever have to keep a set of all the coinbase hashes in order to perform the test. The height-in-coinbase BIP will make duplicates effectively impossible to create, which is a much more clean behavior. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
One more thing to add. The implementation in the reference patch fixes the blockchain forking issue however by still allowing spent coinbases to be disconnected patched clients are still vulnerable to blockchain corruption. While not an immediate issue it would mean LoadBlockIndex() would error on restart and could cause problems for new clients during the initial blockchain download. Is there a reason not to disallow duplicate coinbases entirely? On Thu, Mar 1, 2012 at 10:15 AM, Ben Reeves wrote: > Yes you are right. Any fix in DisconnectBlock() has the same potential issues. > > I think the exchanges and major merchants need to be made aware that > they must also upgrade. Maybe bundle both BIP16 and BIP30 in 0.6 and > issue an advisory stating that this is a mandatory upgrade for > everyone. > > It also might be prudent to have a blockchain repair script ready, > which checks the db for missing coinbase transactions and downloads > them from another peer or block explorer if necessary. > > Thank You, > Ben Reeves > www.blockchain.info > > On Wed, Feb 29, 2012 at 11:45 PM, Pieter Wuille > wrote: >> On Wed, Feb 29, 2012 at 11:00:42PM +, Ben Reeves wrote: >>> I'm not sure. What if they use a coinbase of a block that has already >>> matured? >> >> Indeed; duplicate an old coinbase, fork chain without dupe, and spend the >> old coinbase. >> The 100-blocks maturity will not help against is. >> >> I'm not sure how you intend to fix DisconnectBlock() to prevent this in a >> backward- >> compatible way, though. >> >> -- >> Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
Yes you are right. Any fix in DisconnectBlock() has the same potential issues. I think the exchanges and major merchants need to be made aware that they must also upgrade. Maybe bundle both BIP16 and BIP30 in 0.6 and issue an advisory stating that this is a mandatory upgrade for everyone. It also might be prudent to have a blockchain repair script ready, which checks the db for missing coinbase transactions and downloads them from another peer or block explorer if necessary. Thank You, Ben Reeves www.blockchain.info On Wed, Feb 29, 2012 at 11:45 PM, Pieter Wuille wrote: > On Wed, Feb 29, 2012 at 11:00:42PM +, Ben Reeves wrote: >> I'm not sure. What if they use a coinbase of a block that has already >> matured? > > Indeed; duplicate an old coinbase, fork chain without dupe, and spend the old > coinbase. > The 100-blocks maturity will not help against is. > > I'm not sure how you intend to fix DisconnectBlock() to prevent this in a > backward- > compatible way, though. > > -- > Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Wed, Feb 29, 2012 at 11:00:42PM +, Ben Reeves wrote: > I'm not sure. What if they use a coinbase of a block that has already matured? Indeed; duplicate an old coinbase, fork chain without dupe, and spend the old coinbase. The 100-blocks maturity will not help against is. I'm not sure how you intend to fix DisconnectBlock() to prevent this in a backward- compatible way, though. -- Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
I'm not sure. What if they use a coinbase of a block that has already matured? On Wed, Feb 29, 2012 at 10:46 PM, Gavin Andresen wrote: > On Wed, Feb 29, 2012 at 5:05 PM, Ben Reeves wrote: >> A malicious miner can produce a duplicate coinbase which the majority >> of clients will accept but the majority of hashing power won't. >> Spending the coinbase output after > > That can't happen until the coinbase matures, which takes 100 blocks. > And it won't mature because a majority of hashing power is rejecting > it, right? > > -- > -- > Gavin Andresen -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Wed, Feb 29, 2012 at 5:05 PM, Ben Reeves wrote: > A malicious miner can produce a duplicate coinbase which the majority > of clients will accept but the majority of hashing power won't. > Spending the coinbase output after That can't happen until the coinbase matures, which takes 100 blocks. And it won't mature because a majority of hashing power is rejecting it, right? -- -- Gavin Andresen -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
In other words when we roll out the update, we have to make sure we have >>50% not just 50%. Something like 60%-75% should do fine (IMHO). In other words we just have to be very, very vocal about the change when it happens and make sure miners are all on board. Matt On Wed, 2012-02-29 at 22:05 +, Ben Reeves wrote: > Assuming 50% of hashing power adopts BIP30 but the actual client > install base is relatively low the patch will likely result in a > "hard" blockchain split if someone takes advantage. > > A malicious miner can produce a duplicate coinbase which the majority > of clients will accept but the majority of hashing power won't. > Spending the coinbase output after disconnection will cause the > blockchain to fork. All none BIP30 clients on the short blockchain > will be vulnerable to transaction reversal of 6 confirmations or more. > > It is a relatively inexpensive attack to perform (costing the attacker > only one valid block ~$240) and could be quite disruptive. I think > this should be patched in DisconnectBlock() (if it hasn't already?) > before any protocol change - maybe a new mapByCoinbase multimap is > needed. > > Thank You, > Ben Reeves > www.blockchain.info > > On Tue, Feb 28, 2012 at 4:48 PM, Pieter Wuille > wrote: > > Hello all, > > > > as some of you may know, a vulnerability has been found in how the > > Bitcoin reference client deals with duplicate transactions. Exploiting > > it is rather complex, requires some hash power, and has no financial > > benefit for the attacker. Still, it's a security hole, and we'd like > > to fix this as soon as possible. > > > > A simple way to fix this, is adding an extra protocol rule[1]: > > > > Do not allow blocks to contain a transaction whose hash is equal to > > that of a former transaction which has not yet been completely spent. > > > > I've written about it in BIP30[2]. There is a patch for the reference > > client, which has been tested and verified to make the attack > > impossible. The change is backward compatible in the same way BIP16 > > is: if a supermajority of mining power implements it, old clients can > > continue to function without risk. > > > > The purpose of this mail is asking for support for adding this rule to > > the protocol rules. If there is consensus this rule is the solution, I > > hope pools and miners can agree to update their nodes without lengthy > > coinbase-flagging procedure that would only delay a solution. So, who > > is in favor? > > > > [1] https://en.bitcoin.it/wiki/Protocol_rules > > [2] https://en.bitcoin.it/wiki/BIP_0030 > > > > -- > > Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
Assuming 50% of hashing power adopts BIP30 but the actual client install base is relatively low the patch will likely result in a "hard" blockchain split if someone takes advantage. A malicious miner can produce a duplicate coinbase which the majority of clients will accept but the majority of hashing power won't. Spending the coinbase output after disconnection will cause the blockchain to fork. All none BIP30 clients on the short blockchain will be vulnerable to transaction reversal of 6 confirmations or more. It is a relatively inexpensive attack to perform (costing the attacker only one valid block ~$240) and could be quite disruptive. I think this should be patched in DisconnectBlock() (if it hasn't already?) before any protocol change - maybe a new mapByCoinbase multimap is needed. Thank You, Ben Reeves www.blockchain.info On Tue, Feb 28, 2012 at 4:48 PM, Pieter Wuille wrote: > Hello all, > > as some of you may know, a vulnerability has been found in how the > Bitcoin reference client deals with duplicate transactions. Exploiting > it is rather complex, requires some hash power, and has no financial > benefit for the attacker. Still, it's a security hole, and we'd like > to fix this as soon as possible. > > A simple way to fix this, is adding an extra protocol rule[1]: > > Do not allow blocks to contain a transaction whose hash is equal to > that of a former transaction which has not yet been completely spent. > > I've written about it in BIP30[2]. There is a patch for the reference > client, which has been tested and verified to make the attack > impossible. The change is backward compatible in the same way BIP16 > is: if a supermajority of mining power implements it, old clients can > continue to function without risk. > > The purpose of this mail is asking for support for adding this rule to > the protocol rules. If there is consensus this rule is the solution, I > hope pools and miners can agree to update their nodes without lengthy > coinbase-flagging procedure that would only delay a solution. So, who > is in favor? > > [1] https://en.bitcoin.it/wiki/Protocol_rules > [2] https://en.bitcoin.it/wiki/BIP_0030 > > -- > Pieter > > -- > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
> The purpose of this mail is asking for support for adding this rule to > the protocol rules. If there is consensus this rule is the solution, I > hope pools and miners can agree to update their nodes without lengthy > coinbase-flagging procedure that would only delay a solution. So, who > is in favor? Looks good to me. I also second the notion that we should deploy this quickly, given that it's a bug fix. On 2/28/2012 5:48 PM, Pieter Wuille wrote: > Hello all, > > as some of you may know, a vulnerability has been found in how the > Bitcoin reference client deals with duplicate transactions. Exploiting > it is rather complex, requires some hash power, and has no financial > benefit for the attacker. Still, it's a security hole, and we'd like > to fix this as soon as possible. > > A simple way to fix this, is adding an extra protocol rule[1]: > >Do not allow blocks to contain a transaction whose hash is equal to > that of a former transaction which has not yet been completely spent. > > I've written about it in BIP30[2]. There is a patch for the reference > client, which has been tested and verified to make the attack > impossible. The change is backward compatible in the same way BIP16 > is: if a supermajority of mining power implements it, old clients can > continue to function without risk. > > The purpose of this mail is asking for support for adding this rule to > the protocol rules. If there is consensus this rule is the solution, I > hope pools and miners can agree to update their nodes without lengthy > coinbase-flagging procedure that would only delay a solution. So, who > is in favor? > >[1] https://en.bitcoin.it/wiki/Protocol_rules >[2] https://en.bitcoin.it/wiki/BIP_0030 > -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
I support BIP 30. I gave it a thought. The other ways of resolving this issue, all have various niggles. This is the best way. From: Pieter Wuille To: Zooko Wilcox-O'Hearn Cc: Bitcoin Dev Sent: Wednesday, February 29, 2012 4:47 PM Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote: > Could you spell out the attack explicitly? Presumably there aren't a > lot of people with the "malice energy" to perform the attack but not > to figure it out for themselves. I, however, have the "niceness > energy" to think about it for a few minutes but not to figure it out > for myself. If in your opinion it is realistically dangerous to post > it publicly, would you be so kind as to include me in the private > sharing of the explanation? It's not exactly a secret anymore, as the patch also references it. Russell O'Connor described the attack on his blog: http://r6.ca/blog/20120206T005236Z.html -- Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote: > Could you spell out the attack explicitly? Presumably there aren't a > lot of people with the "malice energy" to perform the attack but not > to figure it out for themselves. I, however, have the "niceness > energy" to think about it for a few minutes but not to figure it out > for myself. If in your opinion it is realistically dangerous to post > it publicly, would you be so kind as to include me in the private > sharing of the explanation? It's not exactly a secret anymore, as the patch also references it. Russell O'Connor described the attack on his blog: http://r6.ca/blog/20120206T005236Z.html -- Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
Could you spell out the attack explicitly? Presumably there aren't a lot of people with the "malice energy" to perform the attack but not to figure it out for themselves. I, however, have the "niceness energy" to think about it for a few minutes but not to figure it out for myself. If in your opinion it is realistically dangerous to post it publicly, would you be so kind as to include me in the private sharing of the explanation? By the way, I found a couple of cases of slightly bad handling of merkle trees when I inspected the code (v0.4) that was, I'm 99% sure, not exploitable. I never got around to reporting it yet. I'm sorry about that. My discoveries might interact with the one you're talking about here. I should definitely explain mine to y'all soon. (Possibly in private for the first pass, in case it is more exploitable than I thought, or has become exploitable since v0.4.) I showed it to a couple of other people at the time who helped me make sure that it wasn't exploitable. I'll make time to explain what I found within a week. Regards, Zooko -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
I might be wrong but I think perhaps it would help to get this fix out before the p2sh protocol change. Otherwise a miner could combine a duplicate coinbase and an invalid P2SH transaction to create a block which can have excellent network propagation and still be guaranteed to be orphaned. This makes the attack significantly easier to perform. If someone were to do this on the day of the P2SH switchover they could corrupt the database of all clients < 0.6 with only a single block. If it was done on an early block and was widespread enough it would make it difficult for new clients to find a genuine non-corrupted copy of the blockchain to download. Thank You, Ben Reeves www.blockchain.info On 28 Feb 2012, at 18:23, Luke-Jr wrote: > On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote: >> A simple way to fix this, is adding an extra protocol rule[1]: >> >> Do not allow blocks to contain a transaction whose hash is equal to >> that of a former transaction which has not yet been completely spent. >> >> I've written about it in BIP30[2]. There is a patch for the reference >> client, which has been tested and verified to make the attack >> impossible. > > Has it been verified to make even rocconor's complicated transaction-based > version impossible? > >> The purpose of this mail is asking for support for adding this rule to >> the protocol rules. If there is consensus this rule is the solution, I >> hope pools and miners can agree to update their nodes without lengthy >> coinbase-flagging procedure that would only delay a solution. So, who >> is in favor? > > Can we do this in two steps? First, prefer blocks which don't break the rule; > once 55%+ are confirmed to have upgraded, then it is safe to treat it as a > hard rule. > > -- > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Tue, Feb 28, 2012 at 01:23:01PM -0500, Luke-Jr wrote: > Has it been verified to make even rocconor's complicated transaction-based > version impossible? Yes, he tried it on testnet against a patched node. > > The purpose of this mail is asking for support for adding this rule to > > the protocol rules. If there is consensus this rule is the solution, I > > hope pools and miners can agree to update their nodes without lengthy > > coinbase-flagging procedure that would only delay a solution. So, who > > is in favor? > > Can we do this in two steps? First, prefer blocks which don't break the rule; > once 55%+ are confirmed to have upgraded, then it is safe to treat it as a > hard rule. I prefer to avoid this if possible, as it increases the size of the patch significantly. In particular, it would require the discouragement-system to be backported to whatever versions pools are running. The current proposal only requires adding 6 lines of code. -- Pieter -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote: > A simple way to fix this, is adding an extra protocol rule[1]: > > Do not allow blocks to contain a transaction whose hash is equal to > that of a former transaction which has not yet been completely spent. > > I've written about it in BIP30[2]. There is a patch for the reference > client, which has been tested and verified to make the attack > impossible. Has it been verified to make even rocconor's complicated transaction-based version impossible? > The purpose of this mail is asking for support for adding this rule to > the protocol rules. If there is consensus this rule is the solution, I > hope pools and miners can agree to update their nodes without lengthy > coinbase-flagging procedure that would only delay a solution. So, who > is in favor? Can we do this in two steps? First, prefer blocks which don't break the rule; once 55%+ are confirmed to have upgraded, then it is safe to treat it as a hard rule. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
> > The purpose of this mail is asking for support for adding this rule to > the protocol rules. If there is consensus this rule is the solution, I > hope pools and miners can agree to update their nodes without lengthy > coinbase-flagging procedure that would only delay a solution. So, who > is in favor? Pieter > Most of you might already know this, but I'm strongly in favor of doing this as soon as possible. -- -- Gavin Andresen -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On Tue, Feb 28, 2012 at 18:12, Brautigam Róbert wrote: >> A simple way to fix this, is adding an extra protocol rule[1]: >> >> Do not allow blocks to contain a transaction whose hash is equal to >> that of a former transaction which has not yet been completely spent. > > I don't know whether I understand this correctly, but there should be no > duplicate transaction hashes at all. So the rule should be: Do not allow > blocks to contain transaction hashes which are already present in that > branch. As explained in the BIP, that would prevent pruning, as it would require each full node to keep a database with all transaction hashes ever. > If by a freak accident a transaction has the same hash as another > transaction in the chain, shouldn't the transaction be "tweaked" in some > way to avoid collision (generate a new target address for it or > something)? In any case this seams very-very unlikely to happen, or am I > missing something? It won't happen by accident. Duplicate coinbase transactions are possible however (by badly written software, or malicious intent). Transactions that spend duplcate coinbases can be made to have the same hash as well. -- Pieter -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Duplicate transactions vulnerability
On 02/28/2012 05:48 PM, Pieter Wuille wrote: > Hello all, Hi, > as some of you may know, a vulnerability has been found in how the > Bitcoin reference client deals with duplicate transactions. Exploiting > it is rather complex, requires some hash power, and has no financial > benefit for the attacker. Still, it's a security hole, and we'd like > to fix this as soon as possible. > > A simple way to fix this, is adding an extra protocol rule[1]: > >Do not allow blocks to contain a transaction whose hash is equal to > that of a former transaction which has not yet been completely spent. I don't know whether I understand this correctly, but there should be no duplicate transaction hashes at all. So the rule should be: Do not allow blocks to contain transaction hashes which are already present in that branch. If by a freak accident a transaction has the same hash as another transaction in the chain, shouldn't the transaction be "tweaked" in some way to avoid collision (generate a new target address for it or something)? In any case this seams very-very unlikely to happen, or am I missing something? Robert. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Duplicate transactions vulnerability
Hello all, as some of you may know, a vulnerability has been found in how the Bitcoin reference client deals with duplicate transactions. Exploiting it is rather complex, requires some hash power, and has no financial benefit for the attacker. Still, it's a security hole, and we'd like to fix this as soon as possible. A simple way to fix this, is adding an extra protocol rule[1]: Do not allow blocks to contain a transaction whose hash is equal to that of a former transaction which has not yet been completely spent. I've written about it in BIP30[2]. There is a patch for the reference client, which has been tested and verified to make the attack impossible. The change is backward compatible in the same way BIP16 is: if a supermajority of mining power implements it, old clients can continue to function without risk. The purpose of this mail is asking for support for adding this rule to the protocol rules. If there is consensus this rule is the solution, I hope pools and miners can agree to update their nodes without lengthy coinbase-flagging procedure that would only delay a solution. So, who is in favor? [1] https://en.bitcoin.it/wiki/Protocol_rules [2] https://en.bitcoin.it/wiki/BIP_0030 -- Pieter -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development