Re: [Bitcoin-development] Duplicate transactions vulnerability
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille pieter.wui...@gmail.com 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
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 pieter.wui...@gmail.com 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
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 supp...@pi.uk.com 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 pieter.wui...@gmail.com 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 Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves supp...@pi.uk.com 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
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 gmaxw...@gmail.com wrote: On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves supp...@pi.uk.com 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 Tue, Feb 28, 2012 at 17:48, Pieter Wuille pieter.wui...@gmail.com 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
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
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 pieter.wui...@gmail.com To: Zooko Wilcox-O'Hearn zo...@zooko.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net 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 Wed, Feb 29, 2012 at 5:05 PM, Ben Reeves supp...@pi.uk.com 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
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 gavinandre...@gmail.com wrote: On Wed, Feb 29, 2012 at 5:05 PM, Ben Reeves supp...@pi.uk.com 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
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
