Blocks & Hashes: Why You Can’t Quietly Rewrite History

Each block carries a fingerprint of the one before it — so editing any old entry shatters every fingerprint after it, in plain sight.

Crypto & Tokenization · Lesson 4 · 9 min read

A skeptic corners you: “These records are just data sitting on computers. What stops someone — a hacker, the people running it, a government — from going back and quietly editing an old transaction to steal coins or erase a debt? With a bank, you’d never even know if they fudged the books.” It’s a fair challenge, and the answer is a surprisingly simple trick with digital fingerprints. Hold the question; by the end you’ll be able to explain why changing one old entry would force someone to redo everything after it — out in the open.

A hash is a digital fingerprint

A hash function takes any data — a word, a file, a list of transactions — and produces a short, fixed-length string of characters: its hash. It has four properties that make it perfect for catching tampering:

• Same input always gives the same hash.
• Change the input even slightly and the hash comes out completely different.
• You can’t run it backward to recover the original data from the hash.
• You can’t feasibly find two different inputs with the same hash.

So a hash is a tiny tamper-detector: record the fingerprint now, recompute it later, and if it differs by even one character, you know the data was changed.

Hashing two almost-identical records (illustrative — real hashes are longer):
• “Alice pays Bob 5” → hash 9f2a1c…
• “Alice pays Bob 6” → hash 4e7b03…
One digit changed, and the fingerprint is unrecognizably different. There’s no “close” — any edit, however small, is loud.

Blocks chain by carrying the previous fingerprint

Transactions are bundled into a block. Each block’s header includes the hash of the block before it. That single inclusion is what turns a pile of blocks into a chain — hence “block-chain.”

Picture numbered pages in a notebook where the top of every page copies down a fingerprint of the entire previous page. Page 101 records the fingerprint of page 100; page 102 records the fingerprint of page 101; and so on. Each page is now tied to its predecessor by that recorded fingerprint.

Why you can’t quietly rewrite history

Now watch what an edit does. Suppose someone changes a transaction in block 100. That instantly changes block 100’s hash. But block 101 stored the old hash of 100 as its “previous hash” — so it no longer matches, and the chain visibly breaks at 101. And 102 was tied to 101, and 103 to 102… the break cascades all the way to the present.

To make the edit “fit,” the attacker would have to recompute block 101, then 102, then every block after — and keep up as the honest network keeps adding new blocks on top of the original chain. (Module 2 is all about why producing valid blocks is deliberately made expensive, so winning that race is infeasible.) The precise takeaway: a blockchain isn’t tamper-proof — you can always attempt an edit. It’s tamper-evident: any edit is immediately visible to anyone who checks the fingerprints. That is exactly what “immutable” really means here, and you can verify it yourself.

A tamper attempt, start to finish:
1. The ledger has blocks 1–200. Block 100 records “Mallory paid Sam 10 coins.”
2. Mallory wants to erase that debt, so she edits block 100 to read “Mallory paid Sam 0.”
3. Block 100’s hash instantly changes — a one-character edit yields a totally different fingerprint.
4. Block 101 stored the OLD hash of 100 as its “previous hash,” so now they don’t match: the chain is visibly broken from 101 onward, and anyone checking sees it.
5. To hide it, Mallory must recompute 101, 102, … 200 — and then out-pace the honest network as it adds 201, 202, … on the original chain. That race is made prohibitively expensive (next module), so her edit is caught, not hidden. Tamper-evident, exactly as advertised.