BIP 34: Enforcing Block Height in the Coinbase Script

Prior to 2012, it was mathematically possible for different blocks to generate identical coinbase transactions. Because transaction hashes (TXIDs) are calculated purely from their serialized data, identical coinbase transactions produced identical TXIDs, leading to critical database overwrite vulnerabilities.

To permanently patch this, BIP 34 introduced a strict consensus rule requiring miners to include the Block Height as the first item in the coinbase script.

🔒 1. The Duplicate TXID Collision Bug

In the early years of Bitcoin, miners mined block rewards to identical public key script addresses without changing the coinbase script text. * The Collisions: * Block 91,722 and Block 91,812 generated identical coinbase transactions. * Block 91,842 and Block 91,880 also generated identical coinbase transactions. * The Database Overwrite: When Block 91,812 was mined, its coinbase transaction was processed by nodes. Because the TXID already existed in the node's UTXO database (from Block 91,722), the old UTXO entry was overwritten and lost before it could be spent, permanently locking those original coins.

Since transactions are identified by their TXID, having two distinct transactions on the blockchain with the same TXID broke key assumptions in the database architecture of Bitcoin nodes.

🛠️ 2. The BIP 34 Specification

Standardized in BIP 34 (activated at block 227,835), the protocol enforced a new consensus rule:

The Rule: The signature script of the coinbase transaction must contain the block height serialized as its first data push element.

                           BIP 34 HEIGHT DATA PUSH LAYOUT

                           [ Raw Coinbase Script ]
                                      │
               ┌──────────────────────┴──────────────────────┐
               │                                             │
      [ Length Byte ]                                 [ Block Height ]
   • Specifies length of height                    • Serialized in Little Endian
   • e.g. \x03 (3 bytes)                           • e.g. \xc0\xd0\x0c for 840,000

Script Format:

1. Length Byte: A single byte defining the number of bytes required to represent the block height integer.
2. Block Height: The height integer, serialized as a signed little-endian array.

---

📐 3. Step-by-Step Serialization Example

Let's serialize the block height for block 840,000 (the 2024 halving block height):

Step A: Convert Height to Hexadecimal

$$840,000 = \texttt{0x0CD0C0}$$

Step B: Apply Little-Endian Serialization

A little-endian conversion reverses the byte order of the integer: $$\text{Big Endian: } \texttt{0C D0 C0} \quad \Longrightarrow \quad \text{Little Endian: } \texttt{C0 D0 0C}$$

Step C: Define the Length Prefix

The height value \xC0\xD0\x0C is exactly $3\text{ bytes}$ long, so we prefix it with the length byte \x03.

Step D: Compile the BIP 34 Script Header

$$\text{Serialized Height Prefix} = \texttt{03 C0 D0 0C}$$

This prefix must be the absolute first data push in the coinbase signature script. Because this prefix contains the unique block height, no two coinbase transactions can ever have identical serialized data, preventing future TXID collisions on the network.