Why blockchains are hard to change
Immutability is not magic — it is hash functions plus economics. Change a byte in an old block and you must rebuild everything above it, faster than the rest of the network extends the real chain.
In this lesson
- Trace how one edit invalidates every later block
- Explain confirmations as accumulated work
- Give an example of a successful deep reorganisation
One edit, total breakage
Each block stores its parent's hash. Edit an old transaction and the old block's Merkle root changes, so its hash changes, so the next block's previous_hash no longer matches — and the mismatch cascades to the tip in seconds. Honest nodes reject your branch instantly.
Example · Rewriting six confirmations
Suppose your transaction sits six blocks deep. To reverse it, an attacker must re-mine those six blocks and outpace the entire network doing it — while other miners keep extending the honest chain. Six confirmations ≈ re-doing days of global computation. That is why exchanges wait.
def is_valid(chain):\n for prev, block in zip(chain, chain[1:]):\n if block["previous_hash"] != hash_block(prev):\n return False # someone edited the past\n if not meets_target(block):\n return False # block was not properly mined\n return TrueImmutability is probabilistic
"Final" means "irreversibly expensive", not "mathematically impossible". Deep reorganisations have happened on small chains during attacks or bugs — which is exactly why confirmation depth is a policy choice, not a constant.
Tamper with history
Mine a chain, edit block 2 in the lab, and watch validation fail at exactly the block you touched.
What happens to the Merkle root?
Practice · server-gradedWhy not just store the whole chain encrypted?
Public verifiability is the feature. The chain stays auditable; privacy comes from addresses, mixers or zero-knowledge proofs at the application layer.
Does pruning change this?
Nodes can discard old block bodies and keep headers — the hash links still chain, and any lie about the past is still detectable.