<p>(updated based on Pieter's comments below)</p>

<p>There are (essentially) two sets of UTXOs at play. One is constructed from the blockchain itself, by reading the blocks on disk and updating with any new blocks that are broadcasted. This set is saved to disk, and can be reconstructed from the blockchain data if erased.</p>

<p>Another UTXO set is the mempool itself. Each output in the mempool is considered a valid UTXO, unless it is already spent by another mempool tx. Moreover, any outputs consumed by mempool transactions from confirmed transactions are considered spent in the other UTXO set. This mempool UTXO set is not saved to disk, and only exists when there are transactions in the mempool, while the node is running.</p>

<p>You can see existing CPFP transactions by calling <code>getrawmempool</code> with the <a href="http://chainquery.com/bitcoin-api/getrawmempool/true" rel="nofollow noreferrer">verbose option</a>. This produces a json array in which you can see if an unconfirmed tx depends on an existing unconfirmed tx:</p>

<pre><code>...
"fdb9bed320457e8ff606bdf1e4a6fa980bc65d9ad8525e75abba30af1363ef8e": {
    "size": 256,
    "fee": 0.00001923,
    "modifiedfee": 0.00001923,
    "time": 1527988568,
    "height": 525693,
    "descendantcount": 1,
    "descendantsize": 256,
    "descendantfees": 1923,
    "ancestorcount": 4,
    "ancestorsize": 964,
    "ancestorfees": 7212,
    "depends": [
      "4b2541774140a6afe58606f8a97cca9d1aef0dff5f769ee1dcdcb834b50aeb97"
    ]
},
...
</code></pre>

CC BY-SA 4.0
2018-06-03T17:07:23.540Z
Small clarification: saying "the UTXO" is confusing, as there are multiple explicit and implicit UTXO sets in Bitcoin Core. Unconfirmed transactions do not affect the on-disk or cached chainstate UTXO set, but there is a separate UTXO set implied by the blockchain+all mempool transactions (which is not even materialized; it is just implied by the mempool).
Pieter Wuille
CC BY-SA 4.0
2018-06-04T01:06:38.597Z
@PieterWuille I didn't know that, thanks for the insight. I've update the answer to hopefully better reflect what's going on
Raghav Sood
CC BY-SA 4.0
2018-06-04T01:09:53.697Z
(very much a nit) It's not "updated with any mempool transactions". It *is* the mempool. Every output of a mempool transaction that isn't spent by another mempool transaction is seen as an extra available UTXO for verifying incoming transaction. Every blockchain UTXO spent by a mempool transaction is seen as not available. There is no explicit data structure for this UTXO set; it's just defined conceptually by the mempool itself.
Pieter Wuille
CC BY-SA 4.0
2018-06-04T01:19:47.337Z
Made another edit, hopefully this one is better!
Raghav Sood
CC BY-SA 4.0
2018-06-03T01:18:28.627Z
2018-06-04T01:19:13.597Z
2018-06-04T01:19:13.597Z
Raghav Sood
<p>I am trying to understand how the relay mechanism works in bitcoin?</p>

<p>I understand how CPFP transaction works, but how those transactions get relayed to miner nodes in the first place? the reason is that some inputs of those transactions are not in UTXO. Should standard nodes discard it in the first place? </p>

<child-pays-for-parent>
Does bitcoin core node relay those child-pay-for-parent transactions?
devildeer
# Does bitcoin core node relay those child-pay-for-parent transactions?

(Asked by: username_0 on 2018-06-03)

I am trying to understand how the relay mechanism works in bitcoin?

I understand how CPFP transaction works, but how those transactions get relayed to miner nodes in the first place? the reason is that some inputs of those transactions are not in UTXO. Should standard nodes discard it in the first place?

**Tags:** child-pays-for-parent


---

## 1 answers

### Answer by username_1 on 2018-06-03. Score: 2 | Accepted answer

(updated based on username_2's comments below)

There are (essentially) two sets of UTXOs at play. One is constructed from the blockchain itself, by reading the blocks on disk and updating with any new blocks that are broadcasted. This set is saved to disk, and can be reconstructed from the blockchain data if erased.

Another UTXO set is the mempool itself. Each output in the mempool is considered a valid UTXO, unless it is already spent by another mempool tx. Moreover, any outputs consumed by mempool transactions from confirmed transactions are considered spent in the other UTXO set. This mempool UTXO set is not saved to disk, and only exists when there are transactions in the mempool, while the node is running.

You can see existing CPFP transactions by calling `getrawmempool` with the [verbose option](http://chainquery.com/bitcoin-api/getrawmempool/true). This produces a json array in which you can see if an unconfirmed tx depends on an existing unconfirmed tx:

```
...
"fdb9bed320457e8ff606bdf1e4a6fa980bc65d9ad8525e75abba30af1363ef8e": {
    "size": 256,
    "fee": 0.00001923,
    "modifiedfee": 0.00001923,
    "time": 1527988568,
    "height": 525693,
    "descendantcount": 1,
    "descendantsize": 256,
    "descendantfees": 1923,
    "ancestorcount": 4,
    "ancestorsize": 964,
    "ancestorfees": 7212,
    "depends": [
      "4b2541774140a6afe58606f8a97cca9d1aef0dff5f769ee1dcdcb834b50aeb97"
    ]
},
...

```

> **Comments:**
> **username_2**: Small clarification: saying "the UTXO" is confusing, as there are multiple explicit and implicit UTXO sets in Bitcoin Core. Unconfirmed transactions do not affect the on-disk or cached chainstate UTXO set, but there is a separate UTXO set implied by the blockchain+all mempool transactions (which is not even materialized; it is just implied by the mempool).  
> **username_1**: @username_2 I didn't know that, thanks for the insight. I've update the answer to hopefully better reflect what's going on  
> **username_2**: (very much a nit) It's not "updated with any mempool transactions". It *is* the mempool. Every output of a mempool transaction that isn't spent by another mempool transaction is seen as an extra available UTXO for verifying incoming transaction. Every blockchain UTXO spent by a mempool transaction is seen as not available. There is no explicit data structure for this UTXO set; it's just defined conceptually by the mempool itself.  
> **username_1**: Made another edit, hopefully this one is better!  

---

