7

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.

1

2 Answers 2

9

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 227931!

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 209920), 490897 (in block 176684) and 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.

4

My understanding of the problem is:

The coinbase transaction in block 164384 (3aa03753fc) happens to start with OP_PUSHBYTES_3 d6441e which is the value 1983702.

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

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.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.