The issue, transition to requiring block height in block coinbases, was discussed back in 2012, however I just stumbled upon it, and would like to understand more about its significance.
Bitcoin assumes a (txid, vout) pair, usually referred to as an "outpoint", is a unique identifier for a UTxO. This assumption did not actually hold in the early years of Bitcoin, since two coinbase transactions may have had the same txid then. This was fixed in early 2012 with the deployment of BIP30 which mandates no new transaction may have the same txid as a previous transaction which still has unspent outputs.
A few months later, BIP34 mandated coinbase transactions contain the height of the block they're included in as the first item in their input's
scriptSig. This effectively made the txid of all transactions from then on unique. (Note this did not make all transactions unique though as it was still possible to spend earlier duplicate coinbase transactions.)
The BIP30 check is expensive, as it requires going through all the outputs of all the transactions in the block, and checking if a UTxO with the same outpoint does not already exist. In addition, it was not possible to create duplicate transactions from the only two occurrences of BIP30 violations. Therefore, nodes can avoid performing the BIP30 check after BIP34 activation (that is, past block
227931). This was implemented in Bitcoin Core in PR #6931.
However, #6931 overlooked how if a block prior to BIP34 activation contained a coinbase transaction which had a value pushed as first item of its
scriptSig such as it represents a block height in the future, this allowed for the block at the height represented by this value to have a coinbase transaction identical to the first block. Thus re-introducing duplicate txids since the BIP30 check wasn't performed after block
It turns out there is many such blocks (this gist contains a few) with block heights from the future pushed as first item of the coinbase's
scriptSig. The three lowest heights pushed are
209921 (in block
490897 (in block
1983702 (in block
164384). For block
209921 BIP30 verification is still performed still it's prior to BIP34 activation. It's not possible to create a duplicate in block
490897 (see this code comment for rationale). The next height at which a duplicate is possible is
1983702. Since there is many more heights after this one where a duplicate is possible, BIP30 verification was simply re-enabled for all blocks after height
1983702. This was implemented in Bitcoin Core in PR #12204.
I believe this is what you refer to as the "block 1,983,702 problem". Starting from block 1,983,702 nodes won't be able to leverage BIP34 to avoid performing the BIP30 validation anymore.
If you want to learn more, see this code comment which explains the above in more details.
My understanding of the problem is:
The coinbase transaction in block
3aa03753fc) happens to start with
OP_PUSHBYTES_3 d6441e which is the value
This means there is a very small but non-zero chance that the miner of block
1983702 could use the exact same coinbase transaction from block
This is somewhat mitigated by BIP30 which disallows blocks from containing a duplicate previous transaction - but only if it has unspent outputs.
See the linked duplicate question for Murch’s answer.