Chaining Blocks: prev-hash & immutability

We’ve seen that a block is a header plus transactions, and that the header carries a field called the previous block hash. This page is about that one field, because it is the hinge on which the word “blockchain” turns. The prev-hash is what makes the data structure a chain rather than a heap — and it is the entire reason rewriting Bitcoin’s history is expensive instead of trivial. The cryptography here is humble; the consequence is profound. This is the structural half of Satoshi’s synthesis.

The link: each header points backward

Every block header includes the double-SHA-256 hash of the previous header. So the blocks form a backward-pointing linked list:

   Block N-1            Block N              Block N+1
 ┌────────────┐      ┌────────────┐      ┌────────────┐
 │ header     │      │ header     │      │ header     │
 │  prev: ●───┼──┐   │  prev: ●───┼──┐   │  prev: ●───┼──► ...
 │  merkle    │  │   │  merkle    │  │   │  merkle    │
 │  ...       │  └──►│  (hashes    │  └──►│  (hashes   │
 └────────────┘  hash│   N-1's     │  hash│   N's      │
       ▲          of  │   header)   │   of │   header)  │
       │              └────────────┘      └────────────┘
   hash of N-1's        hash of N's
   full header          full header

Each arrow is a hash. The header of block N contains a fingerprint of block N-1’s header — which itself contains a fingerprint of N-2’s, and so on, all the way back to the genesis block, the hardcoded first block with a prev-hash of all zeros. There is exactly one unbroken chain of hashes from any block back to the beginning.

Why this makes history tamper-evident

Here is the whole point. Suppose an attacker wants to change a transaction in an old block — say, block 100 — to erase a payment they made. Watch what cascades:

1. They edit a transaction in block 100.
2. → block 100's MERKLE ROOT changes (the tx tree is rebuilt).
3. → block 100's HEADER changes (the root is a header field).
4. → block 100's HASH changes (the hash IS the header's double-SHA-256).
5. → block 101's "prev block hash" no longer matches block 100.   ✗ BROKEN
6. To fix that, they must change block 101's header...
7. → which changes 101's hash...
8. → which breaks block 102...  and on, and on, to the chain tip.

Changing one old transaction forces the attacker to rebuild every single block after it. And each of those blocks was only valid because it carried proof of work — a header whose hash falls below the target. So rebuilding them means redoing all that work, while the honest network keeps extending the real chain ahead of them.

Hashes turn “edit the past” into “out-mine the planet”

Without the prev-hash link, editing block 100 would be a local change — fix one block, done. The chaining is what converts a cheap, local edit into a demand to re-mine everything from block 100 to the present, faster than the entire rest of the network combined. That impossibility is Bitcoin’s immutability. The history isn’t protected by a law or a company — it’s protected by arithmetic.

”Immutable” really means “expensive to rewrite”

It’s worth being precise. Nothing physically prevents someone from producing an alternative chain that forks off at block 100. The protocol doesn’t forbid it — it makes it economically hopeless, for two compounding reasons:

Defense	What it costs the attacker
The chain links (this page)	Must redo every block from the edit point forward
Most-work rule (consensus)	Must out-pace the honest network’s ongoing hashing, too

The deeper a block is buried — the more blocks stacked on top — the more work an attacker must redo, so older history is exponentially more settled than recent history. This is exactly why we wait for confirmations and why reversing a deeply-buried transaction is considered practically impossible. The mechanics of competing chains are covered in Orphans & Reorgs.

Tamper-evident, not tamper-proof

The chain doesn’t stop tampering — it makes tampering instantly visible. Any node can recompute the hashes and spot a broken link in microseconds. A forged history is not undetectable-but-illegal; it is detectable-and-rejected. Every honest node will simply refuse a chain whose links don’t add up. That’s a stronger guarantee than secrecy: you don’t have to trust that no one cheated, because cheating can’t be hidden.

The thread

How does this help untrusting strangers agree on one ledger? The prev-hash link gives every participant a way to check, with nothing but arithmetic, that the entire history is internally consistent — that no block was inserted, removed, or edited after the fact. Two strangers who trust nothing about each other can each hash the chain from genesis to tip and confirm they’re looking at the same history, with the same order of transactions, backed by the same accumulated work. The chain of hashes is the shared, append-only spine that lets a leaderless network agree not just on the present balance sheet, but on the unforgeable record of how it got there.

The architect’s lens

Step back from the one field that makes a chain and answer the five questions that turn an implementer into an architect:

• Why does it exist? So that each header carries the double-SHA-256 of its parent’s header — one 32-byte field that welds blocks into a single backward-pointing line reaching all the way to the genesis block.
• What problem does it solve? It makes history tamper-evident: editing one old transaction cascades through that block’s Merkle root → header → hash → the next block’s prev-hash, so changing block 100 forces re-mining every block after it.
• What are the trade-offs? It buys only evidence, not prevention — nothing forbids a fork off block 100; it merely makes rewriting cost a re-mine of everything since, which is why chaining alone is incomplete and must combine with the most-work rule.
• When is a different design better? If a trusted operator can simply sign and timestamp records, you don’t need prev-hash immutability at all — a signed append-only log gives tamper-evidence without burning energy to make rewrites expensive.
• What breaks if I remove it? Without the link, editing an old block becomes a cheap local change — “edit the past” stops meaning “out-mine the planet,” confirmations stop accumulating security, and the “chain” collapses into an unordered heap of blocks with no enforced history.

Check your understanding

1. What does the “previous block hash” field contain, and where does the chain of these links ultimately terminate?
2. Walk through the cascade that occurs when someone edits a transaction in an old block. Why does it not stay local?
3. Why does the chaining alone not make history immutable — what second defense must combine with it?
4. Explain why a transaction buried under more blocks is harder to reverse than a recent one.
5. Distinguish “tamper-evident” from “tamper-proof.” Why is evidence enough for a network of untrusting strangers?

Show answers

1. The double-SHA-256 hash of the previous header. Following these links backward terminates at the genesis block — the hardcoded first block, whose prev-hash is all zeros.
2. Editing a transaction in (say) block 100 rebuilds its Merkle root → changes its header → changes its hash → so block 101’s “prev block hash” no longer matches → to fix that you must change 101’s header → which breaks 102 → and on to the chain tip. It can’t stay local because each header’s hash is welded into the next block’s prev-hash field.
3. Chaining only makes you redo every block from the edit point forward; on its own that’s a one-time cost. The second defense is the most-work rule (the most-work chain): you must also out-pace the honest network’s ongoing hashing to overtake the real chain.
4. The deeper a block is buried, the more blocks stacked on top, so an attacker must redo all that accumulated proof of work and out-mine the honest network from the fork point — older history is exponentially more settled, which is why we wait for confirmations.
5. Tamper-proof would mean tampering is impossible; tamper-evident means tampering is instantly visible — any node recomputes the hashes and spots a broken link in microseconds. Evidence is enough because a forged history is detectable-and-rejected: you don’t have to trust that no one cheated, because cheating can’t be hidden.