<p>Since transactions bidding 1 ṩ/vB were dropped from almost all mempools in the past few months, most nodes would no longer know about the transaction that created the UTXO you are trying to spend (the “parent” transaction). If you still have a copy of the parent transaction, you could use the <a href="https://bitcoincore.org/en/doc/25.0.0/rpc/rawtransactions/sendrawtransaction/" rel="nofollow noreferrer"><code>sendrawtransaction</code></a> rpc to resubmit the parent to your own and other nodes’ mempools. Then, a transaction spending the output of the parent should propagate fine, as long as the parent transaction’s feerate is not under most nodes’ dynamic minimum feerate.</p>

CC BY-SA 4.0
2023-10-19T11:59:18.447Z
Were they? I couldn't find any historical data that the backlog went over 300MB in the past 3 months? (See the links in my answer)
Antoine Poinsot
CC BY-SA 4.0
2023-10-19T12:39:45.563Z
@AntoinePoinsot: Yeah, it’s been above the limit almost the entire last six months. The mempool limit is not 300 MvB of transaction weight, but [300 MB of memory for the mempool data structure](https://bitcoin.stackexchange.com/a/96070/5406). mempool.space runs with a much bigger memory limit, but they show their memory use here: https://i.imgur.com/qj30FXI.png (it’s over the limit right now). On JoHoe’s you’d want to look at the [“Default Mempol”](https://bitcoinqueue.com/#BTC%20(default%20mempool),6m,weight) rather than the standard view which also has a higher limit.
Murch
CC BY-SA 4.0
2023-10-19T12:44:43.340Z
Oh, right! I was comparing vMB to MB.
Antoine Poinsot
CC BY-SA 4.0
2023-10-19T11:40:35.973Z
2023-10-19T12:41:49.240Z
2023-10-19T12:41:49.240Z
Murch
<p>The mempool of a node is limited in size (300MB by default). Once it's filled and the node keeps receiving transactions it will start evicting some transactions. The transactions less attractive to miners are (supposed to be) evicted to let room for higher-fee-paying transactions.</p>
<p>As pointed by @Murch in his own answer, there has been more than 300MB of backlog across the network at many points in the past 3 months. Most of it paying more than 1sat/vb. Your transaction must have been evicted from your node's mempool (and most likely from the mempool of its peers as well).</p>
<p>Therefore a <code>sendrawtransaction</code> of a child (a transaction spending some of its outputs) will fail, since the inputs of the child would appear to be inexistent to the node. You should first rebroadcast the parent (the initial transaction), and then the child, for it to succeed.</p>
<p>Note you're only able to do this because your mempool isn't actively purging transactions at 1sat/vb at the moment. Otherwise you would have to submit both your transactions as a single <a href="https://bitcoinops.org/en/topics/package-relay/" rel="nofollow noreferrer">package</a>. This feature isn't available yet (as of October 2023).</p>

CC BY-SA 4.0
2023-10-19T09:28:33.677Z
"You should first rebroadcast the parent (the initial transaction) and then the child for it to succeed."  i should be able to rebroadcast the parent's inputs and new outputs at higher feerate ?
Jack Zhu
CC BY-SA 4.0
2023-10-19T09:50:16.973Z
If you want you can re-broadcast the parent at the same feerate and create a higher fee-paying child. This is called CPFP.
Antoine Poinsot
CC BY-SA 4.0
2023-10-19T10:09:49.730Z
"You should first rebroadcast the parent (the initial transaction) and then the child for it to succeed."
i think this should work for me, i could get the parent's rawtransaction from a blockbook with larger mempoolsize
Jack Zhu
CC BY-SA 4.0
2023-10-19T07:43:11.313Z
2023-10-19T12:49:02.147Z
2023-10-19T12:49:02.147Z
Antoine Poinsot
<p>I have some unconfirmed utxos with: <code>sat_per_vbyte=1</code>, which probably exist in the tail of the mempool queue, e.g. 22300/22385. They are being kept in: &quot;unconfirmed&quot; since 3 months ago. And <code>getrawtransaction txid</code> returns: 'No such mempool or blockchain transaction' for these utxos in my bitcoind node, the mempoolsize=300MB.</p>
<p>Now if I create a new transaction spending these utxos with much higher <code>sat_per_vbyte</code> in <code>cpfp</code> style, will <code>sendrawtransaction</code> successfully broadcast the transaction or end in error?</p>

<bitcoin-core><unconfirmed-transactions><mempool><transaction-propagation><child-pays-for-parent>
spending unconfirmed utxos which exist in the tail of mempool queue
Jack Zhu
# spending unconfirmed utxos which exist in the tail of mempool queue

(Asked by: username_0 on 2023-10-19)

I have some unconfirmed utxos with: `sat_per_vbyte=1`, which probably exist in the tail of the mempool queue, e.g. 22300/22385. They are being kept in: "unconfirmed" since 3 months ago. And `getrawtransaction txid` returns: 'No such mempool or blockchain transaction' for these utxos in my bitcoind node, the mempoolsize=300MB.

Now if I create a new transaction spending these utxos with much higher `sat_per_vbyte` in `cpfp` style, will `sendrawtransaction` successfully broadcast the transaction or end in error?

**Tags:** bitcoin-core, unconfirmed-transactions, mempool, transaction-propagation, child-pays-for-parent


---

## 2 answers

### Answer by username_2 on 2023-10-19. Score: 3 | Accepted answer

The mempool of a node is limited in size (300MB by default). Once it's filled and the node keeps receiving transactions it will start evicting some transactions. The transactions less attractive to miners are (supposed to be) evicted to let room for higher-fee-paying transactions.

As pointed by @username_1 in his own answer, there has been more than 300MB of backlog across the network at many points in the past 3 months. Most of it paying more than 1sat/vb. Your transaction must have been evicted from your node's mempool (and most likely from the mempool of its peers as well).

Therefore a `sendrawtransaction` of a child (a transaction spending some of its outputs) will fail, since the inputs of the child would appear to be inexistent to the node. You should first rebroadcast the parent (the initial transaction), and then the child, for it to succeed.

Note you're only able to do this because your mempool isn't actively purging transactions at 1sat/vb at the moment. Otherwise you would have to submit both your transactions as a single [package](https://bitcoinops.org/en/topics/package-relay/). This feature isn't available yet (as of October 2023).

> **Comments:**
> **username_0**: "You should first rebroadcast the parent (the initial transaction) and then the child for it to succeed."  i should be able to rebroadcast the parent's inputs and new outputs at higher feerate ?  
> **username_2**: If you want you can re-broadcast the parent at the same feerate and create a higher fee-paying child. This is called CPFP.  
> **username_0**: "You should first rebroadcast the parent (the initial transaction) and then the child for it to succeed." i think this should work for me, i could get the parent's rawtransaction from a blockbook with larger mempoolsize  

---

### Answer by username_1 on 2023-10-19. Score: 3

Since transactions bidding 1 ṩ/vB were dropped from almost all mempools in the past few months, most nodes would no longer know about the transaction that created the UTXO you are trying to spend (the “parent” transaction). If you still have a copy of the parent transaction, you could use the [`sendrawtransaction`](https://bitcoincore.org/en/doc/25.0.0/rpc/rawtransactions/sendrawtransaction/) rpc to resubmit the parent to your own and other nodes’ mempools. Then, a transaction spending the output of the parent should propagate fine, as long as the parent transaction’s feerate is not under most nodes’ dynamic minimum feerate.

> **Comments:**
> **username_2**: Were they? I couldn't find any historical data that the backlog went over 300MB in the past 3 months? (See the links in my answer)  
> **username_1**: @username_2: Yeah, it’s been above the limit almost the entire last six months. The mempool limit is not 300 MvB of transaction weight, but [300 MB of memory for the mempool data structure](https://bitcoin.stackexchange.com/a/96070/5406). mempool.space runs with a much bigger memory limit, but they show their memory use here: https://i.imgur.com/qj30FXI.png (it’s over the limit right now). On JoHoe’s you’d want to look at the [“Default Mempol”](https://bitcoinqueue.com/#BTC%20(default%20mempool),6m,weight) rather than the standard view which also has a higher limit.  
> **username_2**: Oh, right! I was comparing vMB to MB.  

---

