51% Attack Economics: Why Bitcoin's Security Budget Matters

A determined attacker with a billion dollars in ASICs, a private power plant, and a grudge walks into Bitcoin. They leave with nothing — or rather, they leave having spent more on electricity than they could possibly steal, having burned block rewards they would otherwise have earned honestly, and having torched the value of the very coins they hoped to double-spend. That is not a moral argument. It is the economic argument, and it is the reason Bitcoin has never suffered a successful 51% attack despite being the single largest bounty in computing history.

This is Part 5 of our Bitcoin Deep Dive. We have walked through the halving and supply schedule, the UTXO model, and how fees and blockspace tie miner incentives to user demand. Now we look at the adversary — what a majority-hashrate attacker can and cannot do, what it would cost, and what smaller proof-of-work chains have already shown us when the security budget collapses.

What a 51% attack actually is

A 51% attack — more accurately a majority-hashrate attack — is when a single miner or coordinated pool controls more than half of the network's hashing power for long enough to build a private chain that outpaces the public one. Because Bitcoin nodes follow the chain with the most accumulated proof-of-work, the attacker's longer chain, once revealed, reorganises the public ledger. Any transactions that existed only on the old tip are erased.

The canonical use of this power is the double-spend. An attacker deposits coins at an exchange on the public chain, withdraws a different asset once the deposit confirms, and then publishes their private chain in which the original deposit never happened. The exchange is left with a hole; the attacker walks away with whatever they withdrew.

What a 51% attacker cannot do is, frankly, most of the interesting things people assume they can:

• They cannot steal coins from addresses they do not control. Transactions still require valid signatures. A majority of hashrate does not grant a majority of private keys.
• They cannot inflate the supply. The 21 million cap and the block subsidy schedule are consensus rules enforced by every full node. A block that prints extra coins is rejected regardless of the work behind it.
• They cannot change old, deeply buried transactions. Rewriting history requires redoing the work for every block since the target — and doing it faster than the honest network is producing new blocks.
• They cannot force users to accept invalid blocks. Running your own node is the ultimate backstop: nodes validate consensus rules independently and will reject malformed blocks no matter how much hashrate backs them.

What they can do is censor transactions by refusing to include them, reorganise recent blocks, and double-spend their own coins. Everything else is off the menu.

Satoshi's probability table, revisited

Section 11 of the Bitcoin whitepaper contains a small gem of applied probability: a calculation of the chance that an attacker with fraction q of total hashrate catches up from z blocks behind. The model treats block discovery as a Poisson process and the race between chains as a gambler's ruin problem.

A few anchor values from that table are worth internalising:

• q = 10%, z = 6: probability of successful catch-up ≈ 0.024%. This is roughly where exchanges settled on "six confirmations" as a default — it assumes a non-trivial but realistic adversary and makes the odds of a reversal roughly one in four thousand.
• q = 30%, z = 24: probability < 0.1%. Even a very well-resourced attacker controlling nearly a third of hashrate would need to get extraordinarily lucky to reverse a day's worth of blocks.
• q ≥ 50%: the probability converges to 1 given unbounded time. With a true majority, catch-up is eventually certain — depth only buys you time, not safety.

The lesson is that confirmation depth is a sliding scale against a probabilistic adversary, and it loses all meaning once the attacker crosses the 50% line. Below that line, every extra confirmation multiplies the cost of a reversal attempt exponentially.

The security budget, in math

Miner revenue per block is simple arithmetic:

security budget per block = block subsidy + sum of [transaction fees](/academy/how-to/sending-crypto-fees-speed)

As of 2026, the subsidy is 3.125 BTC per block after the 2024 halving. Fees vary wildly with demand but are a small fraction of the subsidy in normal conditions and spike far higher during congested periods. Over the course of a day — 144 blocks — the network pays out on the order of 450–500 BTC to miners. That sum is the honest opportunity cost an attacker forgoes every single day they spend attacking instead of mining.

The subsidy halves every 210,000 blocks, and by the 2030s it will be a small share of miner income relative to fees — if the fee market develops. This is the transition we covered in the fees and blockspace piece: the long-term security model depends on a healthy fee market paying miners to protect the chain once issuance has faded. A thin fee market in 2040 is a much bigger threat to Bitcoin than any attacker in 2026.

Bitcoin in 2026: roughly $1.7M per hour to attack, if you could rent it

Bitcoin's network hashrate sits in the 900–990 EH/s range in 2026. Services like crypto51.app publish a running estimate of the theoretical cost to rent 51% of a given chain's hashrate for one hour. For Bitcoin that number is roughly $1.69 million per hour — and critically, the "NiceHash-able" fraction is listed at 0%.

That zero is the entire story. There is no rental market remotely deep enough to supply half of Bitcoin's hashrate. An attacker cannot swipe a credit card. They would have to:

