Coinbase maturity

Mining rewards are not spendable money the moment a block is found. Bitcoin Core sets COINBASE_MATURITY to 100 in its consensus header, so the wait is 100 blocks, about 16 hours and 40 minutes at the ten minute block target. Coins you buy on an exchange are never caught by the rule, because anything that reached you has already been spent at least once.

How it works

Coinbase maturity is enforced by every full node as a network rule, which means no setting, no wallet and no pool can relax it.

The check itself is one subtraction. Validating a transaction, a node inspects each input, and where the coin came from a coinbase transaction it subtracts that coin's block height from the height the spend would land at. If the difference is under 100, Bitcoin Core rejects the transaction with the code bad-txns-premature-spend-of-coinbase and a message reporting the depth it was tried at. A reward paid out in block 900,000 is first spendable in block 900,100, the lowest height at which that subtraction reaches 100.

The delay exists because a coinbase output is the one kind of coin that can stop existing. Ordinary coins survive a chain reorganization: the transactions holding them return to the mempool and are mined again. A block's reward exists only because that block is in the chain, so if a competing branch wins, the reward is gone and so is anything descended from it. Spends built on a reward that later evaporated would take down every wallet that had touched it.

Bitcoin Core guards the gap between blocks too. Each mempool entry is tagged with whether it spends a coinbase, and the comment in the source says why: those entries get re-scanned during reorganizations to check the 100 block rule is still met. Anything that has become immature again is dropped rather than mined.

One property of the rule catches people out. The wait is counted in blocks, not hours, so a slow difficulty epoch stretches it and a fast one shortens it. Bitcoin aims at one block every 600 seconds, which is where both 16 hours and 40 minutes and the familiar 144 blocks a day come from, and an eleven minute average stretches the same 100 blocks to 18 hours and 20 minutes.

Where you see it

The most common sighting of coinbase maturity is a wallet reporting two balances instead of one.

Bitcoin Core's getbalances returns an immature field, documented in the source as the balance from immature coinbase outputs, and getreceivedbyaddress and listunspent both take an include_immature_coinbase flag that defaults to false. Core's wallet is a block stricter than consensus, holding a reward immature until the block that paid it is 101 deep, so a solo miner sees the balance unlock one block later than the network rule alone requires.

Pool dashboards use their own vocabulary, usually a pending or immature column beside a confirmed one. A pool paying a fixed amount per share credits its miners long before the coins mature, so it is advancing money against a reward it cannot yet move, and the pool rather than the miner is exposed if that block is replaced.

The rule also sets the floor on how fast mined coins reach a market. A miner who wants to sell waits out the 100 blocks, sends to an exchange, then waits out its deposit policy, normally a handful of confirmations rather than a hundred.

Coinbase maturity vs confirmation

Coinbase maturity is one fixed depth written into consensus, while a confirmation count is a running total that anybody can pick a threshold from.

An exchange asking for six confirmations before crediting a deposit chose that number itself and can change it tomorrow. The 100 block rule is not a choice. It covers only coins created by a block, it applies identically on every node that validates, and a transaction breaking it is not slow but invalid: no miner can include it, because the block carrying it would be rejected too.