<blockquote>
  <p>how is the output of a coinbase transaction (plus block's transaction fees) different than the outputs of any other transaction?</p>
</blockquote>

<p>Because it's validity is tied to WHICH block it is included in. You can't take a coinbase transaction and include it as if it were a standard transaction in another block, because it creates more bitcoins than it spends, which is not allowed for normal bitcoin transactions.</p>

<p>This issue is called being reorg-safe (reorganization-safe). It is a general principal of the blockchain, and it means that if a fork happens and you have to undo the latest block or two to replace them with different blocks, that shouldn't change which transactions are valid. With normal transactions, it's pretty easy to just add them to block X instead of block Y when a fork happens. </p>

<p>But if you have transactions that depend on a recent coinbase transaction, then you can't take those transactions and put them in another block easily. So the 100 block rule is to keep the blockchain reorg-safe, so nothing bad happens in the case of a small fork.</p>

CC BY-SA 3.0
2015-09-24T18:11:00.863Z
A nice side effect is that it forces miners to have a slightly longer-term interest in Bitcoin. Although I guess 16.6 hours is not that much of a difference. Proposals have been made to make the delay much longer, like months (for example for half of the reward).
Jannes
CC BY-SA 3.0
2015-09-24T17:13:41.690Z
2015-09-25T14:13:38.027Z
2015-09-25T14:13:38.027Z
morsecoder
<p>From the <a href="https://bitcoin.org/en/developer-guide#transaction-data" rel="noreferrer">developer guide</a>:</p>

<blockquote>
  <p>The UTXO of a coinbase transaction has the special condition that it cannot be spent (used as an input) for at least 100 blocks. This temporarily prevents a miner from spending the transaction fees and block reward from a block that may later be determined to be stale (and therefore the coinbase transaction destroyed) after a block chain fork.</p>
</blockquote>

<p>Can someone please explain why this constraint is necessary? I mean, how is the output of a coinbase transaction (plus block's transaction fees) different than the outputs of any other transaction?</p>

<p>Or, put differently, if coinbase transactions require a 100-block cooldown period, all other transactions do too, no?</p>

CC BY-SA 3.0
2015-09-24T17:26:46.743Z
Possible duplicate of http://bitcoin.stackexchange.com/questions/1991/what-is-the-block-maturation-time
morsecoder
<transaction-fees><mining-reward><coinbase-transaction>
Coinbase transaction's 100-block cooldown period
shx2
# Coinbase transaction's 100-block cooldown period

(Asked by: username_0 on 2015-09-24)

From the [developer guide](https://bitcoin.org/en/developer-guide#transaction-data):

> The UTXO of a coinbase transaction has the special condition that it cannot be spent (used as an input) for at least 100 blocks. This temporarily prevents a miner from spending the transaction fees and block reward from a block that may later be determined to be stale (and therefore the coinbase transaction destroyed) after a block chain fork.

Can someone please explain why this constraint is necessary? I mean, how is the output of a coinbase transaction (plus block's transaction fees) different than the outputs of any other transaction?

Or, put differently, if coinbase transactions require a 100-block cooldown period, all other transactions do too, no?

**Tags:** transaction-fees, mining-reward, coinbase-transaction

> **Comments:**
> **username_1**: Possible duplicate of http://bitcoin.stackexchange.com/questions/1991/what-is-the-block-maturation-time  

---

## 1 answers

### Answer by username_1 on 2015-09-24. Score: 13 | Accepted answer

> how is the output of a coinbase transaction (plus block's transaction fees) different than the outputs of any other transaction?

Because it's validity is tied to WHICH block it is included in. You can't take a coinbase transaction and include it as if it were a standard transaction in another block, because it creates more bitcoins than it spends, which is not allowed for normal bitcoin transactions.

This issue is called being reorg-safe (reorganization-safe). It is a general principal of the blockchain, and it means that if a fork happens and you have to undo the latest block or two to replace them with different blocks, that shouldn't change which transactions are valid. With normal transactions, it's pretty easy to just add them to block X instead of block Y when a fork happens.

But if you have transactions that depend on a recent coinbase transaction, then you can't take those transactions and put them in another block easily. So the 100 block rule is to keep the blockchain reorg-safe, so nothing bad happens in the case of a small fork.

> **Comments:**
> **username_2**: A nice side effect is that it forces miners to have a slightly longer-term interest in Bitcoin. Although I guess 16.6 hours is not that much of a difference. Proposals have been made to make the delay much longer, like months (for example for half of the reward).  

---

