<p>Let me add a few more details on how an unconfirmed transaction is relayed on the network and then you can answer your own question. Let's say there are three nodes. Alice, Bob, and Carol. Alice has Tx1 and just received Tx2, Bob has Tx1, Carol has neither. Both Bob and Carol are peer nodes to Alice.</p>
<p>When Alice learns about the new transaction Tx2, she announces Tx2 to Bob and Carol via the txid. Bob and Carol both don't have a transaction with the txid of Tx2 yet, so they request Tx2 from Alice.</p>
<p>Bob receives Tx2 and checks whether it would be valid to include in a block. As the node sees the input spending an output of Tx1, it finds Tx1 in its mempool. The input is unconfirmed but also part of a valid transaction, so Tx2 could be included in a block, as long as Tx1 is included in the block before it. Bob adds Tx2 to his mempool and announces Tx2 to his peers.</p>
<p>Carol receives Tx2 and checks whether the transaction would be valid to include in a block. As the node sees the input spending an output of Tx1, it realizes that it does not know about Tx1, e.g. because Carol was not online when Tx1 was originally broadcast to the network. Since Carol cannot confirm that Tx2 is ready for inclusion in a block until all inputs are known, Carol puts Tx2 in its &quot;orphan transaction&quot; list. As nodes only forward transactions they consider valid, the node that forwarded Tx2 to Carol should know all the inputs for Tx2. Hence, Carol follows up by requesting Tx1 from Alice. Alice serves Tx1 to Carol. Carol validates Tx1, adds it to her mempool. Now that the inputs are known, she determines Tx2 also to be valid and adds that to the mempool as well. Carol then announces both Tx1 and Tx2 to her peers.</p>
<p>Also, a note on terminology: we consider a transaction <em>confirmed</em> when it is included in a block. However, we consider an transaction <em>valid</em> if it could be included in a block. There can be multiple conflicting (spending the same inputs) valid transactions, but only one of them can be confirmed in the best chain. A node will only hold one out of a conflicting set of transactions in their mempool at a time. Usually that's the first they saw, unless a later transaction fulfills the requirements to replace its predecessor.<br />
<em>Accepting a zero-conf transaction</em>, refers to the practice of a receiver deciding to rely on a (valid) transaction before it is confirmed. Since transactions can be replaced before they're confirmed (and in some circumstances even after they are confirmed), this practice is not recommended. There are however some businesses that have the necessary telemetry and risk mitigation in place to make it work for them.</p>

CC BY-SA 4.0
2022-08-08T13:58:36.463Z
2022-08-08T14:48:53.583Z
2022-08-08T14:48:53.583Z
Murch
<p>Blocks can contain two interdependent transactions (one transaction spending an output created by another transaction in the same block).</p>
<p>Bitcoin Core will accept to its mempool transactions which spend outputs created by other transactions that are in the mempool already. These transactions may or may not be mined into the same block then.</p>

CC BY-SA 4.0
2022-08-07T12:53:35.087Z
Thanks!
If Tx1 has low/standard fee and Tx2 has very high fee, will the miners prioritize Tx1 also bexause of the high fee of Tx2?
michaell_co
CC BY-SA 4.0
2022-08-07T14:16:53.307Z
@michaell_co They will, in fact. Bitcoin Core supports a mechanism called Child-Pays-For-Parent (CPFP), by doing ancestor aware prioritization in the block construction code.
Pieter Wuille
CC BY-SA 4.0
2023-05-15T14:31:17.613Z
@PieterWuille Hey I'm wondering what happens when taken to the extreme. I noticed that BTC Block times are sometimes over 1 hour. Let's say I do 20 txs in that hour before the Block is mined, where every next tx is based on the former. I would have a chain of 20 txs where only the first tx uses a confirmed UTXO. Does this have negative consequences? Might the miners reject it or something?
CoderApprentice
CC BY-SA 4.0
2023-05-15T14:32:55.190Z
@CoderApprentice Bitcoin Core by default has a limit where transactions can have at most 24 ancestors and at most 24 descendants concurrently in its mempool.
Pieter Wuille
CC BY-SA 4.0
2023-05-16T07:42:50.113Z
@PieterWuille I see, that's great and more than enough :) Do you happen to know if the BTC node's policy to decide up until which tx in the chain of concurrent descendants is included in a Block, is based on a greedy algorithm? Like maybe txs 1-15 would give most profit so it would leave out txs 16-20. Or must it always look at the total average and include the entire chain? (aka maybe I should put the highest fees on my last tx in the chain)
CoderApprentice
CC BY-SA 4.0
2023-05-16T10:44:19.467Z
@CoderApprentice The currently used mining algorithm in Bitcoin Core is the ancestor feerate based one. Roughly, for every transaction the average feerate of the tx together with all unconfirmed ancestors is computed. The one with the highest such average feerate is included. Then the process repeats with remaining transactions. This covers "child pays for parent" use cases, but not "children pay for parent", as only one child at a time is considered.
Pieter Wuille
CC BY-SA 4.0
2023-05-16T11:46:45.200Z
@PieterWuille I see that's really helpful to know, many thanks for this knowledge.
CoderApprentice
CC BY-SA 4.0
2022-08-07T12:34:08.123Z
2022-08-07T12:34:08.123Z
Pieter Wuille
<p>Consider two transactions - Tx1, Tx2. Tx1 is an input of Tx2.</p>
<p>Say Tx1 did not get to any block yet. Can Tx2 get into the mempool of:</p>
<ol>
<li>a node that holds Tx1 in its mempool</li>
<li>a node that does not hold Tx1 in its mempool. If so, will it ask for Tx1 from its neighbors?</li>
</ol>
<p>I read some article which says Tx2 is a valid Tx and will get confirmed as a 0-conf Tx in some cases. I understand it might be different with different nodes (they can tweak the implementation) so I ask only for the bitcoin standard source code behavior.</p>

