Merkle Root

What Is a Merkle Root?

A Merkle root is the topmost hash in a binary hash tree (called a Merkle tree) that summarizes all transactions included in a Bitcoin block. Every block header contains exactly one Merkle root, and that single 32-byte value is enough to verify whether any given transaction belongs to the block.

The concept was invented by computer scientist Ralph Merkle in 1979 and later adapted by Satoshi Nakamoto for Bitcoin. In the Bitcoin protocol, the Merkle root serves as a compact, tamper-evident commitment to the block's transaction set. If any transaction is altered, added, or removed, the Merkle root changes entirely, making fraud immediately detectable.

This design is what makes lightweight wallets possible. Instead of requiring every user to download and store every transaction, the Merkle root lets SPV clients verify individual transactions using only the block headers and a short proof path.

How It Works

Computing a Merkle root starts at the bottom of the tree with the raw transactions and works upward through repeated rounds of hashing until a single hash remains.

1. Every transaction in the block is serialized and hashed with double SHA-256 to produce its TXID. These TXIDs become the leaf nodes of the tree. The coinbase transaction is always the first leaf.
2. Adjacent TXIDs are paired: the first with the second, the third with the fourth, and so on. Each pair is concatenated (64 bytes total) and hashed with double SHA-256 to produce a parent node.
3. If a level has an odd number of nodes, the last node is duplicated and paired with itself before hashing.
4. This process repeats at each level: parent nodes are paired and hashed to create grandparent nodes, and so on, until only one hash remains.
5. That final hash is the Merkle root. If the block contains only one transaction (the coinbase), its TXID is the Merkle root directly.

Computation Example

Consider a block with four transactions (A, B, C, D). The tree is built bottom-up:

        Merkle Root
        /          \
     H(AB)        H(CD)
     /   \        /   \
   H(A)  H(B)  H(C)  H(D)    ← leaf nodes (TXIDs)

H(A)  = SHA256(SHA256(tx_A))
H(AB) = SHA256(SHA256(H(A) || H(B)))
Root  = SHA256(SHA256(H(AB) || H(CD)))

With three transactions (A, B, C), the last TXID is duplicated to create an even count:

        Merkle Root
        /          \
     H(AB)        H(CC)      ← C is duplicated
     /   \        /   \
   H(A)  H(B)  H(C)  H(C)

This duplication happens at every level of the tree where the node count is odd, not only at the leaf level.

Position in the Block Header

The Bitcoin block header is exactly 80 bytes and contains six fields. The Merkle root occupies the third field:

When miners perform proof of work, they hash this entire 80-byte header. Because the Merkle root is embedded in the header, any change to any transaction invalidates the block's proof of work, forcing the miner to start over. This is how Bitcoin's consensus mechanism binds the transaction set to the block's proof of work.

Merkle Proofs and SPV

The Merkle root's most important practical application is enabling Merkle proofs, which allow lightweight clients to verify transaction inclusion without downloading full blocks. This concept was described in Section 8 of the Bitcoin whitepaper as Simplified Payment Verification (SPV).

To verify that a transaction exists in a block, an SPV client needs only the block headers (about 4.2 MB per year of chain growth) and the sibling hashes along the path from the transaction's leaf to the Merkle root. For a block with n transactions, this proof requires only ceil(log₂n) hashes:

• 1,024 transactions: 10 hashes (320 bytes)
• 4,096 transactions: 12 hashes (384 bytes)
• 1,000,000 transactions: ~20 hashes (640 bytes)

The verifier reconstructs the path from the transaction's TXID up to the root, hashing with each sibling along the way. If the computed root matches the Merkle root in the block header, the transaction is proven to be included. For a deeper look at how lightweight clients use this mechanism, see the research article on Bitcoin light clients and SPV.

SegWit Witness Commitment

Segregated Witness (BIP 141) introduced a parallel Merkle tree for witness data. A separate witness Merkle root is computed from witness transaction IDs (wtxids), which include the signature data that regular TXIDs exclude. This witness commitment is stored in an OP_RETURN output of the coinbase transaction, maintaining backward compatibility as a soft fork.

Use Cases

Lightweight Wallet Verification

Mobile wallets and browser-based clients cannot store the full blockchain (hundreds of gigabytes). By downloading only block headers and requesting Merkle proofs for their own transactions, these clients can verify payments with minimal bandwidth and storage. This is the foundation of SPV wallets and protocols like compact block filters (BIP 157/158).

Mining and Block Construction

Miners compute a new Merkle root every time they adjust the transaction set in their candidate block. When searching for a valid nonce, miners sometimes modify the coinbase transaction (changing the extra nonce field), which changes the first leaf and cascades through the entire tree to produce a new Merkle root and therefore a new block header hash.

Cross-Chain and Layer 2 Verification

Merkle roots and Merkle proofs are used beyond Bitcoin's base layer. Layer 2 protocols and sidechains use similar tree structures to commit to off-chain state. For example, systems like Spark can reference on-chain Merkle roots to anchor off-chain transactions back to Bitcoin's security.

Risks and Considerations

CVE-2012-2459: Merkle Tree Mutation

The duplicate-last rule that handles odd transaction counts introduced a subtle vulnerability. An attacker could take a valid block and append duplicates of its last transactions to create an invalid block that produced the same Merkle root (and therefore the same block hash). For example, transaction lists [1, 2, 3, 4, 5, 6] and [1, 2, 3, 4, 5, 6, 5, 6] could generate identical Merkle roots.

The invalid block would be rejected by nodes (duplicate transactions violate consensus rules), but Bitcoin Core cached rejected block hashes. If a node received the mutant block first, it would reject and cache the hash. When the legitimate block arrived later with the same hash, the node would reject it too, thinking it had already processed that block.

Discovered by Forrest Voight and disclosed in May 2012, this was a denial-of-service vulnerability: it could isolate victim nodes from the network but could not be used to steal funds. Bitcoin Core versions before 0.4.6 were affected. The fix detects when two identical hashes would be paired at the end of a tree level and flags the block as having a mutated Merkle tree.

64-Byte Transaction Ambiguity

A related weakness (CVE-2017-12842) arises because internal Merkle tree nodes and leaf nodes use the same hash function without domain separation. Two 32-byte internal digests can be misinterpreted as a 64-byte transaction and vice versa, potentially deceiving SPV clients. The Bitcoin community has proposed invalidating 64-byte transactions via a soft fork as part of the Great Consensus Cleanup proposal to permanently eliminate this attack vector.

SPV Trust Assumptions

While Merkle proofs allow efficient verification that a transaction is included in a block, they do not prove that the block itself is valid. An SPV client trusts that miners have validated the block's transactions correctly. A majority of dishonest miners could theoretically produce a valid proof-of-work block containing invalid transactions. For applications requiring stronger guarantees, running a full Bitcoin node remains the gold standard.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.