Bitcoin’s Duplicate Transactions

Abstract: In the Bitcoin blockchain there are two sets of completely identical transactions, one set sandwiches another, and they all occurred in the middle of November 2010. Duplicate transactions have the potential to cause confusion and Bitcoin developers have been fighting against them for years, in various ways. The issue is still not 100% fixed, with the next potential duplicate arising in 2046. Although the risks associated with duplicate transactions are now minimal, it is an interesting novelty bug to think about.

Overview

A normal Bitcoin transaction spends at least one output of a previous transaction, by referencing the transaction ID (TXID) of the previous transaction. These unspent outputs can only be spent once, if they could be spent twice, you could double spend Bitcoin, making Bitcoin worthless. However, there are actually precisely two sets of two identical transactions in Bitcoin. The way this was possible is that the coinbase transaction does not have any transaction inputs, instead it has newly generated coins. Therefore, it is possible for two different coinbase transactions to send the same amount to the same addresses and be structured in exactly the same way, such that they are exactly identical. Since the transactions are identical, the TXIDs are also a match, since the TXID is a hash digest of the transaction data. The only other way for the TXIDs to be duplicated, would be a hash collision and for a cryptographically secure hash function, this is supposed to be improbable and unachievable. A hash collision like this for SHA256 has never occurred in Bitcoin or anywhere else for that matter.

The two sets of two identical transactions all happened in close proximity, between 08:37 UTC on 14 November 2010 and 00:38 UTC on 15 November 2010, a period spanning around 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 duplicate first, even though, oddly, it first appeared on the blockchain after the other duplicate, e3bf….b468.

The Duplicate Transaction Details

In the below images, one can see two screenshots from the mempool.space block explorer, of the first duplicate transaction, repeated in two different blocks.

Interestingly, when entering the relevant URLs into a web browser, the mempool.space block explorer defaults to the earlier block in the d5d2….8599 case and later block in the e3bf….b468 case. Blockstream.info and Btcscan.org have the same behaviour as mempool.space. On the other hand, Blockchain.com and Blockchair.com, behave in a different manner, always showing the most recent version of the duplicate transaction, when one enters the URL in the browser, based on our basic tests.

Only one of the four blocks in question, had any other transactions in them, block 91,812. This transaction, which consolidated a 1 BTC and 19 BTC output into a 20 BTC output.

Are The Outputs Spendable?

With there being two sets of identical TXIDs, this creates a referencing problem for the next transactions. Each duplicate transaction has a value of 50 BTC. Therefore there are a total of 4 x 50 BTC = 200 BTC involved in these duplicate transactions, or perhaps 2 x 50 BTC = 100 BTC is involved, depending on how one thinks of it. In a way, there is 100 BTC that does not really exist. As of today, all 200 BTC is unspent. As far as we know, and we could be wrong here, if someone has the private key associated with these outputs, they could spend the Bitcoin. However, once spent, the UTXO would be removed from the database and the duplicate 50 BTC would therefore be unspendable and lost, therefore only 100 BTC is potentially recoverable. As for which block the coins would have come from if they were spent, the earlier one or the most recent one, that could be undefined or impossible to say.

It could have been possible for this person to have spent all the Bitcoin before the duplicate transaction was created, then create the duplicate output, creating a new entry in the database on unspent outputs. This would have meant there were not only duplicate transactions, duplicate transactions with possibly duplicate spent outputs. If this happened, this would open up the possibility of creating even more duplicate transactions, when these outputs were spent, a kind of duplicate chain. One would have to be careful with the sequencing of the events, always spending before creating a duplicate, or the Bitcoin could be lost forever. These new duplicate transactions would not be coinbase transactions, but “normal” transactions. Luckily this never happened.

The Problem With Duplicates

Duplicate transactions are clearly bad. They cause confusion for wallets and block explorers, as well as ambiguity over where Bitcoin came from. There are also many attacks and exploits it opens up. For example, you could pay someone twice, with two duplicate transactions. Then when the counterparty decided to try and spend the funds, they could find out that only half is recoverable. This could be an attack on an exchange for example, trying to make it insolvent, while costing the attacker nothing, since they could immediately withdraw the funds after the deposit.

Disallow Transactions With Duplicate TXIDs

In order to mitigate the duplicate transaction problem, in February 2012, Bitcoin developer Pieter Wuille proposed BIP30, a softfork that bans transactions with duplicate TXIDs, unless the previous one was spent. This softfork applied to all blocks after 15 March 2012.

In September 2012, Bitcoin developer Greg Maxwell modified the rule, such that the BIP30 check applied to all blocks, not just those after 15 March 2012. With specific exception of the two duplicate transactions mentioned earlier in this article. This fixed some DOS vulnerabilities. This was technically another softfork, although the rule change only applied to blocks over 6 months in the past, so it didn’t share any of the risks associated with normal protocol rule changes.

