I'm not familiar with how the blockchain is stored in nodes so I have one question.
Can this replacement of a transaction with another one with identical hash break a trace if someone is following the coins? if yes then whoever wants to do this will have to implement a different storing mechanism to allow multiple transactions with identical hash to coexists. Is this true or I'm too noob to understand?
Topic: Security update: duplicate transaction vulnerability fix - page 3. (Read 14543 times)
Very unlikely. Someone would need to plan the attack very carefully, have huge amounts of hashing power hiding offline, and gain essentially nothing from it.
Not really, during this protocol change they only need to mine one valid block.
But as along as the majority of hashing power is supporting BIP30 the difficulty on the forked chain would be left so high that it would probably die fairly quickly and would not be able to produce the 6 valid blocks needed for transaction reversal.
If anything will ever go wrong with bitcoin... it'll be now.... the whole idea of a possible fork is somewhat scary.
Very unlikely. Someone would need to plan the attack very carefully, have huge amounts of hashing power hiding offline, and gain essentially nothing from it.
+1
If anything will ever go wrong with bitcoin... it'll be now.... the whole idea of a possible fork is somewhat scary.
Very unlikely. Someone would need to plan the attack very carefully, have huge amounts of hashing power hiding offline, and gain essentially nothing from it.
A technical question - why the patch does not simply discard the block with the duplicate hash, regardless of its contents?
If anything will ever go wrong with bitcoin... it'll be now.... the whole idea of a possible fork is somewhat scary.
Do we have an ETA on the patch getting merged and included in rc3 or whatever?
To conclude: We want to fix a newly found vulnerability, we need majority of miners to support the fix in order to prevent a potential permanent fork, the fix was thoroughly discussed on the mailing list, the developers support it and it is noncontroversial. With majority support, if all goes well, this change will be activated on march 15th 2012, 0:00 UTC.
So the strategy is to post updated code on Sourceforge before March 15 and have miners switch at 0:00 UTC? I assume this version will not include any form of multisig, in order to avoid controversy and resistance to immediate adoption.
These pools have confirmed that they have deployed BIP 30 updates:
* deepbit (3400 GH/s)
* btcguild (1300 GH/s)
* mining.bitcoin.cz (1400 GH/s)
* eclipsemc (520 GH/s)
* eligius (290 GH/s)
* ozcoin (600 GH/s)
* bitclockers (175 GH/s)
* bitlc (170 GH/s)
* btcmp.com (120 GH/s)
* btcmine (620 GH/s)
(total over 8 TH/s)
* deepbit (3400 GH/s)
* btcguild (1300 GH/s)
* mining.bitcoin.cz (1400 GH/s)
* eclipsemc (520 GH/s)
* eligius (290 GH/s)
* ozcoin (600 GH/s)
* bitclockers (175 GH/s)
* bitlc (170 GH/s)
* btcmp.com (120 GH/s)
* btcmine (620 GH/s)
(total over 8 TH/s)
UPDATE: 0.5.3 was released with BIP30 support
Hello all,
as some of you already know, a vulnerability was found in the way bitcoin currently handles duplicate transactions. Even though we were able to demonstrate a potential attack on testnet, there is no cause for alarm because such an attack requires significant hashing power, is rather complex, and even if carried out does not allow financial gain for an attacker. Still, it is a vulnerability that can cause problems and we want to fix it as soon as possible.
But before we roll out the fix we wanted to inform you, the community, exactly what the problem is and how we are going to fix it. Essentially we want everyone to be on the same page to make the fix roll-out as smooth and uneventful as possible.
For most problems, this is not required, as we can just release an updated client. However, the nature of the problem dictates a fix that will introduce a new stricter block-validity rule. This means we have to actually change the rules by which blocks are considered to be valid or invalid. This in and of itself poses a risk, because an attacker violating this new rule while only a minority has upgraded their clients could cause a block chain fork. This is a bad thing because it would allow any transaction output that existed before the fork to be spent twice: once in each branch of the fork. However, if a majority enforces the stricter rules, we are sure that any fork will be resolved quickly and not be permanent. This is why we need your support.
The fix, described in BIP 30, is noncontroversial. There was a long discussion on the mailing list, and several developers have expressed their support. A majority of mining pools (in terms of hashing power) have also confirmed they will be updating their nodes. BIP 30 is backward-compatible: only what was previously considered a valid block can become invalid and not the other way around. This means that old software will continue to accept blocks "mined" by clients following the new rule, and keep building upon them.
A bit more technical, the actual bug is this: the bitcoin software was written with the assumption that it is impossible to create a transaction with a hash that is identical to that of a previous transaction. This is however not entirely true. It requires buggy software, or malicious intent, but one can create a coinbase transaction that is identical to a previous coinbase, implying it has the same hash. Furthermore, by recreating transactions that use these duplicated coinbase(s), those can be duplicated as well. Now here is how the bitcoin software currently deals with this: it does not check whether that previous hash already exists but simply overwrites it in its transaction index database. Even worse, when a block that contained such a duplicate is reverted (during a reorganisation), the index entry is deleted entirely. If the original transaction was not yet spent, it has now become unspendable.
The way to fix this is simple: simply disallow blocks to contain such duplicated transactions. In order not to make pruning impossible in the future, one exception is added: if the original transaction was already completely spent before a block, it is (for now) still allowed to contain a duplicate. Without this exception, every full node in the network would be required to keep an index of all transactions ever. This was implemented, the change is merged in git master (so it will be included in the 0.6.0 release) as well as in several backports. It was tested by roconnor (who demonstrated the original attack on testnet) to prevent his attack, and it was tested to still accept the current longest block chain on the real network.
To conclude: We want to fix a newly found vulnerability, we need majority of miners to support the fix in order to prevent a potential permanent fork, the fix was thoroughly discussed on the mailing list, the developers support it and it is noncontroversial. With majority support, if all goes well, this change will be activated on march 15th 2012, 0:00 UTC.
PS: thanks to Hazek for proofreading
Hello all,
as some of you already know, a vulnerability was found in the way bitcoin currently handles duplicate transactions. Even though we were able to demonstrate a potential attack on testnet, there is no cause for alarm because such an attack requires significant hashing power, is rather complex, and even if carried out does not allow financial gain for an attacker. Still, it is a vulnerability that can cause problems and we want to fix it as soon as possible.
But before we roll out the fix we wanted to inform you, the community, exactly what the problem is and how we are going to fix it. Essentially we want everyone to be on the same page to make the fix roll-out as smooth and uneventful as possible.
For most problems, this is not required, as we can just release an updated client. However, the nature of the problem dictates a fix that will introduce a new stricter block-validity rule. This means we have to actually change the rules by which blocks are considered to be valid or invalid. This in and of itself poses a risk, because an attacker violating this new rule while only a minority has upgraded their clients could cause a block chain fork. This is a bad thing because it would allow any transaction output that existed before the fork to be spent twice: once in each branch of the fork. However, if a majority enforces the stricter rules, we are sure that any fork will be resolved quickly and not be permanent. This is why we need your support.
The fix, described in BIP 30, is noncontroversial. There was a long discussion on the mailing list, and several developers have expressed their support. A majority of mining pools (in terms of hashing power) have also confirmed they will be updating their nodes. BIP 30 is backward-compatible: only what was previously considered a valid block can become invalid and not the other way around. This means that old software will continue to accept blocks "mined" by clients following the new rule, and keep building upon them.
A bit more technical, the actual bug is this: the bitcoin software was written with the assumption that it is impossible to create a transaction with a hash that is identical to that of a previous transaction. This is however not entirely true. It requires buggy software, or malicious intent, but one can create a coinbase transaction that is identical to a previous coinbase, implying it has the same hash. Furthermore, by recreating transactions that use these duplicated coinbase(s), those can be duplicated as well. Now here is how the bitcoin software currently deals with this: it does not check whether that previous hash already exists but simply overwrites it in its transaction index database. Even worse, when a block that contained such a duplicate is reverted (during a reorganisation), the index entry is deleted entirely. If the original transaction was not yet spent, it has now become unspendable.
The way to fix this is simple: simply disallow blocks to contain such duplicated transactions. In order not to make pruning impossible in the future, one exception is added: if the original transaction was already completely spent before a block, it is (for now) still allowed to contain a duplicate. Without this exception, every full node in the network would be required to keep an index of all transactions ever. This was implemented, the change is merged in git master (so it will be included in the 0.6.0 release) as well as in several backports. It was tested by roconnor (who demonstrated the original attack on testnet) to prevent his attack, and it was tested to still accept the current longest block chain on the real network.
To conclude: We want to fix a newly found vulnerability, we need majority of miners to support the fix in order to prevent a potential permanent fork, the fix was thoroughly discussed on the mailing list, the developers support it and it is noncontroversial. With majority support, if all goes well, this change will be activated on march 15th 2012, 0:00 UTC.
PS: thanks to Hazek for proofreading
Jump to: