Bitcoin block and chain design — headers, Merkle trees, and chain selection

Introduction

This page is L1 #3 — Block & chain design in the design-document series. It covers the block and chain layer: how transactions are batched into blocks, how blocks are linked into a chain, and how nodes select the authoritative chain tip.

The transaction design page described individual transactions — inputs, outputs, scripts, and signatures. This page moves one level up: the structures that make those transactions permanent and globally ordered.

Three questions organize the material:

1. What is a block? A timestamped container that commits a set of transactions under a single proof-of-work seal.
2. What is a chain? A sequence of blocks, each referencing its predecessor’s hash, forming an append-only ledger.
3. Which chain wins? The chain with the most accumulated proof-of-work — not the chain with the most blocks.

Where behavior differs between the Satoshi-era implementation (v0.1, January 2009) and modern Bitcoin Core (v27+ baseline), both are noted.

1. Block structure

A block consists of two parts: a compact 80-byte header that summarizes the block, and a transaction list that contains every transaction included in the block. Only the header is needed for chain-level validation; the full transaction list is needed for content-level validation.

Block anatomy

Header field breakdown

Block version evolution

2. Merkle tree

The Merkle root in the block header is a cryptographic commitment to every transaction in the block. It is constructed as a binary hash tree: leaf nodes are transaction hashes, and each internal node is the SHA-256d hash of its two children concatenated together.

Merkle tree construction

Odd-count rule. If a tree level has an odd number of nodes, the last node is duplicated to form a pair. This ensures the tree is always a complete binary tree.

Why Merkle trees

SegWit witness commitment

Modern Bitcoin Core (v27+ baseline) adds a second Merkle tree: the witness Merkle tree, whose root is committed inside the coinbase transaction’s OP_RETURN output (BIP 141). This commits the witness data (signatures, scripts) that the primary Merkle root excludes. Satoshi’s v0.1 had no witness concept; the single Merkle tree committed the complete serialized transactions including signatures.

3. Chain structure

A blockchain is a singly linked list of blocks, where each block’s header contains the SHA-256d hash of the previous block’s header. This chain of hashes makes the ledger append-only: altering any historical block would change its hash, breaking the link from the next block, and cascading through every subsequent block to the chain tip.

Chain of blocks

Immutability through cascading hashes. Each header hash is computed over all 80 bytes of the header, which includes prevBlockHash. Changing a single byte in block 2’s transaction list changes block 2’s Merkle root, which changes block 2’s header hash, which invalidates block 3’s prevBlockHash, and so on. An attacker who modifies a historical block must redo the proof-of-work for that block and every subsequent block — an exponentially increasing cost.

Fork scenarios

4. Chain selection rule

Bitcoin’s chain selection rule is the most-work chain rule: among all valid chains a node is aware of, the node follows the chain with the greatest total accumulated proof-of-work. This is commonly — and inaccurately — called the “longest chain rule.” Chain length (block count) and chain work are not the same: if the difficulty adjusts between blocks, two chains of the same height can have different total work. The protocol selects on work, not height.

Chain selection decision process

Chain selection vs fork resolution

Why “most work” and not “most blocks.” The difficulty target adjusts every 2,016 blocks. If an attacker produced blocks at a lower difficulty (e.g., on a minority fork before a difficulty adjustment takes effect), those blocks contribute less proof-of-work per block. A chain with fewer blocks but higher per-block difficulty can have more total work — and the protocol would correctly select it. Bitcoin Core tracks this as nChainWork, a 256-bit integer that accumulates the work contribution of each block.

5. Block size and weight

Satoshi’s v0.1 had no explicit block-size limit. A 1 MB maximum block size was added in 2010 (initially as an anti-spam measure). SegWit (BIP 141, activated August 2017) replaced the byte-size cap with a weight system that discounts witness data, effectively raising the maximum block capacity while maintaining backward compatibility.

Legacy size vs SegWit weight

Satoshi era vs v27+ baseline.

6. Coinbase transaction

Every block’s first transaction is the coinbase transaction — the only transaction type that creates new bitcoin. It has no inputs referencing previous UTXOs; instead, it has a single input with a null previous-transaction hash and an arbitrary data field.

Structure:

• Input: Null prevout (32 zero bytes + index 0xFFFFFFFF), plus a coinbase data field (2–100 bytes). The miner may write arbitrary data here. Since BIP 34, the first bytes must encode the block height.
• Outputs: One or more outputs distributing the block reward (subsidy + fees) to the miner’s chosen addresses.

Block reward schedule:

The subsidy halves every 210,000 blocks (approximately every 4 years) and asymptotically approaches zero. The total supply is capped at 20,999,999.9769 BTC (commonly rounded to 21 million).

Coinbase maturity. Coinbase outputs cannot be spent until 100 blocks have been mined on top of them. This rule protects against chain reorganizations that would invalidate the coinbase and leave downstream transactions without a valid input.

Notable coinbase data. Satoshi embedded the text The Times 03/Jan/2009 Chancellor on brink of second bailout for banks in the genesis block’s coinbase — a reference to a Times headline that serves as both a timestamp proof and a statement about the financial system Bitcoin was designed to circumvent.

7. Two-era comparison

8. Limits of this page

This page covers the block and chain layer in isolation. The following topics are out of scope and addressed in their respective domain pages within the design-document series:

• Transaction structure and UTXO model — how the transactions inside each block are constructed, validated, and chained. Covered in the transaction design page.
• Mining and proof-of-work — the hash puzzle that produces valid blocks, the difficulty adjustment algorithm, and block template construction.
• Consensus rules beyond chain selection — soft fork activation mechanisms (BIP 9, BIP 8), the consensus–policy boundary, and the full set of block validity rules.
• Network-layer block relay — how inv, getdata, headers, block, and cmpctblock messages propagate blocks across the P2P network.
• Storage and chain state — how validated blocks are persisted to disk (block files, undo data) and how the UTXO set is maintained in LevelDB.
• SPV client implementation — the practical use of Merkle proofs by lightweight wallets (this page describes the Merkle tree structure; the SPV protocol itself is a network-layer topic).