Repository: bitcoin
Issue: Cluster mempool, CPFP carveout, and V3 transaction policy
Labels: Feature,TX fees and policy,Mempool

Opening an issue for high-level discussion, as the PR that implements this has gotten difficult to follow.

### Cluster mempool

Work is underway to [redesign the mempool](https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393/1) with different topology constraints on the transaction graph than exist today.  I originally described this proposal in a github issue (#27677), and have shared a draft implementation (#28676).  In brief, with a new mempool design we could simultaneously: fix bugs with mempool eviction and the incentive compatibility of RBF replacements; achieve improved performance; eliminate the ancestor/descendant limits (with the introduction of a likely more relaxed "cluster" limit); and likely be in a position to better implement complex behaviors like package validation and package rbf.

### CPFP carveout is not compatible with cluster mempool

As I explain [here](https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#the-cpfp-carveout-rule-can-no-longer-be-supported-12), I believe the CPFP carveout rule (introduced in #15681) is not compatible with the new design. Since some users may be relying on this behavior, we should come up with a workaround to avoid breaking existing applications.

### V3 transaction policy

Described in #28948, the v3 transaction policy is a proposal to introduce topology restrictions on unconfirmed transactions with `nVersion=3` (which are currently non-standard for relay, and would be made standard under the proposal).  Specifically, v3 transactions would be:
- opted-in to RBF replacement policies (whatever those may be, as they evolve in our project)
- permitted to only be part of mempool clusters that are at most of size 2 (meaning 1 parent/1 child)
- required to have any unconfirmed parents or children also be marked v3 (and therefore subject to these rules)
- bounded in size to at most 1000 vbytes, if the child of an unconfirmed (and therefore v3) parent

By offering a policy rule that can enforce a much tighter topology restriction that the current ancestor/descendant limits, we hope to achieve a few things:

#### Replacing CPFP carveout (with a new sibling-replacement policy)

We can provide a way to achieve the goals of the CPFP carveout rule even if the existing carevout rule were to be dropped. As explained in [this post](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html), the use-case contemplated by the CPFP carveout rule was one where a single transaction might have two spendable outputs, each spendable by a different party, and that either party should be able to spend their output without hitting global topology limits, provided that their spending transaction was bounded in size and had no other unconfirmed parents. If the v3 policy rule were to be applied to the LN commitment transactions described in that post, then neither of the two outputs that are spendable could be used to hit the limits that carveout is designed to bypass. 

So if we couple the v3 policy with an RBF rule that would allow one spend of a v3 transaction to replace an existing lower-feerate spend of that same parent -- something we call *sibling eviction* and has a draft implementation in #29306 -- then I believe we will have enacted a set of policies that replicate the CPFP carveout use case. 

#### Provide a general way for fee bumping to work better

Even apart from the needs of layer 2 protocols, the new v3 policy serves as a general way to bypass the issue of RBF being expensive when a child transaction is created that has a large fee (and is typically large in size, allowing for it to be low feerate).  This has been the source of user complaints since our RBF policies were first deployed, and by bounding the size of child transactions we effectively can limit the amount of additional fee a user would need to pay due to the presence of such children.  

Note, of course, that this property is also what makes the sibling-eviction-policy described above workable.

### Proposed roadmap

To unblock the cluster mempool project, I think we need the following:
1. Deployment of the V3 policy rules (current proposal is #28948)
2. Deployment of V3 sibling eviction rbf rules (current proposal is #29306)

Then, projects that use CPFP carveout would need to be able to adopt the new policy rules.  After the last LN spec discussion, I understand that migrating their commitment transactions to use a new format (even just a change in version number) might take time to coordinate, and that in the meantime we should simply use some other unique markers to identify those commitment transactions, and implicitly imbue such transactions with the v3 policy rules.  However, doing so would eliminate the ability to batch-CPFP several unconfirmed commitment transactions at once (although this isn't reliable anyway today, since the carveout protections don't apply to this case, but perhaps this sometimes works fine and is more efficient).

It's not clear to me if that final step -- of imbuing transactions with v3 policy, rather than requiring explicit opt-in -- is needed before we move further forward with cluster mempool, or even if doing so would be acceptable to the broader community, but I think we could entertain that idea as a way to assist the LN project with migration and to decouple progress in this project from upgrade timelines in that one.

### Feedback

While we're still working out implementation details in the v3 and v3-sibling-eviction PRs, it would be great to get concept ACKs on this roadmap from any users of the current CPFP carveout policy.  In particular, please provide feedback on:
1. whether there are use cases of CPFP carveout that are not covered by the V3 proposal as I described above, and 
2. whether the "imbued v3" behavior described above should be treated as a blocker for CPFP carveout removal as well, or if it's a bad idea due to (eg) breaking the ability to batch-CPFP (or any other reason)