1

I'm encountering an issue with Bitcoind where I frequently get the error:

"Unconfirmed UTXOs are available, but spending them creates a chain of transactions that will be rejected by the mempool."

This problem seems to be exacerbated by the high volume of transactions generated by bitcoinfaucet.uo1.net, leading to long chains of unconfirmed transactions. What can I do to prevent this error and ensure my transactions are accepted by the mempool?

1

2 Answers 2

0

It sounds like your wallet’s UTXO pool is too small for the number of transactions you are making. Here are some possible ways to mitigate your issue:

  1. Dial-back consolidatory behavior
    If you are operating a send-only wallet, the default Bitcoin Core behavior might be too consolidatory for your use-case. Bitcoin Core uses multiple different coin selection algorithm to produce input set candidates when building transactions. You may want to set consolidatefeerate=0.00000000 in your config to always prefer less consolidatory input sets.
  2. Create more UTXOs
    If you have a lot of funds, but few UTXOs, you could combine the above with deliberately splitting up some of your largest UTXOs into many smaller useful pieces. Especially if you know that you will need a specific amount for later transactions, you could fan out a large piece into dozens or hundreds of outputs of that size in a single transaction.
  3. Use a higher feerate
    Your transactions exceeding the default ancestor count limit indicates that you are either combining funds from too many unconfirmed transactions, or making long chains of unconfirmed transactions. If you generally use a higher feerate for your transactions to ensure a prompt confirmation, this will free up confirmed UTXOs for later use.
  4. Batch payments
    Instead of adding new transactions for every payment, you could gather payment requests for some timespan and then create a single payment-batching transaction with multiple outputs. A send-only wallet using payment-batching will generally require way fewer UTXOs to reliably operate.
  5. Add more payments to previous unconfirmed transactions using RBF
    As a fairly advanced strategy, you could have only a single unconfirmed transaction in flight, and every time you get another payment request, you replace your unconfirmed transaction with a new version that adds the payment. This approach is limited in practice because each replacement needs to increase the feerate, and you need to add a new input with each batch of payments you fold into the transaction to ensure that you pay the recipients only once.

Overall, it seems to me that you may be trying to create an unsustainable count of transactions and should look into achieving the same outcome with fewer transactions.

1
  • 1
    Creating more UTXOs and setting consolidatefeerate=0 fixed the problem. I was batching payments already when I posted the question. Commented May 11 at 9:58
1

Nothing, as you are not deciding the ancestor count for other nodes. See https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-limits.md

Similar question: https://bitcoin.stackexchange.com/a/77056/61384

1
  • I'm thinking about increasing the number of available unspent outputs by creating a transaction that splits existing outputs into a larger number of outputs. Should I try that? Commented Apr 15 at 7:13

Your Answer

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

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