Overview

A normal Bitcoin transaction uses at least one output from a previous transaction by referencing the transaction ID (TXID) of that transaction. These unspent outputs can only be spent once; if they could be spent twice, it would enable double spending, rendering Bitcoin worthless. However, there actually exist two sets of completely identical transactions in Bitcoin. This situation is possible because coinbase transactions do not have any transaction inputs but rather newly generated coins. Therefore, two different coinbase transactions can potentially send the same amount to the same address and be constructed in exactly the same way, making them identical. Since these transactions are the same, their TXIDs also match, as the TXID is a hash digest of the transaction data. The only other way TXIDs can be duplicated is through a hash collision, which is considered unlikely and unfeasible for cryptographically secure hash functions. Hash collisions like SHA256 have never occurred in Bitcoin or anywhere else.

These two sets of duplicate transactions occurred within a close timeframe, between November 14, 2010, 08:37 UTC and November 15, 2010, 00:38 UTC, spanning approximately 16 hours. The first set of duplicate transactions is sandwiched between the second set. We classify d5d2….8599 as the first duplicate transaction because it became a copy first, although oddly, it first appeared on the blockchain after another duplicate transaction e3bf….b468.

Details of Duplicate Transactions

In the images below, two screenshots from the mempool.space block explorer show the occurrence of the first duplicate transaction in two different blocks.

Interestingly, when entering the relevant URLs in a web browser, the mempool.space block explorer defaults to showing the earlier block for d5d2….8599 and the later block for e3bf….b468. Blockstream.info and Btcscan.org exhibit the same behavior as mempool.space. On the other hand, according to our basic tests, Blockchain.com and Blockchair.com behave differently, always showing the latest version of the duplicate transaction when the URL is entered in the browser.

Among the four relevant blocks, only one block (block 91,812) contains other transactions. This transaction merged outputs of 1 BTC and 19 BTC into a single output of 20 BTC.

Can These Outputs Be Spent?

Due to the existence of two sets of identical TXIDs, this creates a referencing issue for subsequent transactions. Each duplicate transaction is worth 50 BTC. Therefore, these duplicate transactions involve a total of 4 x 50 BTC = 200 BTC, or depending on the interpretation, possibly 2 x 50 BTC = 100 BTC. In a sense, 100 BTC does not actually exist. As of today, all 200 BTC remain unspent. To our knowledge (we may be wrong here), if someone possesses the private keys associated with these outputs, they could spend these Bitcoins. However, once spent, the UTXO would be removed from the database, and the duplicate 50 BTC would thus become unspendable and lost, meaning only 100 BTC could potentially be recovered. As for which block these coins would come from if they were spent, whether the earlier or the more recent one, it may be undefined or indeterminate.

This person could have spent all the Bitcoins before creating the duplicate transactions and then created duplicate outputs, generating new entries in the unspent output database. This would mean not only duplicate transactions but also potentially duplicate transactions of already spent outputs. If this occurred, when these outputs were spent, it could create more duplicate transactions, forming a chain of duplicates. People must be careful about the order of events, always spending before creating duplicates; otherwise, Bitcoins could be lost forever. These new duplicate transactions would not be coinbase transactions but rather "normal" transactions. Fortunately, this situation has never occurred.

The Problem of Duplicate Transactions

Duplicate transactions are clearly undesirable. They can create confusion for wallets and block explorers and obscure the source of Bitcoins. They also introduce many attacks and vulnerabilities. For example, you could pay someone twice with two duplicate transactions. Then, when the counterparty decides to try to use the funds, they may find that only half of the funds can be recovered. For instance, this could be an attack on an exchange, attempting to bankrupt it while the attacker incurs no losses because they can withdraw funds immediately after depositing.

Prohibiting Transactions with Duplicate TXIDs

To mitigate the issue of duplicate transactions, in February 2012, Bitcoin developer Pieter Wuille proposed the BIP30 soft fork proposal, which prohibits transactions with duplicate TXIDs unless the previous TXID has been spent. This soft fork applies to all blocks after March 15, 2012.

In September 2012, Bitcoin developer Greg Maxwell modified this rule so that the BIP30 check applies to all blocks, not just those after March 15, 2012. This excludes the two duplicate transactions mentioned earlier in this article. This fixed some DOS vulnerabilities. Technically, this was another soft fork, although the rule change only applied to blocks older than 6 months, so it did not carry any risks associated with normal protocol rule changes.

