Author: Matt Corallo 2012-02-29 22:38:13
Published on: 2012-02-29T22:38:13+00:00
In February 2012, Pieter Wuille reached out to the Bitcoin community inquiring about support for an extra protocol rule. The rule would prohibit blocks from containing a transaction whose hash is equal to that of a former transaction which has not yet been completely spent. This vulnerability had been found in how the Bitcoin reference client deals with duplicate transactions. Exploiting it is complex, requires some hash power, and has no financial benefit for the attacker. However, it still poses a security risk that needed fixing. Wuille's solution is backward compatible in the same way as BIP16. If a supermajority of mining power implements it, old clients can continue to function without risk. Ben Reeves warned that 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. He added that a malicious miner could 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. Reeves suggested that this should be patched in DisconnectBlock() before any protocol change. He also suggested that maybe a new mapByCoinbase multimap is needed. In response, Matt advised that when rolling out the update, they have to make sure they have 50%, not just 50%. Something like 60%-75% should do fine. He added that they just have to be very, very vocal about the change when it happens and make sure miners are all on board.
Updated on: 2023-05-18T23:35:26.076682+00:00