BitcoinMachine
TERM_DEF // BLOCK / MERKLE_ROOT
MERKLE
ROOT
Merkle Root. 32-byte root of the binary Merkle tree of TXIDs; commits the header to every included tx.

This page sits in the Block section — The 80-byte header and the transaction batch beneath it — what miners actually produce. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
Merkle Root — at a glance
BLOCK
The Merkle root is a single 32-byte hash that commits to every transaction in a block. It is produced by repeatedly hashing pairs of transaction IDs together up a binary tree — the root sits in the block header.
Why it exists
DESIGN
Transactions arrive at the network constantly, but consensus needs a synchronisation point — a moment when everyone agrees on a specific batch and ordering. The block is that batch. Its 80-byte header is what miners actually hash, and its Merkle root commits to every transaction inside, so changing any transaction breaks the whole block's identity. Without this structure there would be no proof-of-work and no canonical history.
Mechanism
HOW IT WORKS
A block is a binary serialisation: an 80-byte header followed by a varint transaction count and the transactions themselves. The header has 6 fields totalling exactly 80 bytes: version (4), previous hash (32), merkle root (32), timestamp (4), bits/target (4), nonce (4). Merkle Root is one of those moving parts.
1. Miner assembles candidate block: coinbase tx first, then fee-paying txs sorted by fee-per-weight. 2. Merkle root computed bottom-up over all txid pairs — single 32-byte commitment to the entire block body. 3. Header populated: previous block hash, merkle root, current time, current target ("bits"), starting nonce. 4. Miner double-SHA-256s the 80-byte header, checks hash < target, increments nonce, repeats until success. 5. Valid block broadcast; nodes re-validate header + every transaction + every script before accepting. 6. Accepted block becomes the new chain tip; its hash is what the *next* block's header will commit to.
Building a Merkle root from 4 transactions
EXAMPLE
txid_1 = SHA256(SHA256(tx_1)) ─┐ ├─ h_12 = SHA256(SHA256(txid_1 || txid_2)) ─┐ txid_2 = SHA256(SHA256(tx_2)) ─┘ │ ├── Merkle root txid_3 = SHA256(SHA256(tx_3)) ─┐ │ ├─ h_34 = SHA256(SHA256(txid_3 || txid_4)) ─┘ txid_4 = SHA256(SHA256(tx_4)) ─┘ Merkle root = SHA256(SHA256(h_12 || h_34)) If there is an odd number of txs at any level, the last one is duplicated and paired with itself. Storage: 32 bytes in the block header. Properties: • A change to any tx → its txid changes → its level-1 hash changes → … → Merkle root changes → block hash changes. • You can prove a specific tx is in the block by providing only the sibling hashes along its path (log₂(n) hashes). • This is why SPV wallets work: they get block headers + Merkle proofs from full nodes and verify inclusion without storing the chain.
FIXED HEADER SIZE
The header is always exactly 80 bytes — by design, so mining-hardware-asic/">mining hardware can ASIC-optimise the hash loop.
COINBASE FIRST
The first transaction in every block is the coinbase (miner reward). The rest follow in fee-priority order.
COMMITTED ORDER
Transaction order inside the block is fixed by the Merkle root — you cannot reorder without changing the block hash.
Max block weight: 4,000,000 weight units (~1 MB legacy + ~3 MB witness discount post-SegWit).
Things that catch people out
PITFALLS
  • Bitcoin's Merkle implementation has a quirk — odd numbers of leaves at any level duplicate the last leaf. This was the basis of CVE-2012-2459 (block 480k issue).
  • Don't confuse Merkle proof (proves inclusion in a specific block) with chain proof (proves the block itself is in the longest chain). SPV uses both.
  • The Merkle root commits to txids only — not to witness data. SegWit added a separate witness commitment in the coinbase tx for that.

Pages on this site that cover Merkle Root in more depth:
TERMINOLOGY
Merkle Root
32-byte root of the binary Merkle tree of TXIDs; commits the header to every included tx.
Block Header
An 80-byte structure containing version, previous block hash, Merkle root, timestamp, bits, and nonce — the input miners hash.
Block Hash
HASH256 of the 80-byte header; the value miners must drive below the target.
Block Height
Zero-based index of a block from genesis; not part of the header — derived by counting.
Block Reward
Coinbase output value: subsidy + transaction fees.
Block Subsidy
The newly-minted bitcoin in the coinbase, halving every 210,000 blocks.
Block Time (10 minutes)
Target average interval between blocks, maintained by the difficulty-adjustment/">difficulty adjustment.
Block Size
The serialized byte length of a block; SegWit replaced this with weight as the consensus limit.