This BIP30 check is computationally expensive. Nodes need to check all the transaction outputs in a new block and check whether these output endpoints already exist in the UTXO set. This is probably why Wuille only implemented this check for unspent outputs, if the check was for all outputs, this would be even more computationally expensive and pruning would not be possible.

BIP34

In July 2012, Bitcoin developer Gavin Andresen proposed BIP34, a softfork which activated in March 2013. This protocol change required the coinbase transaction to include the block height, this also enabled block versioning. The block height was added as the first item in the coinbase transaction scriptSig. The first byte in the coinbase scriptSig is the number of bytes the block height number uses and the following bytes is the block height number itself. For the first c160 years (2²³ / (144 blocks per day * 365 days per year)), the first bytes should be 0x03. This is why today the coinbase ScriptSig (HEX) always starts with 03. This softfork seemed to totally fix the duplicate transaction problem and now all transactions should be unique.

With already BIP34 adopted, in November 2015, Bitcoin developer Alex Morcos added a pull request to the Bitcoin Core software repository, a change which would mean the node would stop conducting the BIP30 checks. Afterall, since BIP34 fixed the issue, this expensive check was no longer necessary. It was not known at the time, but this was technically a hardfork for some very rare future blocks. Not that the potential hardfork matters now, because almost nobody is running pre November 2015 node software. At forkmonitor.info, we are running Bitcoin Core 0.10.3, released in October 2015. Therefore, this is a pre-hardfork rules client is still conducting the expensive BIP30 checks.

The block 1,983,702 problem

It turns out that there are some coinbase transactions in blocks prior to when BIP34 was activated, where the first bytes of the scriptSigs used at the time happen to match valid future block heights. Therefore while BIP34 did fix the issue in almost all cases, it was not a complete 100% fix. In 2018, Bitcoin developer John Newbery printed out a full list of these potential duplicates, which is shown in the table below.

Note: * These blocks have already been produced in 2012 and 2017 and the coinbase transactions were not duplicates. The 209,921 block (just 79 blocks away from the first halving) could not have been a duplicate since BIP30 was enforced in that period.

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

Number of potential duplicate coinbase transactions by year

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

Therefore the next block where a duplicate transaction is possible is 1,983,702, which is due to be produced around January 2046. The coinbase transaction in block 164,384, produced in January 2012, sends 170 BTC to seven different output addresses. Therefore, if a miner in 2046 wants to conduct this attack they would not only need to be lucky enough to find this block, but they would also need to burn just under 170 BTC in fees, with a total cost of just over 170 BTC, including the opportunity cost of the 0.09765625 BTC block subsidy. Based on the current Bitcoin price of US$88,500, this would cost over US$15 million. As for who owns the seven addresses from this 2012 coinbase, that is unknown, with a good chance the keys are lost. All seven outputs from this coinbase transaction have now been spent, three of them in the same transaction. We believe these funds may be related to the Pirate40 ponzi scheme, although this is speculation on our part. Therefore, this attack does seem not only very expensive, but also mostly useless for the attacker. This would be quite a lot of money to spend, to boot 31 year old November 2015 nodes off the network in a hardfork.

The next vulnerable block, which could have its coinbase duplicated, is 169,985 in March 2012. This coinbase only spends just over 50 BTC, far less than 170 BTC. 50 BTC was of course the subsidy at the time and when this coinbase transaction becomes vulnerable to be repeated, in 2078, the subsidy will be much lower. Therefore, to exploit this, the miner will need to burn around 50 BTC in fees, fees it cannot get back as it must be sent to the old 2012 outputs. Who knows what the price of Bitcoin could be in 2078, but this attack is also likely to be prohibitively expensive. Therefore this problem is probably not a major risk for Bitcoin, but still somehwhat of a concern.

Since the SegWit upgrade in 2017, the coinbase transaction can also contain a commitment to all the transactions in a block. These pre-BIP34 blocks did not contain a witness commitment. Therefore to produce a duplicate coinbase transaction, the miner would need to exclude any SegWit output redemption transactions from the block, further increasing the opportunity costs of the attack, since the block may not be able to include many other fee paying transactions.

Conclusion

This duplicate transaction bug does not feel like a major security concern for Bitcoin, given how difficult and expensive it would be to pull off and how rare the opportunities to exploit it pop up. However it is fun to think about, given the timescales involved and the novelty of duplicate transactions. Despite this, significant developer time has been spent on this over the years and that 2046 date may be in some developers minds, as a deadline for fixing this issue. There are various ways to fix this bug and it will probably require a softfork. One potential way of fixing this would be to make the SegWit commitment mandatory.

The post Bitcoin’s Duplicate Transactions appeared first on BitMEX Blog.

​BitMEX Blog 

Weiterlesen