<p>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:</p>
<ol>
<li><strong>Dial-back consolidatory behavior</strong><br />
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 <code>consolidatefeerate=0.00000000</code> in your config to always prefer less consolidatory input sets.</li>
<li><strong>Create more UTXOs</strong><br />
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.</li>
<li><strong>Use a higher feerate</strong><br />
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.</li>
<li><strong>Batch payments</strong><br />
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.</li>
<li><strong>Add more payments to previous unconfirmed transactions using RBF</strong><br />
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.</li>
</ol>
<p>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.</p>

CC BY-SA 4.0
2024-05-11T09:58:29.303Z
Creating more UTXOs and setting `consolidatefeerate=0` fixed the problem. I was batching payments already when I posted the question.
Mikhail Yevchenko
CC BY-SA 4.0
2024-04-15T15:10:44.277Z
2024-04-15T15:10:44.277Z
Murch
<p>Nothing, as you are not deciding the ancestor count for other nodes. See <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-limits.md" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-limits.md</a></p>
<p>Similar question: <a href="https://bitcoin.stackexchange.com/a/77056/61384">https://bitcoin.stackexchange.com/a/77056/61384</a></p>

CC BY-SA 4.0
2024-04-15T07:13:59.563Z
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?
Mikhail Yevchenko
CC BY-SA 4.0
2024-04-14T20:20:04.487Z
2024-04-14T20:20:04.487Z
Jan Janssen
<p>I'm encountering an issue with Bitcoind where I frequently get the error:</p>
<p>&quot;Unconfirmed UTXOs are available, but spending them creates a chain of transactions that will be rejected by the mempool.&quot;</p>
<p>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?</p>

CC BY-SA 4.0
2024-04-14T20:22:52.033Z
Does this answer your question? [64: too-long-mempool-chain](https://bitcoin.stackexchange.com/questions/59178/64-too-long-mempool-chain)
Jan Janssen
<utxo><utxo-management>
How to avoid "Unconfirmed UTXOs are available, but spending them creates a chain of transactions that will be rejected by the mempool"?
Mikhail Yevchenko
# How to avoid "Unconfirmed UTXOs are available, but spending them creates a chain of transactions that will be rejected by the mempool"?

(Asked by: username_0 on 2024-04-13)

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?

**Tags:** utxo, utxo-management

> **Comments:**
> **username_1**: Does this answer your question? [64: too-long-mempool-chain](https://bitcoin.stackexchange.com/questions/59178/64-too-long-mempool-chain)  

---

## 2 answers

### Answer by username_2 on 2024-04-15. Score: 0 | Accepted answer

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.

> **Comments:**
> **username_0**: Creating more UTXOs and setting `consolidatefeerate=0` fixed the problem. I was batching payments already when I posted the question.  

---

### Answer by username_1 on 2024-04-14. Score: 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>

> **Comments:**
> **username_0**: 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?  

---