<unconfirmed-transactions><mempool><relay>
Using an unmined Tx as a UTXO
michaell_co
# Using an unmined Tx as a UTXO

(Asked by: username_0 on 2022-08-07)

Consider two transactions - Tx1, Tx2. Tx1 is an input of Tx2.

Say Tx1 did not get to any block yet. Can Tx2 get into the mempool of:

1. a node that holds Tx1 in its mempool
2. a node that does not hold Tx1 in its mempool. If so, will it ask for Tx1 from its neighbors?

I read some article which says Tx2 is a valid Tx and will get confirmed as a 0-conf Tx in some cases. I understand it might be different with different nodes (they can tweak the implementation) so I ask only for the bitcoin standard source code behavior.

**Tags:** unconfirmed-transactions, mempool, relay


---

## 2 answers

### Answer by username_2 on 2022-08-07. Score: 4 | Accepted answer

Blocks can contain two interdependent transactions (one transaction spending an output created by another transaction in the same block).

Bitcoin Core will accept to its mempool transactions which spend outputs created by other transactions that are in the mempool already. These transactions may or may not be mined into the same block then.

> **Comments:**
> **username_0**: Thanks! If Tx1 has low/standard fee and Tx2 has very high fee, will the miners prioritize Tx1 also bexause of the high fee of Tx2?  
> **username_2**: @username_0 They will, in fact. Bitcoin Core supports a mechanism called Child-Pays-For-Parent (CPFP), by doing ancestor aware prioritization in the block construction code.  
> **username_3**: @username_2 Hey I'm wondering what happens when taken to the extreme. I noticed that BTC Block times are sometimes over 1 hour. Let's say I do 20 txs in that hour before the Block is mined, where every next tx is based on the former. I would have a chain of 20 txs where only the first tx uses a confirmed UTXO. Does this have negative consequences? Might the miners reject it or something?  
> **username_2**: @username_3 Bitcoin Core by default has a limit where transactions can have at most 24 ancestors and at most 24 descendants concurrently in its mempool.  
> **username_3**: @username_2 I see, that's great and more than enough :) Do you happen to know if the BTC node's policy to decide up until which tx in the chain of concurrent descendants is included in a Block, is based on a greedy algorithm? Like maybe txs 1-15 would give most profit so it would leave out txs 16-20. Or must it always look at the total average and include the entire chain? (aka maybe I should put the highest fees on my last tx in the chain)  
> **username_2**: @username_3 The currently used mining algorithm in Bitcoin Core is the ancestor feerate based one. Roughly, for every transaction the average feerate of the tx together with all unconfirmed ancestors is computed. The one with the highest such average feerate is included. Then the process repeats with remaining transactions. This covers "child pays for parent" use cases, but not "children pay for parent", as only one child at a time is considered.  
> **username_3**: @username_2 I see that's really helpful to know, many thanks for this knowledge.  

---

### Answer by username_1 on 2022-08-08. Score: 3

Let me add a few more details on how an unconfirmed transaction is relayed on the network and then you can answer your own question. Let's say there are three nodes. Alice, Bob, and Carol. Alice has Tx1 and just received Tx2, Bob has Tx1, Carol has neither. Both Bob and Carol are peer nodes to Alice.

When Alice learns about the new transaction Tx2, she announces Tx2 to Bob and Carol via the txid. Bob and Carol both don't have a transaction with the txid of Tx2 yet, so they request Tx2 from Alice.

Bob receives Tx2 and checks whether it would be valid to include in a block. As the node sees the input spending an output of Tx1, it finds Tx1 in its mempool. The input is unconfirmed but also part of a valid transaction, so Tx2 could be included in a block, as long as Tx1 is included in the block before it. Bob adds Tx2 to his mempool and announces Tx2 to his peers.

Carol receives Tx2 and checks whether the transaction would be valid to include in a block. As the node sees the input spending an output of Tx1, it realizes that it does not know about Tx1, e.g. because Carol was not online when Tx1 was originally broadcast to the network. Since Carol cannot confirm that Tx2 is ready for inclusion in a block until all inputs are known, Carol puts Tx2 in its "orphan transaction" list. As nodes only forward transactions they consider valid, the node that forwarded Tx2 to Carol should know all the inputs for Tx2. Hence, Carol follows up by requesting Tx1 from Alice. Alice serves Tx1 to Carol. Carol validates Tx1, adds it to her mempool. Now that the inputs are known, she determines Tx2 also to be valid and adds that to the mempool as well. Carol then announces both Tx1 and Tx2 to her peers.

Also, a note on terminology: we consider a transaction *confirmed* when it is included in a block. However, we consider an transaction *valid* if it could be included in a block. There can be multiple conflicting (spending the same inputs) valid transactions, but only one of them can be confirmed in the best chain. A node will only hold one out of a conflicting set of transactions in their mempool at a time. Usually that's the first they saw, unless a later transaction fulfills the requirements to replace its predecessor.  
*Accepting a zero-conf transaction*, refers to the practice of a receiver deciding to rely on a (valid) transaction before it is confirmed. Since transactions can be replaced before they're confirmed (and in some circumstances even after they are confirmed), this practice is not recommended. There are however some businesses that have the necessary telemetry and risk mitigation in place to make it work for them.


---

