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


--yP7q3x4oa9g2R/MJ
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

On Mon, Jul 22, 2024 at 06:43:14AM -1000, David A. Harding wrote:
> On 2024-07-22 01:45, Peter Todd wrote:
> > TRUC meanwhile isn't even a drop-in solution, and requires everyone to
> > upgrade before cluster mempool is even possible.
> 
> The proposed BIP for TRUC[1] is indeed entirely opt-in and would require
> all users of CPFP-CO (e.g. LN anchors channels) to upgrade their
> software and switch to a new commitment transactions format, which
> currently requires closing and reopening all anchors channels.  There's
> work on improving upgrade mechanisms in LN, but it would still be a pain
> and a major delay to cluster mempool to depend on every LN user
> upgrading.
> 
> However, there has also been significant discussion and analysis[2] of an
> imbued-semantics form of TRUC that could be retroactively applied to
> LN-style anchor outputs (which are the only users of CPFP-CO we know
> about).  In that case, nobody needs to upgrade before cluster mempool
> becomes possible.
> 
> In my previous email, I assumed you were familiar with the imbued
> semantics proposal; I'm sorry for the miscommunication.

I am aware of that proposal. It is not a proposal with "significant discussion
and analysis", your link, [2], has three posts in total, with discussion ending
in Febuary, with only the OP having any significant content. Both replies to
the idea noted potential incompatibilites with existing implementations. I'm
not aware of any running code nor any significant discussion amongst LN
implementations and other stakeholders. The idea hasn't even been posted to
this mailing list.

That's why I never brought it up: the idea seems to have died out.

Frankly, unless you can point to actual "significant discussion and analysis"
of the idea, it's dishonest and toxic of you to portray it as such as you
should know better. RBFR has had more "significant discussion and analysis"
than this idea in this very thread.

Personally, I think it might not be an unreasonable hack before something
better like RBFR gets implemented. But it's only a hack. And if anything, it
strongly suggests that actually permanently specifying TRUC/V3 is an
unnecessary complication.

> -Dave
> 
> [1] https://github.com/bitcoin/bips/blob/158acdbbbf8ef13f6b345b6281a96e88e20d2cf9/bip-truc.mediawiki#user-content-Specification
> [2] https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527

-- 
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/Zp674YtMTaUX3imH%40petertodd.org.

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmaeu9IACgkQLly11TVR
Lzfz+Q//TqHPI1ZUalLs5nRP64xm7Bk4LZEJxTr+M+gHM/cMCSmDA4Fnbau1cRbe
JYkvyAkjTkjI/ZH8OcLO+17fxc9MX1/mIhARQWFusNvCRD4cf+1boVTWF034bc8o
cV5b3y9IiwKNAmzxPE95H3SUGBVNA+a9c4bAcs2FZGSFpKjCQMBQKDHWIczayXAw
59NwswSv4TrbPnTDFqDqT/LDYb/m0njFIfY8vKvnTDn1VmOSvbELn86nC9s/QYPD
r+zXGMhhJw0f3HUUen8q94580WJDYsDzr5WHQPCiykNbO/8XzTFRnGHTDzE8wvdF
fs7FvsTm7ShX9BxxZG583Ht9JY+VvGPmXvhPAk40itziZi0+Bh96KSfQIThPl0Ta
BqjJPjfa0Q0OzEBUMDgl51206jEib3hHQ8izzVfqj0HlttYpXdn8wqOLyKnfswtC
GJ0uzYkGhjiuJ+rfkHSufCWTiXIENglkv+fk3De7EPJSHfhwlFmC6lgqx8aA29/K
AwQ1Qkdcun8I1zBbh/vuRXxMU3weSKTCecv2Id0zxvEmsF+b4gCm3PlSztECaES9
vOk2tYqeoAMGfeImNHktefkWZg3Oq2ovjjte99c7MEnUMxtYIX3jUXUu7RAC4sEM
z1oiBA96/nulTyl8dhpmBI1zNGL5vkaZ7AlI2n6pCJtskyz0P5A=
=RbHR
-----END PGP SIGNATURE-----

--yP7q3x4oa9g2R/MJ--