<p>In the mempool validation logic, the maximum chain size checks are performed without first removing the transaction to be replaced. That is, if there is a chain of 25 unconfirmed transactions such as:</p>
<pre><code>txA &lt;-- txB &lt;-- txC &lt;-- ... &lt;-- txY
</code></pre>
<p>And a candidate for replacing <code>txY</code> (<code>txY'</code>) is submitted, the mempool limits will be checked with the following topology:</p>
<pre><code>txA &lt;-- txB &lt;-- txC &lt;-- ... &lt;-- txY
                            \-- txY'
</code></pre>
<p><code>txA</code> will therefore fail <a href="https://github.com/bitcoin/bitcoin/blob/95a3934cf3973b4083ca30779c8a0ae45fa636ae/src/validation.cpp#L922" rel="nofollow noreferrer">the descendants count limit check</a> (since it's now 26, accounting for itself) [0].</p>
<p>The wallet logic when creating a transaction (not only for fee bumps) mimics this logic (<a href="https://github.com/bitcoin/bitcoin/blob/95a3934cf3973b4083ca30779c8a0ae45fa636ae/src/wallet/spend.cpp#L1253-L1256" rel="nofollow noreferrer">1</a>, <a href="https://github.com/bitcoin/bitcoin/blob/95a3934cf3973b4083ca30779c8a0ae45fa636ae/src/node/interfaces.cpp#L700-L708" rel="nofollow noreferrer">2</a>). This is why the <code>bumpfee</code> command for the 25th transaction in an unconfirmed chain fails.</p>
<hr />
<p>[0]: This ignores the RBF carveout for simplicity.</p>

CC BY-SA 4.0
2023-11-13T10:28:23.793Z
Ok, thanks. What's the rationale for this behavior? What's the risk of allowing the replacement?
Kalle Rosenbaum
CC BY-SA 4.0
2023-11-13T10:35:16.600Z
I wasn't around when it was introduced, but thinking through how one would make this change seems like a lot of hassle for little gain. It could however be documented as it's an interface for external softwares.
Antoine Poinsot
CC BY-SA 4.0
2023-11-13T13:12:59.103Z
The gain would be that I can get my 25 stuck transactions unstuck. A workaround for this issue is to avoid creating the 25th tx in the first place, to save it fee-bumps so to speak.
Kalle Rosenbaum
CC BY-SA 4.0
2023-11-13T09:53:08.213Z
2023-12-06T11:54:08.017Z
2023-12-06T11:54:08.017Z
Antoine Poinsot
<p>I have a chain of 25 unconfirmed transactions. There's a default mempool limit of 25 chained unconfirmed transactions, so my change output of the 25th transaction is not usable until some of the transactions have confirmed.</p>
<p>To make it confirm, I thought I'd bumpfee the last (25th) tx.</p>
<pre><code>$ bitcoin-cli bumpfee &lt;txid&gt; '{&quot;fee_rate&quot;: 410}'
error code: -4
error message:
Unable to create transaction. Transaction has too long of a mempool chain
</code></pre>
<p>Why do I get this error? I'm not making the chain longer, I'm just trying to replace the last tx.</p>

<bitcoin-core><unconfirmed-transactions><mempool><replace-by-fee>
Why can't I bumpfee the 25th tx in an unconfirmed chain?
Kalle Rosenbaum
# Why can't I bumpfee the 25th tx in an unconfirmed chain?

(Asked by: username_0 on 2023-11-13)

I have a chain of 25 unconfirmed transactions. There's a default mempool limit of 25 chained unconfirmed transactions, so my change output of the 25th transaction is not usable until some of the transactions have confirmed.

To make it confirm, I thought I'd bumpfee the last (25th) tx.

```
$ bitcoin-cli bumpfee <txid> '{"fee_rate": 410}'
error code: -4
error message:
Unable to create transaction. Transaction has too long of a mempool chain

```

Why do I get this error? I'm not making the chain longer, I'm just trying to replace the last tx.

**Tags:** bitcoin-core, unconfirmed-transactions, mempool, replace-by-fee


---

## 1 answers

### Answer by username_1 on 2023-11-13. Score: 3 | Accepted answer

In the mempool validation logic, the maximum chain size checks are performed without first removing the transaction to be replaced. That is, if there is a chain of 25 unconfirmed transactions such as:

```
txA <-- txB <-- txC <-- ... <-- txY

```

And a candidate for replacing `txY` (`txY'`) is submitted, the mempool limits will be checked with the following topology:

```
txA <-- txB <-- txC <-- ... <-- txY
                            \-- txY'

```

`txA` will therefore fail [the descendants count limit check](https://github.com/bitcoin/bitcoin/blob/95a3934cf3973b4083ca30779c8a0ae45fa636ae/src/validation.cpp#L922) (since it's now 26, accounting for itself) [0].

The wallet logic when creating a transaction (not only for fee bumps) mimics this logic ([1](https://github.com/bitcoin/bitcoin/blob/95a3934cf3973b4083ca30779c8a0ae45fa636ae/src/wallet/spend.cpp#L1253-L1256), [2](https://github.com/bitcoin/bitcoin/blob/95a3934cf3973b4083ca30779c8a0ae45fa636ae/src/node/interfaces.cpp#L700-L708)). This is why the `bumpfee` command for the 25th transaction in an unconfirmed chain fails.

---

[0]: This ignores the RBF carveout for simplicity.

> **Comments:**
> **username_0**: Ok, thanks. What's the rationale for this behavior? What's the risk of allowing the replacement?  
> **username_1**: I wasn't around when it was introduced, but thinking through how one would make this change seems like a lot of hassle for little gain. It could however be documented as it's an interface for external softwares.  
> **username_0**: The gain would be that I can get my 25 stuck transactions unstuck. A workaround for this issue is to avoid creating the 25th tx in the first place, to save it fee-bumps so to speak.  

---

