How Does Blockchain Ensure Immutability?

Blockchains do not make records impossible to change. They make changing them so expensive, so visible and so easy to reject that the network refuses the edit. Hash links expose tampering, consensus rules decide which history counts, and economic cost keeps attackers from rewriting it. Where one of those layers is thin, history has been rewritten.

A blockchain is often described as a ledger that cannot be altered. That description is close enough for a product page and wrong enough to cause losses. The accurate version is narrower: once a transaction is buried under enough later blocks, rewriting it costs more than almost anyone can pay, and any attempt is visible to every node watching. How much “enough” is depends on the chain.

The question matters now because the edge cases are in the news. Polygon has a proposal on the table to move about 70.49 million POL out of five blocked addresses at a fixed block, as crypto.news reported on November 6. In April, Litecoin rewound about 32 minutes of its own history. Neither event breaks the idea of immutability. Both show where its limits sit.

What does a hash link actually protect?

A hash function turns any input into a fixed-length fingerprint. Change one character of the input and the fingerprint changes completely. Two real SHA-256 outputs show the effect:

The inputs differ by one digit. The outputs share nothing recognisable. That property is what lets a network detect an edit without comparing every byte of history.

A blockchain applies it in sequence. Each block header contains the hash of the previous block header, so the blocks form a chain of references. The academic literature calls the reference a hash pointer, because it both identifies the earlier block and verifies it. If someone alters a transaction in block 100, block 100’s hash changes. Block 101 still points to the old hash, so the link breaks. Repairing it means recomputing block 101, which changes its hash, which breaks block 102, and so on up to the tip.

Transactions inside a block are summarised through a Merkle tree. Pairs of transaction hashes are combined and hashed again until one value remains, the Merkle root, which goes into the header. The structure lets a light client prove that a transaction is included using only a short chain of hashes instead of the whole block. It also means a single altered transaction changes the root and therefore the block’s hash.

The distinction that matters is between detection and prevention. Hash links make tampering detectable. They do not make it hard to carry out. An attacker with a copy of the chain can recompute every hash from the edited block onward in seconds, because hashing is cheap. Anyone who claims the hash chain alone is the security model is describing a tamper-evident log, not a blockchain.

Why recomputing the hashes is not enough

The missing ingredient is a rule that makes producing a valid block expensive. In proof-of-work, a block counts only if its hash falls below a network-set target, which miners find by repeated guessing. Rewriting block 100 therefore means redoing the work for block 100 and for every block after it, while the honest network keeps adding new ones at the same time. A Spark glossary entry makes the same point: chaining hashes does not provide immutability on its own, and proof-of-work is what makes recalculation infeasible.

Satoshi Nakamoto’s whitepaper models this as a race. An attacker who controls a fraction of the network’s hash power must catch up from behind. The odds of catching up fall exponentially with each block the honest chain adds. In the paper’s table, an attacker with 10% of hash power has roughly a 0.02% chance of overtaking a transaction buried six blocks deep. An attacker with 30% needs about ten blocks of depth to push the odds down to roughly 4%.

That is where the six-confirmation convention comes from. It is not a protocol rule. It is a risk threshold that exchanges and merchants adopted, and it is tied to Bitcoin’s 10-minute block target, which puts six blocks at about an hour. A merchant selling a coffee can accept zero or one confirmation. An exchange crediting a seven-figure deposit should want more.

How does Ethereum’s proof-of-stake version differ?

Ethereum replaced hash power with stake. Validators attest to checkpoints, and a block becomes finalised after two epochs, which takes about 12.8 minutes under normal conditions. The Ethereum consensus specification book describes the guarantee as economic: if two conflicting checkpoints were both finalised, evidence would exist that at least one-third of validators acted maliciously, and their deposits would be destroyed.

The cost of reversal is therefore a share of staked ETH rather than a rented hash rate. Spark’s comparison of finality models puts the figure at more than 11 million ETH for a finalised block, based on over 34 million ETH staked. At early November’s price of roughly $2,230 per ETH, that is in the region of $25 billion in destroyed stake. Treat the dollar figure as a rough illustration, because both the staked total and the price move daily.

The two models answer the same question differently.

Ethereum’s version has a useful property. A failed attack costs the attacker its stake. A failed Bitcoin attack costs the attacker electricity and hardware time but destroys no capital. Whether that makes proof-of-stake more or less secure in practice is still debated, and nothing here settles it.

What does it cost to attack Bitcoin, and what about everyone else?

Immutability scales with the money defending the chain. Bitcoin’s hash rate has hovered around 1 zettahash per second. Trackers reported readings between roughly 950 and 1,070 EH/s in early November, according to Hashrate Index and Pickaxe. Foundry USA alone accounts for about 26% to 28% of that, according to Pickaxe’s estimate.

A BloFin Academy snapshot using Crypto51 data from mid-May put the one-hour rental-equivalent cost of attacking each chain as follows:

The data shows why “the blockchain is immutable” is a statement about a particular chain. A sustained attack on Bitcoin has to compete for hundreds of exahashes, and the hardware is not available to rent at that scale. The same operation on a small proof-of-work chain can cost less than a lunch.

History has already run the experiment. Ethereum Classic suffered three separate 51% attacks in August 2020, with reorganisations reaching thousands of blocks deep, and Bitcoin Gold lost an estimated $18 million to double-spends in May 2018, according to the same source. In each case the protocol worked as designed. The attacker simply controlled most of the work.

