<p>My understanding of the problem is:</p>
<p>The coinbase transaction in block <code>164384</code> (<a href="https://mempool.space/tx/3aa03753fc238b38f4db9e5889362f3a6f0900d602baa8c9a7e789cb13ca1462" rel="nofollow noreferrer"><code>3aa03753fc</code></a>) happens to start with <code>OP_PUSHBYTES_3 d6441e</code> which is the value <code>1983702</code>.</p>
<p>This means there is a very small but non-zero chance that the miner of block <code>1983702</code> could use the exact same coinbase transaction from block <code>164384</code>.</p>
<p>This is somewhat mitigated by <a href="https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki" rel="nofollow noreferrer">BIP30</a> which disallows blocks from containing a duplicate previous transaction - but <strong>only if it has unspent outputs</strong>.</p>
<p>See the linked duplicate question for Murch’s answer.</p>

CC BY-SA 4.0
2023-12-08T11:07:40.893Z
2023-12-09T07:52:02.120Z
2023-12-09T07:52:02.120Z
delta1
<p>Bitcoin assumes a (txid, vout) pair, usually referred to as an &quot;outpoint&quot;, 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 <a href="https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki" rel="noreferrer">BIP30</a> which mandates no new transaction may have the same txid as a previous transaction which still has unspent outputs.</p>
<p>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 <code>scriptSig</code>. This effectively made the txid of all transactions from then on unique. (Note this did not make <em>all</em> transactions unique though as it was still possible to spend earlier duplicate coinbase transactions.)</p>
<p>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 <code>227931</code>). This was implemented in Bitcoin Core in PR <a href="https://github.com/bitcoin/bitcoin/pull/6931" rel="noreferrer">#6931</a>.</p>
<p>However, <a href="https://github.com/bitcoin/bitcoin/pull/6931" rel="noreferrer">#6931</a> overlooked how if a block prior to BIP34 activation contained a coinbase transaction which had a value pushed as first item of its <code>scriptSig</code> 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 <code>227931</code>!</p>
<p>It turns out there is many such blocks (<a href="https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd" rel="noreferrer">this gist</a> contains a few) with block heights from the future pushed as first item of the coinbase's <code>scriptSig</code>. The three lowest heights pushed are <code>209921</code> (in block <code>209920</code>), <code>490897</code> (in block <code>176684</code>) and <code>1983702</code> (in block <code>164384</code>). For block <code>209921</code> BIP30 verification is still performed still it's prior to BIP34 activation. It's not possible to create a duplicate in block <code>490897</code> (see <a href="https://github.com/bitcoin/bitcoin/blob/03042fb6bb35135566f47892b7fd15b34ca19cef/src/validation.cpp#L2297-L2311" rel="noreferrer">this code comment</a> for rationale). The next height at which a duplicate is possible is <code>1983702</code>. 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 <code>1983702</code>. This was implemented in Bitcoin Core in PR <a href="https://github.com/bitcoin/bitcoin/pull/12204" rel="noreferrer">#12204</a>.</p>
<p>I believe this is what you refer to as the &quot;block 1,983,702 problem&quot;. Starting from block 1,983,702 nodes won't be able to leverage BIP34 to avoid performing the BIP30 validation anymore.</p>
<p>If you want to learn more, see <a href="https://github.com/bitcoin/bitcoin/blob/03042fb6bb35135566f47892b7fd15b34ca19cef/src/validation.cpp#L2253-L2327" rel="noreferrer">this code comment</a> which explains the above in more details.</p>

CC BY-SA 4.0
2023-12-08T11:33:18.933Z
2023-12-08T11:44:39.643Z
2023-12-08T11:44:39.643Z
Antoine Poinsot
<p>The issue, <a href="https://github.com/bitcoin/bitcoin/pull/1526" rel="nofollow noreferrer">transition to requiring block height in block coinbases</a>, was discussed back in 2012, however I just stumbled upon it, and would like to understand more about its significance.</p>

CC BY-SA 4.0
2023-12-08T11:03:40.283Z
Related: https://bitcoin.stackexchange.com/questions/120836/is-it-possible-for-the-coinbase-transaction-in-block-164384-to-be-duplicated-in
delta1
<blockchain><block><coinbase-transaction>
What is the Block 1,983,702 Problem?
BitcoinFanatic
# What is the Block 1,983,702 Problem?

(Asked by: username_0 on 2023-12-08)

The issue, [transition to requiring block height in block coinbases](https://github.com/bitcoin/bitcoin/pull/1526), was discussed back in 2012, however I just stumbled upon it, and would like to understand more about its significance.

**Tags:** blockchain, block, coinbase-transaction

> **Comments:**
> **username_1**: Related: https://bitcoin.stackexchange.com/questions/120836/is-it-possible-for-the-coinbase-transaction-in-block-164384-to-be-duplicated-in  

---

## 2 answers

### Answer by username_2 on 2023-12-08. Score: 10 | Accepted answer

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](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki) 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](https://github.com/bitcoin/bitcoin/pull/6931).

However, [#6931](https://github.com/bitcoin/bitcoin/pull/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](https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd) 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](https://github.com/bitcoin/bitcoin/blob/03042fb6bb35135566f47892b7fd15b34ca19cef/src/validation.cpp#L2297-L2311) 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](https://github.com/bitcoin/bitcoin/pull/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](https://github.com/bitcoin/bitcoin/blob/03042fb6bb35135566f47892b7fd15b34ca19cef/src/validation.cpp#L2253-L2327) which explains the above in more details.


---

### Answer by username_1 on 2023-12-08. Score: 4

My understanding of the problem is:

The coinbase transaction in block `164384` ([`3aa03753fc`](https://mempool.space/tx/3aa03753fc238b38f4db9e5889362f3a6f0900d602baa8c9a7e789cb13ca1462)) 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](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki) 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.


---

