4

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?

2 Answers 2

3

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 @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).

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. This feature isn't available yet (as of October 2023).

3
  • "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
    Oct 19 at 9:28
  • If you want you can re-broadcast the parent at the same feerate and create a higher fee-paying child. This is called CPFP. Oct 19 at 9:50
  • "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
    Oct 19 at 10:09
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 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.

3
  • 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) Oct 19 at 11:59
  • 2
    @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. mempool.space runs with a much bigger memory limit, but they show their memory use here: i.imgur.com/qj30FXI.png (it’s over the limit right now). On JoHoe’s you’d want to look at the “Default Mempol” rather than the standard view which also has a higher limit.
    – Murch
    Oct 19 at 12:39
  • Oh, right! I was comparing vMB to MB. Oct 19 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.