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.

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?