- Cluster mempool gets rid of CPFP Carve-out so Lightning needs a way to prevent
pinning once cluster mempool is widely deployed.
- v3 transactions is the proposed anti-pinning solution. It limits the worst-case for pinning since children are at most 1000 sat/vb and there can only be one child.
- A v3 transaction in the mempool may only have v3 descendants.
- A v3 transaction may only have 1 in-mempool descendant (aka 1 child).
- A v3 transaction may only have 1 in-mempool ancestor and it must be v3.
- A v3 child may only be up to 1000 vbytes in size.
The above rules make it so that the topology of the set of v3 transactions can only be at maximum 1 parent 1 child (1p1c) where the child is small.
Upgrading the commitment format to v3 transactions with a single anyone-can-spend anchor output ("ephemeral anchor") will take time.
Imbued v3 is a proposal where some v2 transactions would be grandfathered in and have v3 rules applied to them. The v3 rules only apply to a transaction if it has an in-mempool parent with two 330 satoshi outputs (e.g. its parent is a commitment transaction). Such a transaction would be rejected from the mempool if it violates any of the v3 policy rules. This includes having greater than 1 in-mempool parent.
Note that commitment transactions have 2 anchor outputs so on the surface it seems that imbued v3 transactions are at odds with both parties being able to feebump the commitment transaction. For example, if party A feebumps the anchor output first, then it seems that party B is unable to feebump from their anchor output since the 1 parent 1 child limit is already hit.
This shortcoming is fixed by another proposal called "sibling eviction". Simply put, it extends the RBF rules for v3 (and grandfathered v2) transactions such that a sibling transaction (i.e. not a direct conflict, so a transaction that does not spend the same inputs) can replace its sibling if it pays a better feerate. This means that B's anchor CPFP can replace A's anchor CPFP. This allows v3 policy to work with Lightning today without any upgrade on our end.
On our end, to make imbued v3 work, we need to change the way the sweeper deals with anchors. Two things immediately come to mind:
- Anchor spends cannot be batched with spends of an in-mempool transaction (e.g. batching anchor spends together).
- Anchor-spending transactions must be at maximum 1000 vbytes.
One downside with imbued v3 is that older LND nodes that batch anchor spends may be unable to feebump their commitment transactions as the 1 parent 1 child policy rule would be violated.
Is it possible to use Dynamic Commitments to upgrade to v3 commitment transactions?