<p>The maximum unconfirmed descendant count is a mempool setting, not a wallet one. Assuming most of the network run with the default of <code>25</code>, even if you changed your own mempool to accept a longer chain the last child transaction would not relay.</p>
<p>Anyways, in such an extreme case (a chain of &gt;25 unconfirmed transactions) you likely want to <a href="https://bitcoin.stackexchange.com/a/101205/101498">bump your fees</a> already. And batch your transaction next time..</p>
<blockquote>
<p>how bitcoin core decides to allow an additional CPFP transaction to be chained, and when it gives an 'Insufficient Funds' error.</p>
</blockquote>
<p>The wallet will by default spend unconfirmed change (transactions it itself created), but not unconfirmed incoming payments.</p>

CC BY-SA 4.0
2021-01-12T14:13:58.997Z
Thanks for your answer. Unfortunately this doesn't really explain why I am unable to spend unconfirmed funds with chains less than 5. Currently I have unconfirmed change output from a single transaction ('chain' of 1) which I am unable to spend, with a 'Insufficient Funds' error, despite `getbalance` showing all of my expected funds. Do you have any idea what may be causing this, or a possible solution?
qmux
CC BY-SA 4.0
2021-01-12T14:23:56.007Z
What command are you using? Do you have `spendzeroconfchange=1`  (the default) ? Are you sure the wallet is only including this specific utxo (you may be confused by fees, too. Maybe and if possible do a dry run with a smaller amount)
Antoine Poinsot
CC BY-SA 4.0
2021-01-24T12:10:24.650Z
Turns out using `replacebyfee` alongside CPFP chains was causing bitcoin-core to refuse to spend unconfirmed change, likely because 'conflicting' chains of CPFP transactions could result in chaotic/non-deterministic wallet spending conditions. It's not fully clear to me whether or not CPFP and RBF are simply not designed to be used together, or if there is some better way of benefiting from either together that I do not currently know of.
qmux
CC BY-SA 4.0
2021-01-24T12:44:25.930Z
They are, but the Bitcoin Core wallet may not be ready to handle all edge cases yet (would have to dig a bit to give a more secure answer).
Antoine Poinsot
CC BY-SA 4.0
2021-02-08T22:17:10.917Z
Discovered that I get the same "Insufficient Funds" error, along with `getbalance` returning an incomplete balance when exclusively making CPFP txs (without doing RBF txs), and only 5/10 transactions of about 10/20 outputs. I'm a bit stumped as to why this issue still arises. Could it be related to using RBF explicit opt-in for all transactions?
qmux
CC BY-SA 4.0
2021-01-12T13:43:21.687Z
2021-01-12T14:21:30.850Z
2021-01-12T14:21:30.850Z
Antoine Poinsot
<p>I often receive an -32700 'Insufficient Funds' error when attempting to create 'child pays for parent' (CPFP) transactions using unconfirmed change output. This can be problematic since it can prevent me from sending further transactions until the parent transaction is confirmed.</p>
<p>My question:
Is there a bitcoin.conf setting (or other workaround/solution) that would allow for the acceptable length of chains of CPFP transactions/unconfirmed change outputs to be increased, and thereby avoid being stuck, unable to broadcast further bitcoin transactions until parent txs are confirmed?</p>
<p>A related side question - I have not yet discovered the logic behind how bitcoin core decides to allow an additional CPFP transaction to be chained, and when it gives an 'Insufficient Funds' error. It seems to be anywhere between a chain of 1 to ~5 (i.e. sometimes I get 'Insufficient Funds' error when there is only a 'chain' of one tx, other times, up to around 5) and it is not clear to me how this is determined. What is the logic here?</p>

<bitcoin-core><unconfirmed-transactions><bitcoin-cli><child-pays-for-parent>
Bitcoin.conf setting for CPFP - how can I enable longer 'chains' of unconfirmed transactions?
qmux
# Bitcoin.conf setting for CPFP - how can I enable longer 'chains' of unconfirmed transactions?

(Asked by: username_0 on 2021-01-12)

I often receive an -32700 'Insufficient Funds' error when attempting to create 'child pays for parent' (CPFP) transactions using unconfirmed change output. This can be problematic since it can prevent me from sending further transactions until the parent transaction is confirmed.

My question:
Is there a bitcoin.conf setting (or other workaround/solution) that would allow for the acceptable length of chains of CPFP transactions/unconfirmed change outputs to be increased, and thereby avoid being stuck, unable to broadcast further bitcoin transactions until parent txs are confirmed?

A related side question - I have not yet discovered the logic behind how bitcoin core decides to allow an additional CPFP transaction to be chained, and when it gives an 'Insufficient Funds' error. It seems to be anywhere between a chain of 1 to ~5 (i.e. sometimes I get 'Insufficient Funds' error when there is only a 'chain' of one tx, other times, up to around 5) and it is not clear to me how this is determined. What is the logic here?

**Tags:** bitcoin-core, unconfirmed-transactions, bitcoin-cli, child-pays-for-parent


---

## 1 answers

### Answer by username_1 on 2021-01-12. Score: 2

The maximum unconfirmed descendant count is a mempool setting, not a wallet one. Assuming most of the network run with the default of `25`, even if you changed your own mempool to accept a longer chain the last child transaction would not relay.

Anyways, in such an extreme case (a chain of >25 unconfirmed transactions) you likely want to [bump your fees](https://bitcoin.stackexchange.com/a/101205/101498) already. And batch your transaction next time..

> how bitcoin core decides to allow an additional CPFP transaction to be chained, and when it gives an 'Insufficient Funds' error.

The wallet will by default spend unconfirmed change (transactions it itself created), but not unconfirmed incoming payments.

> **Comments:**
> **username_0**: Thanks for your answer. Unfortunately this doesn't really explain why I am unable to spend unconfirmed funds with chains less than 5. Currently I have unconfirmed change output from a single transaction ('chain' of 1) which I am unable to spend, with a 'Insufficient Funds' error, despite `getbalance` showing all of my expected funds. Do you have any idea what may be causing this, or a possible solution?  
> **username_1**: What command are you using? Do you have `spendzeroconfchange=1`  (the default) ? Are you sure the wallet is only including this specific utxo (you may be confused by fees, too. Maybe and if possible do a dry run with a smaller amount)  
> **username_0**: Turns out using `replacebyfee` alongside CPFP chains was causing bitcoin-core to refuse to spend unconfirmed change, likely because 'conflicting' chains of CPFP transactions could result in chaotic/non-deterministic wallet spending conditions. It's not fully clear to me whether or not CPFP and RBF are simply not designed to be used together, or if there is some better way of benefiting from either together that I do not currently know of.  
> **username_1**: They are, but the Bitcoin Core wallet may not be ready to handle all edge cases yet (would have to dig a bit to give a more secure answer).  
> **username_0**: Discovered that I get the same "Insufficient Funds" error, along with `getbalance` returning an incomplete balance when exclusively making CPFP txs (without doing RBF txs), and only 5/10 transactions of about 10/20 outputs. I'm a bit stumped as to why this issue still arises. Could it be related to using RBF explicit opt-in for all transactions?  

---

