BIP 34 and the Consensus Enforcement of Coinbase Height Commits

Before block height was programmatically committed inside transaction scripts, the Bitcoin protocol suffered from a subtle database vulnerability: Transaction Identifier (TXID) Collisions. If a miner mined two identical coinbase transactions with matching payout outputs, they generated identical TXIDs. Under early database rules, the second block's coinbase overwritten the first, permanently destroying the original coins.

BIP 34 (Bitcoin Improvement Proposal 34) was introduced to resolve this issue by strictly committing the Block Height inside the coinbase transaction input script.

This guide details the database collision vulnerability, the BIP 34 consensus rules, and how nodes validate height arrays.

---

🕷️ 1. The Duplicate TXID Vulnerability

In Bitcoin, a transaction's identifier (TXID) is the double-SHA256 hash of its serialized transaction data. For standard transactions, TXIDs are highly unique because they reference pre-existing, distinct UTXO inputs.

However, Coinbase Transactions have no real inputs; they spend a "null input" that carries no history. Prior to BIP 34, if a miner paid their reward to the exact same public address in two different blocks and left the coinbase signature script empty or identical, the resulting coinbase transaction serialized into the exact same byte string, yielding identical TXIDs.

This occurred twice in early Bitcoin history: * Block 91,812 duplicated the coinbase transaction of Block 91,722. * Block 91,880 duplicated the coinbase transaction of Block 91,730.

Because the active UTXO database at the time indexed records strictly by TXID, the second occurrences of these transactions simply overwrote the unspent outputs of the first blocks. This permanently locked and destroyed the unclaimed coins from the earlier blocks.

---

🛡️ 2. BIP 34 Consensus Rules

Implemented at block 227,930 (in 2012), BIP 34 established new consensus rules to ensure transaction uniqueness by embedding the Block Height into the coinbase transaction's signature script (scriptSig).

                            BIP 34 COINBASE HEIGHT VALIDATION

       [ Read Block Header ] ──► Height: e.g. 840,000
                 │
                 ▼  [Extract Coinbase Transaction]
         [ Read scriptSig ] ──► First element push (e.g. 0x03 0x80 0x30 0x0c)
                 │
                 ▼  [Verify Consistency]
       Does scriptSig height push MATCH block header height?
                 │
                 ├─► NO  ──► Block INVALID! Instant Reject.
                 └─► YES ──► Block VALID! Proceed to UTXO execution.

Script Level Specifications

Under BIP 34, the coinbase scriptSig must begin with a length-prefixed data push containing the block height as a little-endian integer:

1. Length Prefix: A single byte specifying the number of bytes used to represent the height (usually 3 or 4 bytes).
2. Height Bytes: The block height serialized in little-endian format.

For example, for a block at height 840,000: * Decimal Height: 840,000 * Hexadecimal: 0x0C3080 * Serialized Byte Array: 0x80 0x30 0x0C (Little-Endian) * BIP 34 Coinbase Script Prefix: 0x03 0x80 0x30 0x0C (where 0x03 is the length-prefix byte).

Because every block has a strictly unique block height, this push guarantees that every coinbase transaction serialized has unique bytes, yielding completely unique TXIDs and resolving the database override bug forever.

---

🚫 3. Nodes' Validation Logic

Every validating node checks this rule when a block is received: * The node reads the block height $H$ from its local block index. * The node parses the coinbase transaction of the incoming block. * The node extracts the very first push data from the coinbase scriptSig. * The node converts the byte array back to an integer. * If the parsed integer does not match $H$, the node rejects the block as invalid under consensus rules.