Why is a blockchain hard to rewrite?

"Immutable" gets said about blockchains constantly, usually without explanation. Nobody promises it. It falls out of two ordinary pieces of computer science stacked on each other.

Piece one: the hash function

A cryptographic hash function takes an input of any size and returns a fixed-length output — for Bitcoin, 256 bits, written as 64 hexadecimal characters. It has three properties that matter here:

• Deterministic. The same input always gives the same output.
• One-way. Given an output, you cannot work backwards to the input.
• Avalanche. Change one character of the input and the output changes completely — not slightly, entirely.

So a hash is a fingerprint. If two people hold the same data, they compute the same hash. If one character differs anywhere, the hashes disagree instantly.

Piece two: the chain

Each block contains a header, and the header contains the hash of the previous block's header. That single field is the chain.

Follow the consequence:

1. You want to alter one transaction in block 900,000.
2. Altering it changes that block's contents, so its hash changes.
3. Block 900,001 stored the old hash in its "previous block" field. It no longer matches.
4. So block 900,001 must be rebuilt too — which changes its hash, which breaks 900,002, and so on to the tip of the chain.

Editing one entry means rebuilding every block after it. That is the structural half of immutability, and it is pure arithmetic — no economics involved yet.

Piece three: and you must do it faster than everyone else

Rebuilding blocks is not free. On Bitcoin, producing a valid block requires an enormous amount of computation (Unit 4 explains exactly what). On Ethereum it requires staked capital.

So to rewrite history, you must redo the work for your target block and every block after it, and you must do it faster than the entire honest network is adding new blocks on top — because proof-of-work nodes follow the chain with the most accumulated work, not the one that arrived first. Proof-of-stake chains settle the same question differently — Ethereum's fork choice weighs attestations and finalises checkpoints — but the shape of the defence is the same: rewriting means out-running everybody honest.

This is why depth matters and gets its own word: confirmations.

• 0 confirmations — broadcast, not yet in a block. Nothing is settled.
• 1 confirmation — in the most recent block. Reversible with modest effort.
• 6 confirmations — five blocks have been built on top. On Bitcoin that is roughly an hour of network-wide effort an attacker would have to beat.

A payment is not "done" when it is sent. It is done when it is buried.

Confirmations are Bitcoin's measure and they are probabilistic: each block makes reversal more expensive, never impossible. Ethereum since the Merge adds a second kind of settlement. Validators vote on a checkpoint every 32 slots (6.4 minutes); a checkpoint with two consecutive supermajority votes is finalised, roughly 13 minutes after a block. Reversing a finalised block would require at least one third of all staked ETH to be slashed, so venues treat finality as the point of no return rather than counting blocks past it. Other chains have their own rules (Solana's "finalized" commitment level, for example). That is why every venue publishes a per-asset table of required confirmations: those numbers are its policy about reversal risk, not a protocol constant.

It has actually failed — on small chains

Shallow reorganisations of one or two blocks happen naturally when two miners find a block at nearly the same moment; the network converges within minutes and the losing block's transactions return to the queue.

Deep, deliberate rewrites are different, and they are documented. Bitcoin Gold (2018) and Ethereum Classic (2019 and 2020) both suffered attacks in which someone rented enough hash power to rewrite recent history and spend the same coins twice. The lesson is precise: immutability is proportional to how expensive the chain is to attack, and small chains are cheap.

Try it now

1. On a public block explorer, open a recent block and copy its hash. Then open the block above it and find the field labelled "previous block hash" or "parent hash". They are the same string — you have just verified one link of the chain by eye.
2. Look at the timestamps of the last ten Bitcoin blocks. The target is one every ten minutes; note how irregular the real intervals are.
3. Open any transaction and find its confirmations count. Watch it increase by one each time a block is added. That number is the cost an attacker would have to pay to undo it.