<p>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).  </p>

<p>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.  </p>

<p>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. </p>

<p>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. </p>

<p>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.</p>

CC BY-SA 3.0
2011-11-14T17:44:58.310Z
2012-12-26T15:43:55.667Z
2012-12-26T15:43:55.667Z
DeathAndTaxes
<p>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.</p>
<p>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. <em>In contrast, coinbase transactions could be written out of existence by a third party, rather than the original transaction creator.</em></p>
<blockquote>
<p>Generated coins can't be spent until the generation transaction has
101 confirmations.</p>
</blockquote>
<p>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.</p>
<p>A transaction that spends an output of the coinbase transaction at height <em>h</em>, is eligible to be included in block <em>h+100</em> 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 <em>h+99</em>.</p>

CC BY-SA 4.0
2023-07-22T03:12:18.783Z
2023-07-22T04:19:04.480Z
2023-07-22T04:19:04.480Z
Murch
<p>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.</p>

<p>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.)</p>

CC BY-SA 3.0
2012-12-26T16:24:33.733Z
Actually, the network rules require a difference of 100 between the creating block and the spending block, which corresponds to 101 confirmations.
Pieter Wuille
CC BY-SA 3.0
2014-11-28T10:37:22.750Z
@theymos What is the exact purpose of this? Why is the usual 6 confirmations for a transaction not sufficient?
Jori
CC BY-SA 3.0
2014-11-28T13:43:45.653Z
@Jori I updated my answer with that info.
theymos
CC BY-SA 4.0
2022-09-14T21:28:37.423Z
It's unclear why this "disappearing coins" argument works. Temporary forks can also affect regular transactions that were made during a temporary fork. When the temporary fork is abandoned, these transactions are reversed, causing, again, "coins to disappear". Wallets (such as EWallet in your example) should wait for k-deep confirmation before showing coins as confirmed, whether these pertain to coinbase coins, or normally transferred coins. Even lacking a double spending attack, a temporary fork can cause coins to disappear in case the blocks in the canonical chain are full.
dionyziz
CC BY-SA 4.0
2023-07-21T22:34:38.040Z
@PieterWuille: If the consensus rules require a difference of 100 blocks between creating block and spending block wouldn’t that mean that the coinbase output has 100 confirmations when it’s spent? Otherwise, it would be able to be in the block that gives the 101st confirmation to the coinbase output.
Murch
CC BY-SA 4.0
2023-07-21T22:42:45.720Z
A coinbase UTXO created in block number *n* can be spent in a txin in block number *n+100*. The creating transaction, in block *n*, at the time it is included, has 1 confirmation. 100 blocks later, it has 101 confirmations.
Pieter Wuille
CC BY-SA 4.0
2023-07-22T01:54:17.667Z
@PieterWuille: I guess our crossed wires are about “when an output gets spent”: at the time that you create the spending transaction and it gets included in the block template, the coinbase output only has 100 confirmations. When the transaction that spends the coinbase output gets confirmed, the coinbase output gets its 101 confirmation.
Murch
CC BY-SA 4.0
2023-07-22T01:57:42.127Z
@Murchisonstrike Right, I was talking about consensus rules. They don't care about when you create a transaction or when it can get relayed.
Pieter Wuille
CC BY-SA 4.0
2023-07-22T15:15:45.517Z
FWIW, when I commented above, in 2012, non-final transactions (ones with a locktime far in the future, e.g.) were still relayable and accepted into the mempool of the reference client (changed in PR 2223, in Jan 2013). I'm not sure whether that was also the case for immature spends.
Pieter Wuille
CC BY-SA 3.0
2011-11-14T12:00:47.737Z
2014-11-29T01:35:35.673Z
2014-11-29T01:35:35.673Z
theymos
<p>I was reading the <a href="https://en.bitcoin.it/wiki/Block_chain">wiki article</a> about the blockchain and I didn't understand the part in bold:</p>

<blockquote>
  <p>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  <strong>network-enforced 100-block maturation time for
  generations exists.</strong></p>
</blockquote>

<p>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?</p>

<blockchain><protocol><coinbase-transaction><immature-coins>
What is the block maturation time?
nmat
# What is the block maturation time?

(Asked by: username_0 on 2011-11-14)

I was reading the [wiki article](https://en.bitcoin.it/wiki/Block_chain) 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?

**Tags:** blockchain, protocol, coinbase-transaction, immature-coins


---

## 3 answers

### Answer by username_3 on 2011-11-14. Score: 41 | Accepted answer

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.)

> **Comments:**
> **username_4**: Actually, the network rules require a difference of 100 between the creating block and the spending block, which corresponds to 101 confirmations.  
> **username_5**: @username_3 What is the exact purpose of this? Why is the usual 6 confirmations for a transaction not sufficient?  
> **username_3**: @username_5 I updated my answer with that info.  
> **username_6**: It's unclear why this "disappearing coins" argument works. Temporary forks can also affect regular transactions that were made during a temporary fork. When the temporary fork is abandoned, these transactions are reversed, causing, again, "coins to disappear". Wallets (such as EWallet in your example) should wait for k-deep confirmation before showing coins as confirmed, whether these pertain to coinbase coins, or normally transferred coins. Even lacking a double spending attack, a temporary fork can cause coins to disappear in case the blocks in the canonical chain are full.  
> **username_2**: @username_4: If the consensus rules require a difference of 100 blocks between creating block and spending block wouldn’t that mean that the coinbase output has 100 confirmations when it’s spent? Otherwise, it would be able to be in the block that gives the 101st confirmation to the coinbase output.  
> **username_4**: A coinbase UTXO created in block number *n* can be spent in a txin in block number *n+100*. The creating transaction, in block *n*, at the time it is included, has 1 confirmation. 100 blocks later, it has 101 confirmations.  
> **username_2**: @username_4: I guess our crossed wires are about “when an output gets spent”: at the time that you create the spending transaction and it gets included in the block template, the coinbase output only has 100 confirmations. When the transaction that spends the coinbase output gets confirmed, the coinbase output gets its 101 confirmation.  
> **username_4**: @Murchisonstrike Right, I was talking about consensus rules. They don't care about when you create a transaction or when it can get relayed.  
> **username_4**: FWIW, when I commented above, in 2012, non-final transactions (ones with a locktime far in the future, e.g.) were still relayable and accepted into the mempool of the reference client (changed in PR 2223, in Jan 2013). I'm not sure whether that was also the case for immature spends.  

---

### Answer by username_1 on 2011-11-14. Score: 12

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 by username_2 on 2023-07-22. Score: 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*.


---

