The Problem With Trying to Erase a Bitcoin Transaction

Six blocks have settled on top of a payment you want gone. You have the hashrate, the motive, and the political cover. You open your mining dashboard, look at the numbers, and realize, slowly, that you are not about to erase history. You are about to buy a war you cannot win on a timeline that keeps getting worse.

Here's what that actually costs.

Most explainers say Bitcoin is "censorship-resistant" and move on, as if the label does the explaining. It doesn't. The resistance isn't philosophical; it's thermodynamic. It comes from the way Bitcoin chains blocks together using proof-of-work, and once you see the mechanism clearly, you understand why retroactive censorship isn't just difficult. It's a war of attrition that the attacker is almost structurally guaranteed to lose.

How Blocks Lock Each Other In Place

Every Bitcoin block contains, in its header, the hash of the block before it. A hash is a fixed-length fingerprint: change a single byte of the input data and the output fingerprint changes completely and unpredictably. This is the chain in blockchain, and it matters enormously for what follows.

When a miner produces a valid block, they've done real computational work: they've found a number (the nonce) that, combined with the block's contents, produces a hash below a specific target value. At typical network difficulty, this requires on the order of quintillions of attempts. That work is baked into the block's hash. And that hash is baked into the next block's header.

So when block 800,000 references block 799,999's hash, and block 800,001 references block 800,000's hash, you have a physical dependency chain. You cannot alter block 799,999 without changing its hash. If its hash changes, block 800,000's header is now invalid. It references a hash that no longer exists. Which means block 800,000 must be remined. Which invalidates block 800,001. And so on.

Attacking one old block means redoing every block built on top of it. The timechain doesn't just record history; it makes history progressively harder to rewrite with every passing block.

The Arithmetic of a Rewrite Attack

Let's make this concrete.

Imagine a transaction confirmed in block 799,990. By the time an attacker decides to act, the honest network has already added 10 more blocks on top. The attacker needs to: remine block 799,990 with the offending transaction removed; remine blocks 799,991 through 800,000, all 10 of them, because each one's header now references the wrong predecessor hash; and then outpace the honest network, which is simultaneously continuing to build new blocks at the tip.

Say the honest network controls 90% of total hashrate and the attacker controls 10%. For every block the attacker produces, the honest chain adds nine. The attacker starts 10 blocks behind and falls further behind with every second. Catching up is mathematically equivalent to a gambler with a losing edge trying to make back their losses before going bust — the probability of success drops exponentially with each additional block of depth.

The actual formula comes from Satoshi Nakamoto's original 2008 paper, modeled as a Gambler's Ruin problem. With an attacker holding 10% of hashrate trying to overcome a 10-block lead, the probability of success is vanishingly small, well under 0.1%. With a 30-block lead, it's effectively zero for any attacker below 50% hashrate.

And this assumes the attacker can even acquire 10% of global hashrate quietly, which is its own logistical and financial problem.

What a Majority Attack Actually Buys (And What It Doesn't)

The one scenario worth taking seriously is a 51% attack: an entity controlling more than half the network's total hashrate. With majority hashrate, an attacker can rewrite recent history, in principle. Not hypothetical. It has happened to smaller proof-of-work chains. Ethereum Classic suffered several reorganizations of thousands of blocks in a span of roughly two years, and those attacks were methodical and profitable precisely because the chain was small enough to make them cheap.

Bitcoin is not small. Still, even a majority attack here has hard limits that people consistently underestimate.

First, the cost scales with depth. Remining 6 blocks is expensive. Remining 100 blocks is roughly 17 times more expensive, and requires sustaining majority hashrate for the entire duration while the honest chain keeps racing forward. Second, full nodes reject the attack if it violates consensus rules. A rewritten chain that double-spends a transaction or breaks any protocol rule will be refused by every validating node, regardless of how much hashrate backs it. The attacker can produce a longer chain; they cannot force nodes to accept an invalid one.

Third, and this is the point most people miss: the attack is visible. A chain reorganization of any significant depth is immediately detectable by every node on the network. Exchanges pause. The attacker's window for actually using the rewritten history, say to double-spend to an exchange, is narrow and shrinking as the industry builds better monitoring tooling.

The economic incentive runs backwards, too. An entity with 51% of Bitcoin's hashrate has invested billions in hardware and electricity. Using that hashrate to attack the chain is like a landlord burning down their own apartment building for insurance money, except the payout never comes and everyone watched you strike the match.

What People Get Wrong About "Immutability"

Honest caveat, worth sitting with: Bitcoin's timechain doesn't provide absolute immutability. It provides economic immutability, which is a different and more precise claim. Anyone flattening that distinction is either selling something or hasn't thought it through.

A transaction confirmed one block ago is far less secure than one confirmed 144 blocks ago, roughly one day's worth. Most serious exchanges and payment processors apply confirmation thresholds precisely because of this gradient. Six confirmations became a rough industry standard for moderate-value transfers; large OTC desks sometimes wait for dozens more.

The folk wisdom that "one confirmation is enough" needs to die for anything above trivial amounts. The security is real, but it's probabilistic and it accumulates over time, compounding against any would-be attacker the longer they wait.

Think of it like sediment layers in rock. The top layer is still soft and movable. Go down a meter and you're chipping at compressed stone. Go down ten meters and you'd need industrial equipment for days. Bitcoin's block depth works the same way, and the rock hardens at the rate of roughly one block every ten minutes, permanently.

The Deeper Point About Incentive Design

Bitcoin's censorship-resistance isn't a feature bolted on after the fact. It's a consequence of aligning financial incentives with honest behavior at the protocol level. Miners earn block rewards and transaction fees for extending the honest chain. Attacking the chain costs them those same rewards, plus the capital outlay for the attack itself, plus the reputational and market-price damage to an asset they hold.

So here's the question worth asking: if you had billions sunk into mining equipment, would you torch the value of the asset those machines exist to produce?

Found a transaction six confirmations deep and want it gone? You're not fighting code. You're fighting the arithmetic of compound disadvantage, the financial self-interest of every honest miner on the network, and thousands of full nodes that will simply refuse your rewritten history the moment it breaks a rule.

The censorship isn't impossible in some absolute cosmic sense. The catch: the attacker has to spend more than the thing they're erasing is worth, in full view of everyone, with a shrinking window to collect. That's not a guarantee. It's better. It's a structure where rational actors will almost never try, and irrational ones will hemorrhage capital proving the point.