On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote:
> 3. Limiting the worst-case free relay and excessive mempool eviction
>    requires additional rules (e.g. one-shot RBFr) that are challenging
>    to implement and analyze at present, as several devs have noted[3].
>    Both implementation and analysis should become much easier if cluster
>    mempool is deployed (also noted by devs), but the deployment of
>    cluster mempool requires removal of CPFP carve-out, and removal of
>    CPFP carve-out requires either the upgrade of thousands of LN nodes
>    and channels or a drop-in solution (ideally one that can be analyzed
>    independently from cluster mempool, like TRUC).

I'm going to answer this separately for the sake of easy citation in the
future. tl;dr: cluster RBFR makes the CPFP carve-out obsolete, fixing pinning
for existing implementations; TRUC meanwhile isn't even a drop-in solution, and
requires everyone to upgrade before cluster mempool is even possible.

To recap, the CPFP carve-out¹ is an exception to package size limits that
allows a single transaction to exceed those limits slighty, provided that the
transaction has only one unconfirmed ancestor. This is relevant to protocols
like Lightning, where your counterparty might try to pin a transaction by
spending one of the two anchor outputs with a large, low-fee, transaction such
that the total package size is just under the package limit. Notably, in this
scenario, there is *no* way for you to broadcast a CPFP without the CPFP
carve-out because regardless of fee-rate, your transaction will simply be
rejected due to it causing the package limit to be exceeded.

I won't comment on whether or not the cluster mempool is genuinely incompatible
with CPFP carveouts; I'm not convinced that's true. But that point is
irrelevant anyway. To understand why, let's look at package replacement.

Package replacement is the idea that we can do RBF with packages of
transactions. For situations where the CPFP carve-out is relevant, we can
instead evaluate the CPFP child transaction, and the parent transaction(s), as
a package and compare that package to the package consisting of the existing
child transaction(s), and the parent transaction. With RBF alone, that would
allow you to defeat a package size pin by paying more in fees than the
conflicting child transaction(s), reducing this scenario to a straightforward
BIP-125 Rule #3 total fees pin.

Actually implementing this type of package replacement is simple: if you
receive a single transaction with an unconfirmed parent, if the transaction is
rejected due to package limits, try again, treating it as a package
replacement.

Finally, with package (one-shot) RBFR, we defeat both the package size pin and
the Rule #3 pin: so long as your CPFP child transaction pays a higher fee-rate
than the conflicting large, low-fee-rate, child transaction(s) made by the
attacker, you can replace the conflict and get the parent transaction(s) mined.
The only thing protocols need to do is ensure that the combination of parent
transaction(s) and child CPFP doesn't itself exceed the package size limits,
which Lightning already does just fine.


This is a much better upgrade path than TRUC + cluster mempool. We don't have
to wait for existing Lightning users to upgrade and open new channels. Indeed,
we even fix existing pinning problems for existing Lightning implementations,
which RBFR is already² doing!. And we actually fix pinning in general, for all
use-cases, not just the narrow subset that can make use of TRUC.


# References

1) https://bitcoinops.org/en/topics/cpfp-carve-out/
2) https://groups.google.com/g/bitcoindev/c/n2GNmnz0btw

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp5GW/yHzPB8wyjU%40petertodd.org.