The Padlock That Locks Every Padlock Before It
You want to change a payment in an old Bitcoin block. Maybe the amount, maybe the destination address. You find the block, locate the transaction, alter a single byte. Done. Except now the Merkle root is wrong, the block header is wrong, the hash is wrong, and you've just volunteered to redo the proof of work for that block and every single block that came after it. Good luck.
The mechanism doing this work is the cryptographic hash function. Specifically, Bitcoin uses SHA-256 applied twice (SHA-256d) for collision resistance. Understanding why this prevents block malleability at the protocol level is one of those things most explainers gesture at without ever actually showing. So let's show it.
What a Hash Function Actually Does to Data
A hash function takes an input of any size and produces a fixed-length output: in SHA-256's case, 256 bits, written as a 64-character hexadecimal string. Three properties matter here.
First: determinism. The same input always produces the same output, without exception.
Second: avalanche effect. Flip a single bit anywhere in the input and roughly half the output bits change. Not one bit. Half. This is not an approximation; it is a design goal the function is mathematically constructed to achieve.
Third: pre-image resistance. Given an output hash, there is no known method faster than brute-force guessing to find an input that produces it. With a 256-bit output space, brute force is not feasible on any hardware that exists or is plausibly buildable.
Those three properties together are what make malleability computationally absurd rather than merely difficult.
The Chain Is in the Header, Not Just the Name
Every Bitcoin block has a header. That header contains, among other fields, the hash of the previous block's header. This is the cryptographic spine of the chain.
When a miner assembles a new block, they collect pending transactions, build a Merkle tree from those transactions (a hash tree where every transaction hash feeds upward into a single 32-byte Merkle root), and stuff that root into the header alongside the previous block hash, a timestamp, a difficulty target, and a nonce. They then hash the entire header repeatedly, incrementing the nonce, until they find an output below the current difficulty target. That output is the block's proof of work, and it becomes the "previous block hash" field in the next block's header.
Here's what that means in practice. Suppose someone wants to alter a transaction in block 700,000, changing the destination address on a payment.
Altering any byte in that block's transaction data changes the Merkle root, because the Merkle tree hashes propagate upward. A changed Merkle root changes the block header. A changed block header produces a completely different hash output, thanks to the avalanche effect. That new hash no longer satisfies the proof-of-work requirement the network accepted when the block was originally mined. So the attacker must redo the proof of work for block 700,000.
But block 700,001's header contains the original hash of block 700,000. Now that hash is wrong. So block 700,001 must be recomputed too. And 700,002. And every block after it, all the way to the current tip of the chain.
It is, in structure, exactly like a filing cabinet where the combination to each drawer's lock is printed on the outside of the drawer below it. Change drawer five and you've broken every lock beneath it. That's not an analogy stretched to fit Bitcoin. That is the design.
The Arithmetic That Makes This Prohibitive
This is where the math becomes the argument.
At the time a block is mined, the network's aggregate hash rate is performing some enormous number of SHA-256d computations per second, collectively, to find a valid block roughly every ten minutes. Difficulty adjusts every 2,016 blocks to keep that ten-minute average stable. The computation required to produce one valid block is, by definition, whatever the entire honest network produces in ten minutes.
An attacker rewriting block 700,000 doesn't get to start there and catch up leisurely. Every ten minutes, the honest chain adds another block. The attacker must not only redo the work for 700,000 and every subsequent block, but do it faster than the honest network keeps extending the chain. This is the 51% attack threshold: to reliably outpace the honest chain, an attacker needs to control more than half the network's total hash rate.
Consider what that means for an older block. Say a transaction was confirmed 144 blocks ago, roughly one day of blocks. An attacker wanting to rewrite that transaction needs to redo 144 blocks of proof of work, then outrace the honest chain going forward. The cost is not merely relative. It is absolute, and it scales with network size, and it grows with every additional confirmation.
This is why the practical rule of thumb for high-value transactions is six confirmations minimum, and why exchanges receiving large sums sometimes wait for dozens. The hash function doesn't make rewriting impossible in some abstract sense. It makes it progressively more expensive with every block that passes, in direct proportion to the total energy the honest network has expended since your transaction was included.
What People Get Wrong About "Immutability"
The word immutable gets thrown at Bitcoin constantly, and it's doing too much work. The blockchain is not immutable the way a mathematical proof is immutable. It's immutable the way a reputation is: technically revisable, but only at a cost that exceeds the benefit in all realistic scenarios.
The hash function doesn't create a physical barrier. It creates an economic one. Retroactive tampering requires redoing proof of work for every subsequent block, and that work represents real electricity and real hardware time. For a chain with years of accumulated blocks and a large honest mining network, the energy required to rewrite even a moderately old block would exceed the value of almost any transaction it might contain.
Still, there's a subtler point most guides skip entirely: the hash function's role is to make the cost of tampering proportional to the age of the data. A transaction from five years ago isn't protected by a stronger hash. It's protected by the accumulated proof of work of five years' worth of blocks stacked on top of it. The hash function is the mechanism that forces those blocks to be redone. The economics of mining is what makes redoing them infeasible.
The distinction matters more than people admit. If SHA-256 were ever broken in a way that allowed pre-image construction, the economic argument collapses entirely. The security of the entire chain-linking structure rests on the computational hardness assumptions underlying the hash function. That's not a flaw unique to Bitcoin; it's a dependency shared by essentially all of modern cryptographic infrastructure. Worth knowing.
Check Your Own Intuition Here
If you've followed the mechanism, you can now answer a question most people can't: why does it matter that Bitcoin uses a chained hash structure rather than simply signing each block individually with a digital signature?
A signature proves authorship. A chained hash proves history. It proves that a specific sequence of data existed in a specific order, and that altering any piece of it requires redoing computable work for everything that follows. Those are different guarantees, and only one of them prevents block malleability at scale.
So ask yourself this: what other system do you use every day where the cost of lying about the past increases automatically, with no administrator required, the older the lie would need to be?
Every block's identity is partly constituted by everything that came before it. That's not a feature bolted onto Bitcoin. It's the load-bearing wall.