BIP 34 (Coinbase Height): The Anchor Guide to TXID Uniqueness

🔍 Why This Module Matters

In the early days of Bitcoin, a subtle bug existed: if a miner paid themselves 50 BTC in two different blocks using the exact same address, the resulting transactions were identical. This caused the second block to "Overwrite" the first one in the database, effectively deleting the coins from the first block forever. BIP 34 is the mathematical cure for this problem. It turns the "Block Height" into a unique salt that ensures no two transactions in Bitcoin history will ever share the same ID.

🏛️ The "Duplicate TXID" Bug (The Overwrite Crisis)

To understand BIP 34, you must understand the "TXID Collision" problem.

1. The Formula: A Transaction ID (TXID) is the double-SHA256 hash of the transaction's bytes.

2. The Coincidence: In blocks 91,812 and 91,880, miners used the exact same payout address as they did in earlier blocks.

3. The Result: Because the coinbase "input" was empty and the outputs were identical, the TXIDs were identical.

4. The Loss: When the second block was mined, the node's database thought: "Oh, I already have this transaction. I'll just update it." This deleted the record of the unspent 50 BTC from the first block.

⚙️ The Solution: Committing Height in Script

BIP 34 mandates that the coinbase scriptSig must start with a "push" of the block height.

For Block 850,000:

• The Height: 850,000 (Decimal)

• The Hex: 0x0CFE50

• The Byte Order (Little-Endian): 50 FE 0C

• The Script Commit: 03 50 FE 0C (where 03 is the length of the data).

graph LR
 A[Block Header] -->|Implicit Height| B[850,000]
 C[Coinbase Tx] -->|Explicit Height| D[03 50 FE 0C]
 B === D
 D -->|Matches?| E{Valid?}
 E -- YES --> F[Block Accepted]
 E -- NO --> G[Block REJECTED]
 style F fill:#9f9,stroke:#333,stroke-width:2px
 style G fill:#f66,stroke:#333,stroke-width:2px

🛠️ The Technical Specifications of BIP 34

BIP 34 didn't just fix a bug; it introduced a standard for "versioned" block rewards.

1. Strict Enforcement: Nodes will instantly reject any block above height 227,930 that does not contain the correct height in the coinbase.

2. Length Prefix: The first byte of the scriptSig must specify how many bytes follow (usually 3 or 4).

3. Future-Proofing: As the block height grows into the millions and billions, the height commit will automatically expand to 4 or more bytes.

🛡️ Side Benefits: Time and Context

By committing the block height into the transaction data, BIP 34 provided secondary benefits to the network:

• Script-Level Context: Future opcodes (like OP_CHECKBLOCKATHEIGHT) can now use the coinbase height to verify exactly where a transaction lives in time.

• SPV Security: Light clients (SPV) can now verify that a block is at a specific height just by looking at the coinbase transaction, without needing the full block index.

🎯 Learning Objectives for this Module

By the end of this module, you will be able to:

1. Define a TXID collision and explain how it can lead to the permanent loss of bitcoin.

2. Describe the BIP 34 rule and how it is enforced by nodes.

3. Identify the specific format of the height commit in a raw coinbase script.

4. Trace the historical events (Blocks 91,722 & 91,812) that necessitated this upgrade.

5. Explain why the "null input" of a coinbase transaction made collisions possible in the first place.

🗺️ Module Roadmap: What's Next?

Now that we've seen how Bitcoin ensures unique identity, we will look at the competition:

1. The Most Work Rule: How the network picks the winning branch during a collision.

2. Byzantine Generals' Problem: How PoW solves the problem of decentralized truth.

3. Natural Forks & Latency: Why reorgs happen even without attacks.

4. Python Coinbase Auditor: Writing a script to extract and verify the BIP 34 height from a raw block.

🎓 Summary

BIP 34 is the "Fingerprint" rule of Bitcoin. It ensures that every single satoshi generated in the coinbase has a unique, verifiable origin that can never be overwritten or confused. By mastering BIP 34, you are understanding the deep architectural safeguards that protect the integrity and persistence of the Bitcoin ledger.