A Subtle Merkle Tree Vulnerability in Bitcoin (And How It Was Fixed)

When people talk about Bitcoin’s security, Merkle trees are often mentioned as a solved, rock-solid concept. And mostly, they are. But in Bitcoin’s early days, a very subtle edge case in Merkle tree construction led to a real vulnerability — one that didn’t break cryptography, but broke assumptions.

This post explains:

• What the Merkle mutation vulnerability was
• Why it existed despite using SHA-256
• Why explicit duplication is dangerous, but implicit duplication is safe
• How Bitcoin fixed it without a hard fork

Merkle Trees in Bitcoin (Quick Recap)

Each Bitcoin block contains a list of transactions. Instead of storing all transaction hashes in the block header, Bitcoin stores a Merkle root, computed like this:

1. Hash each transaction → leaves
2. Pair hashes and hash them together
3. Repeat until one hash remains (the root)

At every internal node, Bitcoin computes:

H(left || right)

where || means concatenation.

The Odd-Number Rule

What happens if a level has an odd number of hashes?

Bitcoin uses a simple rule:

Duplicate the last hash and continue.

Example:

A, B, C
→ A, B, C, C
→ H(A||B), H(C||C)

This is intentional, documented, and necessary, because blocks do not usually have a power-of-two number of transactions.

So far, so good.

The Subtle Problem: Two Different Lists, Same Merkle Root

Now here’s the surprising part.

Consider these two transaction lists:

List 1: [1, 2, 3, 4, 5, 6]
List 2: [1, 2, 3, 4, 5, 6, 5, 6]

At first glance, these are clearly different.

But under Bitcoin’s Merkle construction rules, both can produce the same Merkle root.

Why?

The Real Equality (And a Common Misconception)

A common misunderstanding is to think:

H(C) == H(C || C)

This is false and never happens.

What actually happens is this:

Merkle([…, C]) == Merkle([…, C, C])

Why?

• In the first case, the algorithm duplicates C
• In the second case, the duplication is already present
• In both cases, the parent hash is computed as:

H(C || C)

Same input → same output → same Merkle root

So two different transaction lists can commit to the same Merkle root.

Why This Is a Vulnerability

This enables a Merkle tree mutation attack:

1. A valid block is mined and broadcast
2. An attacker modifies the transaction list by duplicating the last transaction(s)
3. The Merkle root stays the same
4. The block hash stays the same
5. But the transaction list is now invalid

Now comes the dangerous part:

• A node receives the mutated block
• It fails validation
• It marks that block hash as permanently invalid
• Later, it refuses the real valid block with the same hash

This doesn’t break cryptography — it breaks block validation logic.

The Key Insight: Explicit vs Implicit Duplication

Bitcoin’s fix is based on a very clean idea:

Only the Merkle algorithm itself is allowed to introduce duplication.

Implicit duplication (allowed)

• Happens when a level has an odd number of hashes
• Introduced by the algorithm

Example:

A, B, C → A, B, C, C

Explicit duplication (rejected)

• The data already contains the duplicate

Example:

A, B, C, C   ← already duplicated

This second case creates ambiguity and is now treated as invalid.

How Bitcoin Detects This

During Merkle tree construction, Bitcoin checks:

“Am I about to hash two identical hashes together at the end of a level?”

If yes:

• The block is marked as mutated
• The Merkle root is treated as invalid
• The block is rejected

This works because, assuming no SHA-256 collisions:

• Identical hashes appearing naturally at the end is astronomically unlikely
• So identical final pairs strongly indicate duplication

Important Clarification

This does not mean:

• The number of transactions must be a power of two ❌
• Duplication is never allowed ❌

It means:

• Explicit duplication is forbidden
• Implicit duplication by the algorithm is allowed

Most Bitcoin blocks rely on implicit duplication.

Why This Fix Is Elegant

• No change to the hash function
• No change to block headers
• No hard fork
• Just an additional consensus rule

It restores a critical property:

The Merkle root uniquely commits to the transaction list.

Final Takeaway

The vulnerability wasn’t about weak hashing — it was about ambiguity.

Bitcoin allows the Merkle tree to add a duplicate, but forbids the data from already containing one at the edge.

This tiny distinction closed a real consensus vulnerability and remains one of the best examples of how details matter in distributed systems.