Notice that this coinbase transaction from block 

This is the BIP 54 way of fixing the duplicate transaction problem in Bitcoin, and block 937404 is the first block that has implemented this. BIP 54 (The Great Consensus Cleanup) is a soft fork proposal that attempts to resolves a number of annoying (and potentially troublesome) behaviors in Bitcoin code (

Some coinbase transactions can actually end up having the same txid as other coinbase transactions. BitMex Research did 

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.

This, of course, is a bit of a bummer. There have been a number of attempts to fix this (

). BIP 30 fixed the issue by adding a check to make sure that a duplicate transaction id can only be created if the txid it duplicates was already spent. Unfortunately, this check was fairly computationally expensive. BIP 34 added the block height to the coinbase transaction and this seemed to fix the problem of duplicate transactions and so the more computationally expensive BIP 30 checks were removed.

However, it turns out that the way BIP 34 is implemented doesn't actually prevent duplicate coinbase transactions in all cases. At block 1,983,702 the coinbase transaction could potentially be a duplicate of the coinbase transaction from block 164,384.

As a sort of final solution to the problem, BIP 54 proposes that all coinbase transactions set their locktime to one less than the blockheight (this is because "the locktime validation, which is also performed for coinbase transactions, enforces that the nLockTime value is the last block at which a transaction is invalid, not the first one at which it is valid."). By setting locktime to blockheight - 1, the rule guarantees that every coinbase txid will be unique.

bitcoin

![](https://m.stacker.news/131986)

Notice that this coinbase transaction from block [937404](https://mempool.space/block/0000000000000000000080d8cad3f87b25828e07ecdce38d970c8b3c5df07b23) has a Locktime set to 937403.

This is the BIP 54 way of fixing the duplicate transaction problem in Bitcoin, and block 937404 is the first block that has implemented this. BIP 54 (The Great Consensus Cleanup) is a soft fork proposal that attempts to resolves a number of annoying (and potentially troublesome) behaviors in Bitcoin code (https://stacker.news/items/1428059). One of these behaviors is 

# The duplicate transaction problem

Some coinbase transactions can actually end up having the same txid as other coinbase transactions. BitMex Research did [a great piece](https://www.bitmex.com/blog/bitcoins-duplicate-transactions) on this if you'd like to learn more.

> 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.

This, of course, is a bit of a bummer. There have been a number of attempts to fix this ([BIP 30](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki) and [BIP 34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki)). BIP 30 fixed the issue by adding a check to make sure that a duplicate transaction id can only be created if the txid it duplicates was already spent. Unfortunately, this check was fairly computationally expensive. BIP 34 added the block height to the coinbase transaction and this seemed to fix the problem of duplicate transactions and so the more computationally expensive BIP 30 checks were removed.

However, it turns out that the way BIP 34 is implemented doesn't actually prevent duplicate coinbase transactions in all cases. At block 1,983,702 the coinbase transaction could potentially be a duplicate of the coinbase transaction from block 164,384. 

As a sort of final solution to the problem, BIP 54 proposes that all coinbase transactions set their locktime to one less than the blockheight (this is because "the locktime validation, which is also performed for coinbase transactions, enforces that the nLockTime value is the last block at which a transaction is invalid, not the first one at which it is valid."). By setting locktime to blockheight - 1, the rule guarantees that every coinbase txid will be unique.

The duplicate transaction problemThe duplicate transaction problem