The computational cost of this BIP30 check is high. Nodes need to check all transaction outputs in new blocks and verify whether these output endpoints already exist in the UTXO. This may be why Wuille only checked for unused outputs; checking all outputs would incur higher computational costs and could not be pruned.

BIP34

In July 2012, Bitcoin developer Gavin Andresen proposed the BIP34 soft fork proposal, which was activated in March 2013. This protocol change requires coinbase transactions to include the block height, which also enables block version management. The block height is added as the first item in the coinbase transaction scriptSig. The first byte in the coinbase scriptSig indicates the number of bytes used for the block height number, followed by the bytes representing the block height number itself. For the first c160 years (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 have completely resolved the issue of duplicate transactions, and now all transactions should be unique.

Since BIP34 has been adopted, in November 2015, Bitcoin developer Alex Morcos added a pull request to the Bitcoin Core software repository, which meant that nodes would stop performing BIP30 checks. After all, since BIP34 fixed this issue, this expensive check was no longer necessary. Although it was not known at the time, technically, this was a hard fork for some very rare blocks in the future. It now seems that the potential hard fork is not significant, as very few people were running node software prior to November 2015. On forkmonitor.info, we are running Bitcoin Core 0.10.3 released in October 2015. Therefore, this was a rule before the hard fork, and clients were still performing the expensive BIP30 checks.

Block 983,702 Issue

It turns out that there are some coinbase transactions in blocks prior to the activation of BIP34, where the first byte of the scriptSigs used happened to match the future valid block height. Therefore, while BIP34 did fix this issue in almost all cases, it is not a complete 100% fix. In 2018, Bitcoin developer John Newbery printed a complete list of these potential duplicates, as shown in the table below.

Note: These blocks generated coinbase transactions in 2012 and 2017 that are not duplicates. Block 209,921 (only 79 blocks away from the first halving) cannot be duplicates because BIP30 was enforced during this period.

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

Number of Potential Duplicate Coinbase Transactions by Year

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

Thus, the next block that could potentially have duplicate transactions is 1,983,702, which will be generated around January 2046. The coinbase transaction from block 164,384 generated in January 2012 sent 170 BTC to seven different output addresses. Therefore, if miners in 2046 wanted to carry out this attack, they would not only need to be lucky enough to find this block but also burn fees of less than 170 BTC, with a total cost slightly above 170 BTC, including the opportunity cost of the 0.09765625 BTC block subsidy. At the current Bitcoin price of $88,500, this would cost over $15 million. As for the ownership of the seven addresses from the 2012 coinbase transaction, it is currently unknown, and the keys are likely lost. Currently, all seven output addresses of this coinbase transaction have been used, with three used in the same transaction. We believe these funds may be related to the Pirate40 Ponzi scheme, but this is just our speculation. Therefore, this attack appears not only costly but also nearly useless for the attacker. It would be a significant expense to remove a node from the network that is 31 years old from November 2015.

The next potentially vulnerable block that could be duplicated is block 169,985 from March 2012. This coinbase only spent just over 50 BTC, far below 170 BTC. Of course, 50 BTC was the subsidy at the time, and when this coinbase transaction becomes susceptible to duplication in 2078, the subsidy will be much lower. Therefore, to exploit this, miners would need to burn fees of about 50 BTC, which they would not be able to recover since these fees must be sent to the old outputs from 2012. No one knows what the price of Bitcoin will be in 2078, but the cost of this attack could also be frighteningly high. Thus, this issue may not be a major risk for Bitcoin, but it is still concerning.

Since the SegWit upgrade in 2017, coinbase transactions can also include commitments to all transactions in a block. These blocks prior to BIP34 do not contain witness commitments. Therefore, to generate a duplicate coinbase transaction, miners would need to exclude any SegWit output redeem transactions from the block, further increasing the opportunity cost of the attack, as the block may not be able to include many other transactions paying fees.

Conclusion

Considering the difficulty and cost of duplicating transactions, as well as the rarity of opportunities to exploit it, this duplicate transaction vulnerability does not seem to be a major security issue for Bitcoin. However, given the time scales involved and the novelty of duplicate transactions, it is still quite interesting to think about. Nevertheless, developers have spent a significant amount of time on this issue over the years, and the date of 2046 may be seen by some developers as a deadline to fix this problem. There are many ways to fix this bug, which may require a soft fork. One possible fix is to enforce SegWit commitments.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。