The Problem That Existed Before the Rule Did
You find a valid block. Height 840,000. The 3.125 BTC subsidy lands in your wallet alongside the transaction fees, and for a moment you feel like moving it immediately to an exchange. Why wait? The math checked out. The network accepted it.
Twenty minutes later, a longer competing chain overtakes the network. Your block is orphaned. The reward never existed on the canonical chain. The exchange received coins that are now, technically, dust.
Not hypothetical. That is the exact failure mode Bitcoin's coinbase maturity rule was built to prevent.
What the Rule Actually Says
The coinbase maturity rule is a consensus rule baked into Bitcoin Core: a coinbase transaction output cannot be spent until it has 100 confirmations. Not 6, not 12. One hundred.
Any transaction attempting to spend a coinbase output before those 100 blocks are stacked on top of it gets rejected as invalid by every honest node on the network. It is not a fee policy, not a wallet preference, not a miner courtesy. Hard rule. Protocol level. Non-negotiable.
At roughly ten minutes per block, 100 confirmations works out to about sixteen to seventeen hours of calendar time. During that window, the coinbase output sits frozen. The miner can watch it, count the confirmations, but cannot move a single satoshi.
Why Reorganizations Are the Whole Point
Bitcoin reorganizations happen. They are not exotic disasters; they are a normal feature of a distributed system where two miners occasionally find valid blocks at nearly the same time. The network resolves the tie by following the chain with the most accumulated proof-of-work, and the losing block gets orphaned.
Shallow reorgs of one or two blocks happen a handful of times per year under normal conditions. Deep reorgs, the kind requiring an attacker to control a large fraction of total hash rate, are rare and expensive. The maturity rule does not care which kind it is. It defends against both, indifferently.
Here's the wrinkle. The coinbase transaction is structurally unlike every other transaction in a block. Its input references no prior output. It mints new coins from nothing, citing only the block itself as its source. If that block disappears from the canonical chain, the coinbase output has no valid history to fall back on. Spending it before the chain has firmly settled is, in a very literal sense, spending something that might not exist.
The 100-block buffer is the network saying: wait until the probabilistic certainty of your block's permanence is so high that treating the reward as real money is reasonable.
The Math Behind the Margin of Safety
Why 100 blocks specifically? Satoshi Nakamoto set this number in the original Bitcoin implementation. The reasoning is about the depth required to make a reorg economically catastrophic for any attacker.
The whitepaper's analysis shows that an attacker controlling 30% of total hash rate has roughly a 17.7% chance of catching up from one block behind, about a 3% chance from two blocks behind, and the probability collapses toward zero as the gap widens. At 100 blocks deep, the energy cost of rewriting the chain would, under any realistic hash-rate assumption, vastly exceed the value of every coinbase output in those blocks combined.
There is also a secondary, quieter rationale. In Bitcoin's early days, when hash rate was low and single-machine miners were competitive, short reorgs happened more frequently. A 100-block window gave the network time to reach stable consensus even on a slow, patchy internet. The number was generous by design.
The catch: 100 was set once and has never been changed by consensus. It applies equally to a 6.25 BTC block reward era and a 3.125 BTC one, to a network with ten nodes and one with fifty thousand. It is blunt, which is also what makes it reliable. I think that bluntness is a feature, not an oversight. A rule with carve-outs is a rule with attack surfaces.
A Concrete Scenario: Two Miners, One Reorg
Consider two miners, call them Priya and Kwame, who both run small operations and find blocks on the same afternoon. Priya's block lands at height 900,100. Kwame finds a competing block at the same height two seconds later. For a few minutes, the network is split: some nodes have seen Priya's block first, others Kwame's.
The next block is found by a large pool that built on Priya's chain. Kwame's block is orphaned. His coinbase output, 3.125 BTC plus fees, simply ceases to exist on the canonical chain.
Now run the same scenario but imagine both miners had been allowed to spend their coinbase outputs immediately. Kwame's payment to his electricity provider, made thirty seconds after his block was found, is now a double-spend on the losing chain. The recipient's node accepted a transaction the winning chain never knew about. This is not a hypothetical edge case. It is a clean description of why the rule exists.
Priya, meanwhile, waits her 100 blocks, counts confirmation 100 arriving about sixteen hours later, and only then moves her reward. Her transaction references a real, deeply buried output. Nobody disputes it.
What People Get Wrong About This Rule
The most common misconception: people treat coinbase maturity as a protection for the recipient of miner payments. It is not, primarily. It protects the network from a category of invalid transaction that would otherwise be structurally undetectable without replaying the entire chain history.
The second misconception is that it slows miners down in some punishing way. It does not. Mining is a continuous operation. By the time a miner's block at height N has matured, they've typically found or contributed to dozens of subsequent blocks. The frozen reward is one pebble in a moving stream, barely noticed against the current.
The third misconception, which frankly needs to die: some newer users assume that 6 confirmations, the informal standard for large transfers, applies here too. It does not. Coinbase outputs are categorically different. Six confirmations is a risk-management heuristic. One hundred confirmations for coinbase outputs is a consensus rule. Violating it gets your transaction rejected outright, not flagged. Not delayed. Rejected.
Found your miner dashboard showing a balance you can't spend yet? If the counter reads above 90, you're almost there. If it reads 12, settle in.
The coinbase maturity rule is one of those places where Bitcoin's design reveals what it actually values: the integrity of the ledger over the convenience of any individual participant. Miners are the ones who secure the network, and the rule still applies to them without exception. That's not punitive. That's the whole architecture. Any system that makes exceptions for the people running it is a system waiting to be gamed, and Bitcoin, to its considerable credit, doesn't make that mistake here.