Delivery-date: Mon, 22 Jul 2024 05:06:52 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) client-ip=103.168.172.151;
Feedback-ID: i525146e8:Fastmail
Date: Mon, 22 Jul 2024 11:45:31 +0000
From: Peter Todd <pete@petertodd.org>
To: "David A. Harding" <dave@dtrt.org>
Cc: bitcoindev@googlegroups.com
Subject: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster
 mempool, without upgrading LN nodes; TRUC/V3 does not
Message-ID: <Zp5GW/yHzPB8wyjU@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="CmiQh1B8k9DSHLU1"
Content-Disposition: inline
In-Reply-To: <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--CmiQh1B8k9DSHLU1
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 pinni=
ng
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=C2=B9 is an exception to package size limits t=
hat
allows a single transaction to exceed those limits slighty, provided that t=
he
transaction has only one unconfirmed ancestor. This is relevant to protocol=
s
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 s=
uch
that the total package size is just under the package limit. Notably, in th=
is
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 incompat=
ible
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 existin=
g
child transaction(s), and the parent transaction. With RBF alone, that woul=
d
allow you to defeat a package size pin by paying more in fees than the
conflicting child transaction(s), reducing this scenario to a straightforwa=
rd
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-r=
ate
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) mi=
ned.
The only thing protocols need to do is ensure that the combination of paren=
t
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 ha=
ve
to wait for existing Lightning users to upgrade and open new channels. Inde=
ed,
we even fix existing pinning problems for existing Lightning implementation=
s,
which RBFR is already=C2=B2 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

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

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/Zp5GW/yHzPB8wyjU%40petertodd.org.

--CmiQh1B8k9DSHLU1
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmaeRlkACgkQLly11TVR
LzfJLg//Zyljmi4YmcyauyrFs3DYiC1ZCC+zXBOzDOxwiAeLTltdrU7fHX74k1LH
LYym7max1fXoRO2rRL7lilDxtg9nW4xUHnpmZ+pmCjjL0xruptw6OkQOgraYyXM2
SN7iCZp+j45pI39j9X0LNx5It6lCnP1TAJzU50sQUj6FC1F0NwPIrbdMc5QTLOE1
og5DfsgU86hDXeeYN+gBpZDEpnPyzNn7nDDM3tILPULTNlddvQ22ecxcYrCoYDdN
k9qhzdi3iRitua7nu2NoVzKAr8KWgVJDvo+CD+pY1OD0Q/DfAVxYXQbc9w08HrJN
w3iQHK6aW7Q4SI6YFkosTu/0UtjaaeLVFedr1zkn1EmQv542NXT8MpP0Ey6KFpKy
HNmmGkGDGWhleTCQm7xpVon2xv4g3UhQVC67bn+2eChtzgbAu4qm90zFUqpueu76
7vUe8kppF9ryf+YrC9Xtj9AgmrUrvK+aCmHkC3fw1hwsQwMCQ3g08/ed+qA4Osj2
5CqJJOycolpOdbH9E4FjLu0SXgw6apasBIG+NJHDrWg8jRYcnUs05+xhcMG7FUUr
+Ucdi1/CpKf8TyrH/0u8SWiCQl9a60VQ82kLPVIGQGsHL3FYQ0iL8IFgUc0IY9LC
l5srqLtPKRapRuwR9TuwVt7fZ3dOrZlYeasFhjsqS0gziG2BPsc=
=3HCN
-----END PGP SIGNATURE-----

--CmiQh1B8k9DSHLU1--