Repeated transactions of Bitcoin: An interesting bug with minimal risk

Overview

A normal Bitcoin transaction uses the output of at least one previous transaction by referencing the transaction ID (TXID) of the previous transaction. These unspent outputs can only be spent once, and if they can be spent twice, you can double-pay Bitcoin, making it worthless. However, there actually happens to be two exact sets of transactions in Bitcoin. This situation may occur because coinbase transactions do not have any transaction input, but have newly generated coins. Therefore, it is possible for two different coinbase transactions to send the same number to the same address and build in exactly the same way, making them exactly the same. Since these transactions are the same, TXID also matches because TXID is a hash digest of transaction data. The only other way TXID is copied is a hash collision, which is considered unlikely and unimplemented for cryptographically secure hash functions. Hash collisions like SHA256 have never happened in Bitcoin or anywhere else.

Both sets of repeated transactions occurred in similar times, spanning about 16 hours between 08:37 UTC on November 14, 2010 and 00:38 UTC on November 15, 2010. The first set of repeated transactions are sandwiched between the second set. We classify d5d2….8599 as the first duplicate transaction because it becomes a replica in the first place, although strangely, its first appearance on the blockchain is after another duplicate transaction e3bf….b468 .

Repeated transaction details

In the image below, you can see two screenshots from the mempool.space block browser, showing the first repeated transaction in two different blocks.

Interestingly, when entering the relevant URL in a web browser, the mempool.space block browser defaults to display the earlier block in the case of d5d2….8599 , while the later block by default in the case of e3bf….b468 . Blockstream.info and Btcscan.org have the same behavior as mempool.space. On the other hand, according to our basic tests, Blockchain.com and Blockchair.com behave differently, and when entering a URL in the browser, the latest version of the duplicate transaction is always displayed.

Of the four related blocks, only one block (block 91,812) contains other transactions. This transaction combines the outputs of 1 BTC and 19 BTC into a 20 BTC output.

Can these outputs be spent?

This creates a citation problem for subsequent transactions due to the existence of two identical sets of TXIDs. Each repeat transaction has a value of 50 BTC. So, these repeated transactions involve a total of 4 x 50 BTC = 200 BTC, or depending on the different ways of understanding, it may involve 2 x 50 BTC = a100 BTC. To some extent, there are 100 BTC that doesn't actually exist. As of today, all 200 BTC has not been spent. As far as we know (we might be wrong here), if someone has the private key associated with these outputs, they can spend these bitcoins. However, once spent, UTXO will be deleted from the database and the duplicate 50 BTC will therefore not be spent and lost, so only 100 BTC may be retrieved. As for which block they will come from if these coins are spent, whether they are earlier or most recent, this may be undefined or undeterminable.

This person could have spent all the bitcoins before creating a duplicate transaction, and then created duplicate output, creating a new entry in a database where the output was not spent. This will mean not only repeated transactions, but also repeated repeated transactions with spent output. If this happens, when these outputs are spent, more duplicate transactions will be created, forming a duplicate chain. People have to be careful about the order of events and always spend before creating duplicates, otherwise Bitcoin may be lost forever. These new repeat transactions will not be coinbase transactions, but "normal" transactions. Fortunately, this has never happened.

The issue of repeated transactions

Repeated transactions are obviously bad. They can bring confusion to wallet and block explorers and make it unclear where Bitcoin comes from. It also brings many attacks and vulnerabilities. For example, you can pay someone twice with two repeated transactions. Then, when the trader decides to try to use the money, they may find that only half of the money can be recovered. For example, this could be an attack on an exchange, trying to bankrupt it, without any loss from the attacker, as they can withdraw funds immediately after depositing.

Disable transactions using duplicate TXIDs

In order to alleviate the problem of repeated transactions, in February 2012, Bitcoin developer Pieter Wuille proposed the BIP30 soft fork solution, which prohibits transactions using duplicate TXIDs unless the previous TXID has been spent. This soft fork is suitable for all blocks after March 15, 2012.

In September 2012, Bitcoin developer Greg Maxwell modified this rule to make BIP30 checks work for all blocks, not just blocks after March 15, 2012. Except for the two repeated transactions mentioned earlier in this article. This fixes some DOS vulnerabilities. Technically, this is another soft fork, although the rule change only applies to blocks over the past 6 months, so it does not have any risks associated with normal protocol rule changes.

