# Cluster Mempool RBF Thoughts

**URL:** <https://delvingbitcoin.org/t/cluster-mempool-rbf-thoughts/156>\
**Category:** Implementation\
**Tags:** wg-cluster-mempool\
**Created:** [November 1, 2023, 2:06am UTC](https://delvingbitcoin.org/t/cluster-mempool-rbf-thoughts/156 "2023-11-01T02:06:07Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![ajtowns](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/ajtowns/32/417_2.png) [@ajtowns](https://delvingbitcoin.org/u/ajtowns)\
**Post date:** [December 5, 2023, 5:44pm UTC](https://delvingbitcoin.org/t/cluster-mempool-rbf-thoughts/156/14 "2023-12-05T17:44:23Z")

</div>

> [@instagibbs](#):
>
> Assuming these sizes are problematic, the two levers I see are cluster size, and number of allowed clusters to touch.

If you limit the number of allowed clusters to touch but dropped the ancestor count limit (leaving it implied by the chunk limit), you could get a weird scenario:

Suppose you have a CPFP arrangement to pay for a bunch of txs:

```mermaid
graph TD
   P1 --> C
   P2 --> C
   Pn[P3..P10] --> C

```

But then you realise there’s another 20 txs you want to CPFP, so you RBF C as:

```mermaid
graph TD
   P1 --> C
   P2 --> C
   P3 --> C
   P4 --> C
   P5 --> C
   Pn[P6..P30] --> C[C2]

```

You repeat this until you hat max chunk size:

```mermaid
graph TD
   P1 --> C
   P2 --> C
   Pn[P3..P99] --> C[C6]

```

And that all works fine: you’re merging 21 clusters with C2, another 21 clusters with C3, C4 and C5 and a final 10 clusters with C6.

But what if you didn’t see C2, C3, C4 or C5, but had seen P11…P99? C6 alone would look like it was merging 90 clusters, which would presumably be more than the allowed cluster limit. So the rbf from C1 to C6 becomes path dependent: doing it directly fails, but doing it indirectly works.

---

_[View the full topic](https://delvingbitcoin.org/t/cluster-mempool-rbf-thoughts/156)._
