Hashing, Merkle Trees and Block Headers, Explained

A block can hold thousands of transactions. If you wanted to prove that one specific payment of yours is really in there, the naive way would be to hand someone the entire block and let them check. That doesn't scale — full nodes would need to ship gigabytes of data just to answer "is my transaction included?" The actual answer uses a hash tree that compresses every transaction in the block down to a single 32-byte number, while still letting anyone verify one transaction's membership with only a handful of extra hashes.

A hash function turns any input into a fixed-size fingerprint that changes completely if even one bit of the input changes. A Merkle tree repeatedly hashes pairs of fingerprints together until only one remains — the Merkle root — so that root alone certifies every transaction underneath it, and a short "proof path" of sibling hashes is enough to check any single one.

Fingerprints that can't be faked backward

A cryptographic hash function (SHA-256, for Bitcoin) takes any input — a transaction, a block, a word — and outputs a fixed-length string that looks random. Two properties make it useful here: it's effectively impossible to find two different inputs producing the same output, and changing a single character of the input produces a completely different output. This means a hash is a reliable fingerprint: if you know the correct hash of something, you can verify a copy of it matches without re-reading the whole thing.

Building the tree

Take a block's transactions and hash each one individually. Then pair up those hashes and hash each pair together, producing half as many hashes. Repeat — hash pairs of hashes — until only one hash remains: the Merkle root. That single value is what actually goes into the block header.

To prove tx B is in the block, you only need hash(A) and hash(C,D) — two siblings, not all four transactions.

Worked example

A block has four transactions, A, B, C, D. Hash A and B together to get node AB; hash C and D together to get node CD; hash AB and CD together to get the Merkle root. To prove B is included, a light client only needs three things: B itself, hash(A), and node CD. It computes hash(B), combines it with hash(A) to reconstruct AB, combines AB with CD to reconstruct the root, and compares that to the root already stored in the block header. If they match, B is definitely in the block — without the client ever downloading C or D. For a block with 2,000 transactions, this "Merkle proof" needs only about 11 hashes (log₂ 2000 ≈ 11), not 2,000.

What this means in practice

The block header — a small, fixed-size piece of data containing the Merkle root, the previous block's hash, a timestamp, and a difficulty target — is what nodes actually pass around to establish the chain of blocks. Chaining each header to the previous block's hash is what makes the blockchain tamper-evident: changing one transaction in an old block changes its hash, which changes the Merkle root, which changes that block's header hash, which breaks every subsequent block's reference to it. This is also the basis of "light clients" (like mobile wallets) that verify payments without storing the full blockchain — they trust headers and Merkle proofs instead of full blocks.

A Merkle proof shows a transaction is included in a block whose header you already trust — it says nothing about whether that block itself is part of the longest, most-worked chain. Light clients still need to separately track which chain of headers is the legitimate one; a fake chain with fabricated headers can produce perfectly valid-looking Merkle proofs for fake transactions.

Hashing, Merkle Trees and Block Headers

Fingerprints that can't be faked backward

Building the tree

Worked example

What this means in practice

Related concepts

Practice in interviews

Further reading