1. Physically acquire on the order of 500 EH/s of modern ASICs — years of global production from a handful of manufacturers.
2. Secure gigawatts of power and the sites to host it.
3. Keep it all operational long enough to build a private chain deeper than whatever confirmation depth they are trying to reverse.
4. Do all of this without tipping off the market, which would price in the threat and crash the value of any BTC they planned to double-spend.

The capex alone runs into billions. The opex is the forgone honest mining revenue — hundreds of millions of dollars per month at current prices. And the exit liquidity for any stolen funds is constrained by exchange withdrawal limits and the reputational blast radius of a confirmed Bitcoin reorg.

What smaller chains have already taught us

The economics above assume Bitcoin-scale hashrate. On smaller proof-of-work chains, the numbers invert catastrophically.

Bitcoin Gold, January 2020. BTG suffered two deep reorgs (14 and 15 blocks) during which attackers double-spent approximately 6,500 BTG (~$70,000). Post-mortem analyses put the rental cost of the hashrate at approximately $1,200 per attack — a roughly 60× return on a few hours of NiceHash spend. Binance raised its BTG withdrawal requirement to 20 blocks after the incident.

Ethereum Classic, August 2020. Over three separate incidents in a single month, attackers reorganised thousands of ETC blocks and double-spent coins worth an estimated ~$9M in total — including a 4,236-block reorg with a $1.68M double-spend and a 7,000-plus-block reorg later in the month. Exchanges responded by pushing confirmation requirements to several thousand blocks — an operational nightmare that effectively neutered ETC as a settlement asset for months.

Bitcoin SV, August 2021. BSV saw a 100-block reorganisation that wiped out roughly 570,000 transactions. Coinbase halted BSV trading in response, and the incident became a case study in how quickly a thin-hashrate chain can be destabilised.

The common thread is that all three chains shared a hashing algorithm with a much larger network. BTG's Equihash was rentable; ETC shared Ethash with then-Ethereum; BSV shared SHA-256 with Bitcoin but represented a tiny fraction of total SHA-256 capacity. When your security depends on hashrate that can be trivially borrowed from a bigger sibling, you are not secure.

Bitcoin has the inverse property: it is the big sibling. Nothing else on SHA-256 comes close, and the ASICs that mine it are purpose-built and supply-constrained.

Choosing a confirmation depth

Given all of the above, how many confirmations should you actually wait for?

• Everyday spends under a few hundred dollars: 1 confirmation is typically fine. The attacker cost to reverse a single Bitcoin block vastly exceeds any realistic personal transaction.
• Larger personal transfers, merchant settlement: 3 confirmations is a reasonable default. Satoshi's table puts even a 10% attacker at roughly a 1.3% chance of catching up from 3 behind — and 10% of Bitcoin hashrate is already a heroic assumption.
• Exchange deposits, large OTC trades: 6 confirmations remains the industry default and corresponds to the 0.024% figure at q = 10%.
• Institutional settlement, very large transfers: 10 to 100 confirmations is not unusual, and the marginal wait cost is trivial against the marginal security gain.
• After a suspected reorg event on any chain: double your usual depth until you have independent confirmation the network is stable.

For other chains — especially smaller proof-of-work assets — anchor your depth to the crypto51 cost column, not to Bitcoin habits.

How to hold it in Zelcore

Zelcore is a non-custodial multi-asset wallet. When you hold BTC in Zelcore, your private keys live on your device, derived from your seed phrase — the chain's security model applies to your coins directly, without an exchange acting as an intermediary that a double-spend attacker could target. For UTXOs you care about, let deposits settle to the confirmation depth that matches the value at stake before treating them as spendable. Pair Zelcore's mobile or desktop client with the same threat-modelling posture you would apply to any long-term holding: back up your seed offline, verify receiving addresses on-device, and keep your OS and wallet software current.

Key takeaways

• A 51% attack lets an attacker double-spend their own coins and censor transactions; it cannot steal from others, mint new supply, or rewrite deeply buried history.
• Satoshi's Section 11 table quantifies the probabilistic safety of confirmation depth: ~0.024% reversal risk at q = 10% / z = 6, dropping below 0.1% for z = 24 even at q = 30%.
• Bitcoin's security budget is block subsidy plus fees, paid every ten minutes — miners have a multi-billion-dollar annual incentive to stay honest.
• At ~900–990 EH/s and roughly $1.69M per hour theoretical attack cost with 0% rentable, Bitcoin is structurally unattackable by rental; the capex to build an attacker from scratch dwarfs any plausible payoff.
• Smaller chains — BTG 2020 (~$1,200 for $70k), ETC August 2020 ($9M total double-spends), BSV August 2021 (100-block reorg) — prove what happens when the security budget is too thin or hashrate is rentable.
• Match your confirmation depth to the value at stake, and never trust a rented-hashrate chain at the same depth you trust Bitcoin.
• Next in this series: Part 6 — Holding Bitcoin in Zelcore — the capstone that translates every mechanism in this arc into concrete self-custody actions.