Bitcoin Duplicate Transactions: An Interesting but Limited Impact Vulnerability

There is an interesting vulnerability in the Bitcoin network - double spending. Normally, Bitcoin transactions use unspent outputs by referencing the ID of the previous transaction. These outputs can only be spent once; otherwise, it leads to the double spending problem. However, in the history of Bitcoin, there have indeed been two sets of completely identical transactions.

This situation may occur because the coinbase transaction has no input and directly generates new coins. Therefore, two different coinbase transactions can potentially send the same amount of Bitcoin to the same address, resulting in identical transactions. Since the transaction contents are the same, their transaction ID ( TXID ) is also the same.

These two sets of duplicate transactions occurred from November 14 to 15, 2010, spanning approximately 16 hours. The first set of duplicate transaction ID is d5d2....8599, and the second set is e3bf....b468. Interestingly, although d5d2....8599 became a copy first, it appeared later on the blockchain than e3bf....b468.

These repeated transactions are each worth 50 BTC, totaling 200 BTC. From a certain perspective, 100 BTC of that actually do not exist. As of now, none of this 200 BTC has been spent. Theoretically, the person with the relevant private keys can spend these Bitcoins, but once spent, the duplicated 50 BTC will be lost, so in reality, only 100 BTC can be recovered.

Duplicate transactions can obviously cause confusion for wallets and block explorers, and may also be exploited for attacks. For example, an attacker could deposit funds into an exchange using two duplicate transactions and then immediately withdraw, attempting to bankrupt the exchange.

To address this issue, the Bitcoin community has taken several measures:

1. In March 2012, the BIP30 soft fork prohibited the use of duplicate TXID for transactions unless the previous TXID has been spent.

2. In September 2012, Greg Maxwell modified the rules to make BIP30 checks applicable to all blocks, but retained the two previously mentioned duplicate transactions.

3. In March 2013, BIP34 soft fork required that coinbase transactions include the block height, which basically solved the problem of double spending.

4. In November 2015, Bitcoin Core stopped performing BIP30 checks since BIP34 had already fixed the issue.

However, in some blocks before the activation of BIP34, the first byte of the scriptSigs of the coinbase transaction just matches the future valid block height. This means that the double spending problem has not been 100% resolved. The next block that may have a double spending issue is 1,983,702, expected to be produced around January 2046.

However, the cost of exploiting this vulnerability is very high. Taking block 1,983,702 as an example, an attacker would need to burn approximately 170 BTC in fees, which is about 15 million dollars at current prices. Moreover, these funds are likely irrecoverable. Additionally, since the SegWit upgrade in 2017, coinbase transactions also include commitments to all transactions in the block, further increasing the difficulty of the attack.

Considering the difficulty and cost of copy trading, as well as the scarcity of opportunities to take advantage of, this vulnerability does not pose a major security threat to Bitcoin. Nevertheless, developers are still working hard to find a fix, which may need to be achieved through a soft fork. One possible approach is to enforce the SegWit commitment.

Overall, although the repeated transaction vulnerability is interesting, its actual impact is very limited. It more reflects the complexity of the Bitcoin network and the developers' continuous efforts to improve the system.