What is the block maturation time?

Question

I was reading the wiki article about the blockchain and I didn't understand the part in bold:

When a block becomes an orphan block, all of its valid transactions are re-added to the pool of queued transactions and will be included in another block. The 50 BTC reward for the orphan block will be lost, which is why a network-enforced 100-block maturation time for generations exists.

I don't know the details behind block creation and acceptance, so how does the block maturation time work? Is the block only accepted after a while?

Answer 1

Generated coins can't be spent until the generation transaction has 101 confirmations. Transactions that try to spend generated coins before this will be rejected.

The reason for this is that sometimes the block chain forks, blocks that were valid become invalid, and the mining reward in those blocks is lost. That's just an unavoidable part of how Bitcoin works, and it can sometimes happen even when there is no one attacking the network. If there was no maturation time, then whenever a fork happened, everyone who received coins that were generated on an unlucky fork (possibly through many intermediaries) would have their coins disappear, even without any sort of double-spend or other attack. On long forks, thousands of people could find coins disappearing from their wallets, even though there is no one actually attacking them and they had no reason to be suspicious of the money they were receiving. For example, without a maturation time, a miner might deposit 25 BTC into an EWallet, and if I withdraw money from a completely unrelated account on the same EWallet, my withdrawn money might just disappear if there is a fork and I'm unlucky enough to withdraw coins that have been "tainted" by the miner's now-invalid coins. Due to the way this sort of taint tends to "infect" transactions, far more than 25 BTC per block would be affected. Each invalidated block could cause transactions collectively worth hundreds of bitcoins to be reversed. The maturation time makes it impossible for anyone to lose coins by accident like this as long as a fork doesn't last longer than 100 blocks. If a fork does last longer than 100 blocks, then the damage caused by invalidated transactions would likely be a huge disaster. (However, something else would have to be seriously wrong with Bitcoin or the Internet for a fork to last this long.)

Answer 2

A block is accepted immediately (assuming it is valid) the maturation time applies to the coinbase reward to the miner found in the block (bock subsidy + tx fees).

The purpose is to prevent a form of transaction reversal (most commonly associated with "double spends") if the block is orphaned. If a block is orphaned the coinbase reward "ceases to exist". The coins are produced from the block and when a block is orphaned it is the replacement blocks version of the coinbase tx which is considered valid by the network.

Transactions which use non-coinbase coins as an input are not affected. If a block is orphaned then any tx which was confirmed in the orphaned block and not confirmed in the block which replaced it will return to the memory pool and be included in a future block.

Generated coins however cease to exist when the block is orphaned. If the network allowed miners to spend them immediately it would be the recipient of the coins not the miner who would suffer a loss from the miner's block being orpahned.

So to avoid that undesirable situation the network requires coinbase tx (rewards to miners) to "mature" or wait 100 confirmations (the client makes this 120 confirmations but only 100 is required by the protocol). If a block is orphaned before it gets 100 blocks deep into the chain, then only the miner is affected.

Answer 3

We require a maturation period for coinbase outputs, because any two blocks at the same height will condemn at least one coinbase transaction to never exist in the best chain. If users were able to immediately spend coinbase outputs, perhaps even in the same block, even short reorgs could invalidate entire trees of transactions descending from the coinbase outputs of an extinct chaintip. This would create a big attack surface for scams, and incentives for reorg attacks.

While a reorg might return some non-coinbase transactions to the mempool, in organic chainforks block content would largely overlap anyway, and any transactions not included in either tip, would simply still be in the mempools of nodes following that chaintip. For the most part, a reorging miner would only be able to delay confirmation, but not permanently invalidate any transactions created by third parties. Transactions would only get invalidated in the case that a sender is actively creating conflicting transactions to doublespend while there are competing chaintips. In contrast, coinbase transactions could be written out of existence by a third party, rather than the original transaction creator.

Generated coins can't be spent until the generation transaction has 101 confirmations.

I find the quoted phrase from the accepted answer confusing, especially because it is easy to get lost in a meandering philosophical debate about when exactly a UTXO is spendable, when an output is spent, and at what point the confirmation count increases.

A transaction that spends an output of the coinbase transaction at height h, is eligible to be included in block h+100 or higher. Transactions that are eligible to be included in the next block will be accepted in the mempool, used to build block templates, and relayed on the network. This means that miners may include such a transaction in their block template when their chaintip has a height of h+99.