<p>Yes, it is possible to create transactions that spend unconfirmed outputs, but transactions can only be validly included in blocks if they spend existing coins. Therefore, a child transaction can only ever appear after all of its parent transactions in the blockchain. This leads to a transaction reprioritization technique referred to as <em>Child pays for Parent</em>: it is possible to attach a high fee to a descendant transaction in order to make it more attractive to confirm its ancestors.</p>
<p>There are some mempool policy limits that restrict how much data will be accepted by Bitcoin Core nodes running the default policy, but they are fairly generous: Bitcoin Core will not accept more than 25 descendant transactions to any one transaction (including the transaction itself here and in following), and will not accept a transaction that has more than 25 unconfirmed ancestors. Further, transactions will not be accepted when they would cause the sum of descendants to surpass 101 kvB in total weight or if a new transaction would have unconfirmed ancestry of more than 101 kvB.</p>

CC BY-SA 4.0
2024-07-29T14:57:52.213Z
Thanks a lot, didn't expect such a quick answer!
Maxgmer
CC BY-SA 4.0
2024-07-29T14:50:13.730Z
2024-07-29T15:17:40.560Z
2024-07-29T15:17:40.560Z
Murch
<blockquote>
<p>Is it possible to create transaction with input being an unconfirmed UTXO?</p>
</blockquote>
<p>The consensus rules permit a transaction that spends an output created within the same block. That isn't spending an unconfirmed UTXO, but if two unconfirmed transactions exist with one chaining off the other, then they can be mined simultaneously.</p>
<p>The P2P protocol rules also permit propagation of unconfirmed transactions which spend unconfirmed outputs, so such chains do actually get relayed across the network, and make it to miners.</p>
<blockquote>
<p>If yes, what happens, if such a transaction has a higher fee than the fee of the transaction, that created the unconfirmed UTXO? Will this transaction fail, because it was included into the block ahead of the UTXO transaction? Or will it be delayed, until the UTXO transaction is confirmed?</p>
</blockquote>
<p>The block building and relay code in Bitcoin Core does take the fees of such chains into account even using a principle known as child-pays-for-parent (CPFP). If a descendant transaction pays a higher feerate than its parent, the two may get treated as a group, where the total fee is spread over the total size, virtually bumping the feerate of the parent.</p>
<blockquote>
<p>And how much of this &quot;chaining&quot; can you do? (use unconfirmed UTXO from a tx, which uses unconfirmed UTXO etc etc.) Is there a limit?</p>
</blockquote>
<p>The currently-implemented default policy rules in Bitcoin Core permit a transaction to have up to 25 unconfirmed descendants in the mempool (including itself), and up to 25 unconfirmed ancestors (including itself). In addition, there are limits on the total size (in vbytes) of these combined ancestor and descendant sets.</p>
<p>Note that all of this is likely to change with <a href="https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393" rel="nofollow noreferrer">cluster mempool</a>.</p>

CC BY-SA 4.0
2024-07-29T14:57:40.013Z
Such a detailed answer, thank you!
Maxgmer
CC BY-SA 4.0
2024-07-29T14:47:12.730Z
2024-07-29T14:47:12.730Z
Pieter Wuille
<p>Is it possible to create transaction with input being an unconfirmed UTXO?</p>
<p>If yes, what happens, if such a transaction has a higher fee than the fee of the transaction, that created the unconfirmed UTXO? Will this transaction fail, because it was included into the block ahead of the UTXO transaction? Or will it be delayed, until the UTXO transaction is confirmed?</p>
<p>And how much of this &quot;chaining&quot; can you do? (use unconfirmed UTXO from a tx, which uses unconfirmed UTXO etc etc.) Is there a limit?</p>
<p>Thanks in advance!</p>

<client><utxo><mempool><child-pays-for-parent><utxo-management>
Is it possible to spend unconfirmed UTXO?
Maxgmer
# Is it possible to spend unconfirmed UTXO?

(Asked by: username_0 on 2024-07-29)

Is it possible to create transaction with input being an unconfirmed UTXO?

If yes, what happens, if such a transaction has a higher fee than the fee of the transaction, that created the unconfirmed UTXO? Will this transaction fail, because it was included into the block ahead of the UTXO transaction? Or will it be delayed, until the UTXO transaction is confirmed?

And how much of this "chaining" can you do? (use unconfirmed UTXO from a tx, which uses unconfirmed UTXO etc etc.) Is there a limit?

Thanks in advance!

**Tags:** client, utxo, mempool, child-pays-for-parent, utxo-management


---

## 2 answers

### Answer by username_2 on 2024-07-29. Score: 4 | Accepted answer

> Is it possible to create transaction with input being an unconfirmed UTXO?

The consensus rules permit a transaction that spends an output created within the same block. That isn't spending an unconfirmed UTXO, but if two unconfirmed transactions exist with one chaining off the other, then they can be mined simultaneously.

The P2P protocol rules also permit propagation of unconfirmed transactions which spend unconfirmed outputs, so such chains do actually get relayed across the network, and make it to miners.

> If yes, what happens, if such a transaction has a higher fee than the fee of the transaction, that created the unconfirmed UTXO? Will this transaction fail, because it was included into the block ahead of the UTXO transaction? Or will it be delayed, until the UTXO transaction is confirmed?

The block building and relay code in Bitcoin Core does take the fees of such chains into account even using a principle known as child-pays-for-parent (CPFP). If a descendant transaction pays a higher feerate than its parent, the two may get treated as a group, where the total fee is spread over the total size, virtually bumping the feerate of the parent.

> And how much of this "chaining" can you do? (use unconfirmed UTXO from a tx, which uses unconfirmed UTXO etc etc.) Is there a limit?

The currently-implemented default policy rules in Bitcoin Core permit a transaction to have up to 25 unconfirmed descendants in the mempool (including itself), and up to 25 unconfirmed ancestors (including itself). In addition, there are limits on the total size (in vbytes) of these combined ancestor and descendant sets.

Note that all of this is likely to change with [cluster mempool](https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393).

> **Comments:**
> **username_0**: Such a detailed answer, thank you!  

---

### Answer by username_1 on 2024-07-29. Score: 4

Yes, it is possible to create transactions that spend unconfirmed outputs, but transactions can only be validly included in blocks if they spend existing coins. Therefore, a child transaction can only ever appear after all of its parent transactions in the blockchain. This leads to a transaction reprioritization technique referred to as *Child pays for Parent*: it is possible to attach a high fee to a descendant transaction in order to make it more attractive to confirm its ancestors.

There are some mempool policy limits that restrict how much data will be accepted by Bitcoin Core nodes running the default policy, but they are fairly generous: Bitcoin Core will not accept more than 25 descendant transactions to any one transaction (including the transaction itself here and in following), and will not accept a transaction that has more than 25 unconfirmed ancestors. Further, transactions will not be accepted when they would cause the sum of descendants to surpass 101 kvB in total weight or if a new transaction would have unconfirmed ancestry of more than 101 kvB.

> **Comments:**
> **username_0**: Thanks a lot, didn't expect such a quick answer!  

---