This BIP30 check is computationally expensive. The node needs to check all transaction outputs in the new block and check whether these output endpoints already exist in UTXO. This may be why Wuille only checks for unused outputs, and if all outputs are checked, the calculation costs will be higher and it will not be possible to prune.

BIP34

In July 2012, Bitcoin developer Gavin Andresen proposed the BIP34 soft fork solution and activated it in March 2013. This protocol change requires coinbase transactions to include block height, which also makes block version management possible. Block height is added as the first item of the coin-based trading script Sig. The first byte in coinbase scriptSig is the number of bytes used by the block height number, and the next byte is the block height number itself. For the first c160 year (223 / (144 blocks per day * 365 days per year)), the first byte should be 0x03. This is why today's coinbase ScriptSig (HEX) always starts with 03. This soft fork seems to completely solve the problem of repeated trading, and now all transactions should be unique.

As BIP34 has been adopted, in November 2015, Bitcoin developer Alex Morcos added a pull request to the Bitcoin core software repository, which changes mean that the nodes will stop performing BIP30 checks. After all, since BIP34 fixes this issue, this expensive check is no longer necessary. Although not known at the time, it was technically a hard fork for some very rare blocks in the future. It now seems that potential hard forks are not important, as few people are running node software before November 2015. In forkmonitor.info , we are running Bitcoin Core 0.10.3 released in October 2015. So this is a pre-hard fork rule, and the client is still doing expensive BIP30 checks.

Block ,983,702 Problem

It turns out that there were some coinbase transactions in the block before BIP34 activation, and the first byte of scriptSigs used at the time happened to match the height of the future valid block. So while BIP34 does fix this in almost every situation, it is not a complete 100% fix. In 2018, Bitcoin developer John Newbery printed out a complete list of these potential duplicates, as shown in the following table.

*Note: These blocks have generated Coinbase transactions in 2012 and 2017 and are not duplicate. 209 921 blocks (only 79 blocks away from the first halving) cannot be duplicated because BIP30 is executed during this period.

Source: https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd

Potential repeat Coinbase transactions by year

Source:https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd

Therefore, the next block that may have duplicate transactions is 1,983,702, which will be generated around January 2046. Coinbase transactions in blocks 164,384 generated in January 2012 sent 170 BTC to seven different output addresses. So if miners in 2046 want to conduct this attack, they not only need to be lucky enough to find the block, but also need to burn less than 170 BTC, with a total cost of just over 170 BTC, which includes the opportunity cost of the 0.09765625 BTC block subsidy. Based on the current Bitcoin price of $88,500, this will cost more than $15 million. As for whom the seven addresses of the coin library transactions in 2012 belong to, it is not yet known that the key is likely to have been lost. Currently, all seven output addresses of the Coinbase transaction have been used, three of which are used in the same transaction . We think these funds may be related to the Pirate40 Ponzi scheme, but that's just our speculation. Therefore, this attack not only looks costly, but is almost useless to the attacker. It would be a considerable expense to remove the November 2015 node from the network 31 years ago in a hard fork.

The next vulnerable block that may be copied is 169985 in March 2012. This Coinbase only costs just over 50 BTC, which is far below 170 BTC. Of course, 50 BTC was the subsidy at the time, and when this Coinbase transaction became prone to repeat in 2078, the subsidy would be much lower. So to take advantage of this, miners will need to burn about 50 BTC fees that they can't get back because they have to send to old output in 2012. No one knows what the price of Bitcoin will be in 2078, but the cost of such an attack may also be terrifyingly high. Therefore, this issue may not be the main risk of Bitcoin, but it is still worrying.

Since the SegWit upgrade in 2017, Coinbase transactions can also include commitments to all transactions in a block. These previous BIP34 blocks do not contain witness commitments. Therefore, to generate a duplicate Coinbase transaction, the miner needs to exclude any SegWit output redemption transactions from the block, which further increases the opportunity cost of the attack, as the block may not contain many other transactions that pay fees.

in conclusion

Given the difficulty and cost of copying transactions, and the rare opportunity to exploit them, this copying transaction vulnerability is not like a major security issue for Bitcoin. However, considering the time scale involved and the novelty of repeated transactions, it is quite interesting to think about it. Still, developers have spent a lot of time on this issue over the years, and the 2046 date may be the deadline for some developers to fix it. There are many ways to fix this error, and may require a soft fork. One possible fix is ​​to enforce the SegWit commitment.