A reorganisation is also not proof of an attack. In March 2026 the Bitcoin chain saw a two-block reorg involving competing blocks at around height 941,880. BloFin’s write-up describes a seven-block run by Foundry in late March as within the expected range for a pool near 31% of hash power, with nodes accepting the result and no double-spend. Short reorgs are a normal feature of how proof-of-work resolves competing blocks. The question is depth.

When the code itself rewrites history

The Litecoin incident on April 25 is a useful case because it was not a classic 51% attack. According to CoinDesk’s reporting, attackers exploited a vulnerability in Litecoin’s MimbleWimble Extension Block layer that had been patched but not fully deployed, triggering a 13-block reorganisation that rewound about 32 minutes of activity. Cointelegraph reported that the Litecoin team described it as a zero-day, while other developers questioned that label because of the public commit history.

The mechanism is the point. Outdated mining nodes accepted invalid transactions, and the network then reorganised to remove them. Coverage compiled by VPN Central says NEAR Intents had initially flagged about $600,000 in exposure, and that the reorg may have reduced the final settled impact. Some commentary at the time called the event a coordinated 51% attack, but the project’s own account and the CoinDesk and Cointelegraph reports describe a software flaw and denial-of-service disruption instead. Readers should treat the 51% framing as unconfirmed.

Two lessons follow. First, consensus rules are enforced by software, so a bug can change what “valid” means. Second, the network corrected itself by rewriting recent history. That is the system doing its job, and it also demonstrates that recent history is not fixed. As one exchange analysis noted, confirmation policies that were adequate before a 13-block reorg may not be conservative enough afterwards.

The social layer: forks and freezes

The strongest version of immutability applies to the data structure. It does not apply to the people who run the software. If enough node operators agree to run new rules, the chain they follow can differ from the old one.

Ethereum did this in 2016. After the DAO exploit, the community adopted a hard fork that moved the stolen funds, and the minority that rejected the change continued as Ethereum Classic. That split is the oldest example of the principle, and it is the reason “code is law” has always carried an asterisk.

Polygon’s proposal follows the same logic at a smaller scale. According to crypto.news, block producers first restricted transfers from the addresses after two October thefts, but the filter was a temporary software measure that each producer reads at startup. The proposed fork would zero the five listed balances at a fixed block and credit designated recovery addresses. The proposal separates native POL from USDT, because Tether froze its own stablecoin through its contract, which is a different control.

The case shows three tiers of intervention, each with a different cost to the idea of immutability:

• Asset-level freezes by an issuer, such as Tether’s action on USDT, affect one token and leave the chain untouched.
• Producer-level filters stop transactions from being included but leave balances in place, and they depend on operators staying coordinated.
• State-changing forks alter balances directly and require node operators to adopt new software.

Each tier relies on someone’s discretion, which is why the third tier draws the most scrutiny over precedent.

Why private and permissioned chains are different

Public chains get their immutability from distributed cost. A private chain run by a consortium does not have that. The authors of a survey on blockchain mutability argue that in public blockchains the deep history is immutable because of the extreme cost of redoing the work, while private chains face a harder problem because a small set of administrators can collude to rewrite blocks. The same paper notes that some researchers dispute that any blockchain has perfect immutability, since under certain conditions it can be changed.

For a company evaluating blockchain for audit trails, the practical question is who controls the validators. If the answer is the company itself, the log is tamper-evident only to outsiders who hold copies of the hashes.

What to watch

• Polygon’s fork proposal: whether it is approved, which activation block is chosen, and whether operators adopt the release.
• Litecoin’s patch rollout: how many nodes and pools run the fixed software, and whether exchanges lengthen their confirmation requirements.
• Small-chain hash rates: any proof-of-work network where rented hash power approaches the size of the legitimate miners.
• Bitcoin’s pool concentration: Foundry’s share and any migration after Binance Pool’s planned November 10 closure.
• Finality delays on Ethereum: the gap between the latest and finalised block, which widens when finality stalls.

FAQ

Is blockchain data truly impossible to change?

No. It is tamper-evident and extremely costly to rewrite on large networks. Small chains, buggy software and coordinated forks have all produced changes to recorded history.

What happens if someone edits an old block?

The block’s hash changes, which breaks the reference in the next block. Nodes reject the altered chain unless it also carries more accumulated work than the honest one, which is what makes the edit expensive.

How many confirmations are enough?

It depends on the value at risk and the chain. Six confirmations on Bitcoin is a convention, not a rule. Ethereum offers a defined finalised status after about 13 minutes. Smaller chains may warrant far more.

Can a 51% attacker steal anyone’s coins?

Not directly. A majority attacker can reverse recent transactions and censor new ones, which enables double-spends. They cannot forge signatures or spend coins from wallets whose keys they do not hold.

Did Litecoin’s 13-block reorg mean the chain was hacked?

The Litecoin team described a vulnerability in its MWEB layer that let outdated nodes accept invalid transactions, and the network reorganised to remove them. Some commentators called it a 51% attack. Sources reviewed here do not confirm that.

Why did Ethereum fork after the DAO attack?

A large majority of the community chose to reverse the theft by changing the chain’s rules. The minority that kept the original history continued as Ethereum Classic.

Does proof-of-stake make reversal impossible?

No. It makes reversal of a finalised block cost at least one-third of staked ETH, which is a very large penalty but not an absolute barrier.

This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect sources available as of November 6, 2026 and change frequently. Attack-cost estimates are theoretical rental calculations, not forecasts. Always do your own research.