From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 23 Jul 2024 17:44:43 -0700 Received: from mail-yb1-f183.google.com ([209.85.219.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sWQ7X-0004r2-14 for bitcoindev@gnusha.org; Tue, 23 Jul 2024 17:44:43 -0700 Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e02b7adfb95sf12827597276.2 for ; Tue, 23 Jul 2024 17:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721781877; x=1722386677; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=dSz4k3rCP27gI53zOPt0XXB+b2DSFzuifezCIP8H4dA=; b=XjXuInKfpBhsB1nC3W5DUn6KIvl6R5OxhEkEg8+xwZLkFCZmF/263b/tWZroGxboan 6YSc0YltvlkyRSzdM5gi+m4wqUszvA1ybVeFplih4iMAUftknRQTJ2EzjPP2RSN0Muvd YgHMILv1qjM1egv+w2O169yA2eUE3q860R+IggdP/i/PfmrozDpBaDQgba+HDRTW3AGK EcMtN1tHGJASDMlfRoB7MIUhD9DUEvzHhiJBwuCEDuzp/tuLe+o0ZmXSkwXvfSzwWV8z OozFnVH4/Q6K834cfke6wmgxijPl6+qzhuSQ8SgFw99TY9yrhDjwhRW3ibgvE4k+x61M byTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721781877; x=1722386677; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=dSz4k3rCP27gI53zOPt0XXB+b2DSFzuifezCIP8H4dA=; b=Be9YAgj4h1nxywIYar5F9KBq59wsQrMa/jsszn4fwfkEKXS7ZdlGhV38BuqJIAnHjC KK0oXSOXGrtFvbFYHMeiXGBqjYb0Q8QqyXalEYciMwvIOHoF+/bpt9UjMfuvOxVc5ypZ MFQJb1cXwX1dcw9RhcX4h2LlErvcCUTVXsi/zFDH0k8C3Kc1qMYc0myv3OIDDoOR+GCN e5AAPUvKGpWcf0mZ1o2WiFBvPnf87dlPEmG1HmWsuLGCucnAoXt0aTNICEfQP5bJC98U O0WFxYMv3bxyKYly8pGib7BEVn1FPuRXIltZDYMgdnZY/HundOGkBGO20rvQ5cxPzUdN JCPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721781877; x=1722386677; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=dSz4k3rCP27gI53zOPt0XXB+b2DSFzuifezCIP8H4dA=; b=CaBtKMl2bRpz2Ht4CYF1giRwX00ITWGUfhI+IcP4TQ4YXd2V/soSrdUUdti7VFmERs 5H5vGCkshrrNAsAAAfX2RdUF9pGAbRVOn2iZalRZy/TFbWF6GeGQE2ybnkBkqPK0C3Z+ s7LbgnfeEVT06RkQaaZ6i1y36HnuxrMFaKPX9dQfn0JaStcBBadM1nwkgpLZN0Iai6Eu zZoxNiSwD9ChdY7s9ozYZCS9Bkg4YZKqpx8GL2D+Py2Oe/V2CIHokK9YH8e+IK1dNEha BDE2gqs08kM1bCTDsPfN0ipqQ49/97dcW9QlNh0tcJhxhG4TJTBzMELWeLA5LqGMCpm1 IHZQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV5CEcA6lb3rJMWLV33iwiVNDFz17i7XF1+W0i6vV+h//In0hQAiF/ftct6l82HAEDxtsEMNRcAxbwzvB5RUoRSeG/0iVM= X-Gm-Message-State: AOJu0Yyq2qjvjOCwG5pKbFJJVaCI46elOU6yMWG6feAxEhq7MmLg9k0X lciN4Ari+4uUEwFvH3DZ3AZ2jTUMganyZjyomJHISRYOVnecbZuJ X-Google-Smtp-Source: AGHT+IGPwYjQY9fci+EOrJ9RPjyLbWu8vz5RbGwbHwxJkGVRjiVQ7WCEPvOCpLBIpN4YXZEBoj+qXQ== X-Received: by 2002:a25:b191:0:b0:e08:7bf9:4d76 with SMTP id 3f1490d57ef6-e0b09850f9fmr1703746276.46.1721781876627; Tue, 23 Jul 2024 17:44:36 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:4a04:0:b0:e05:a345:25b6 with SMTP id 3f1490d57ef6-e05fd903374ls9645408276.0.-pod-prod-07-us; Tue, 23 Jul 2024 17:44:35 -0700 (PDT) X-Received: by 2002:a05:6902:1202:b0:e05:f6ba:1982 with SMTP id 3f1490d57ef6-e086fcbac41mr354192276.0.1721781875264; Tue, 23 Jul 2024 17:44:35 -0700 (PDT) Received: by 2002:a05:690c:3104:b0:664:87b6:d9e0 with SMTP id 00721157ae682-66918fcc18cms7b3; Tue, 23 Jul 2024 17:42:26 -0700 (PDT) X-Received: by 2002:a05:690c:f06:b0:648:3f93:68e0 with SMTP id 00721157ae682-66a66837666mr6867417b3.6.1721781745620; Tue, 23 Jul 2024 17:42:25 -0700 (PDT) Date: Tue, 23 Jul 2024 17:42:25 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <1d532e88-d40a-4417-bdac-6c4bbf90c26en@googlegroups.com> In-Reply-To: <6c222c758e10e8061ccdcc180b1826a3@dtrt.org> References: <0eeb34c87b4cd7c9165983dc3a613550@dtrt.org> <6c222c758e10e8061ccdcc180b1826a3@dtrt.org> Subject: Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1061644_1012886377.1721781745387" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_1061644_1012886377.1721781745387 Content-Type: multipart/alternative; boundary="----=_Part_1061645_1801039998.1721781745387" ------=_Part_1061645_1801039998.1721781745387 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, > I'm sorry you've been unable to keep up with protocol development and > are confusing that for me being dishonest and toxic. May I suggest you > subscribe to the weekly Optech newsletter? It's free. See my review comments on the imbuance mechanism PR on bitcoin core, I think it's broken in the sense that you can escapce the imbuanche mechanism by playing on commitment output scriptpubkye / amount collision. Bitcoin core is a public project so you're free to access the 5 months old comments now and make your own opinion. For now, I think there is no bitcoi= n core code available for a robust imbuanche mechanism, so this whole roadmap= =20 thing you're presenting in your post or in the bitcoin optech newsletter I= =20 don't know if it's technically sound, and not a bit misleading for the bitcoin=20 industry players periodically reading it. Best, Antoine ots hash: a75c98ab5166c541ecba5e579639f359e82ff315df89b04264b29f8dfaa87502 Le lundi 22 juillet 2024 =C3=A0 23:10:33 UTC+1, David A. Harding a =C3=A9cr= it : > On 2024-07-22 10:06, Peter Todd wrote: > > can [you] point to actual "significant discussion and analysis" > > of the idea > > The idea for imbued TRUC was developed in part during a live > discussion with LN maintainers: > > https://btctranscripts.com/lightning-specification/lightning-2024-01-15-s= pecification-call/ > > I'm aware of three discussions about it on the Delving Bitcoin Forum: > > -=20 > > https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral= -anchors/418/2 > -=20 > > https://delvingbitcoin.org/t/sibling-eviction-for-v3-transactions/472#ben= efits-1 > - (as previously linked)=20 > > https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitmen= t-transaction-spends-with-v3-semantics/527 > > Each of those discussions was summarized by a Bitcoin Optech Newsletter, > a publication read by many Bitcoin and LN protocol developers > (disclosure: I co-author the newsletter): > > "Adding this policy and automatically applying it to current LN=20 > anchors > will allow the CPFP carve-out rule to be removed, which is necessary=20 > for > cluster mempool to be implemented, which should allow making > replacements of all kinds more incentive-compatible in the future." > > > https://bitcoinops.org/en/newsletters/2024/01/31/#kindred-replace-by-fee > > "Imbued v3 logic: In response to concerns voiced in the LN spec=20 > meeting > that it may take a long time for LN to design, implement, and deploy > these changes, Gregory Sanders proposed an intermediate stage with > temporary special treatment of transactions that look like current > anchors-style LN commitment transactions, allowing Bitcoin Core to > deploy cluster mempool without being blocked by LN development." > > https://bitcoinops.org/en/newsletters/2024/01/24/#imbued-v3-logic > > "[...] research into the idea of automatically applying v3 transaction > relay policy to anchors-style LN commitment and fee-bumping=20 > transactions > (see Newsletter #286 for the underlying imbued v3 proposal)." > > > > https://bitcoinops.org/en/newsletters/2024/02/14/#what-would-have-happene= d-if-v3-semantics-had-been-applied-to-anchor-outputs-a-year-ago > > The word "imbue" is mentioned in 7 separate posts by 4 separate authors > in a Bitcoin Core discussion issue that includes comments from three > different LN implementation maintainers plus @petertodd, who I assumed > was you: https://github.com/bitcoin/bitcoin/issues/29319 > > That thread also links to a draft implementation of imbued v3, which was > used for the Analysis forum post: > https://github.com/bitcoin/bitcoin/pull/29427 > > As discussed in the "sibling eviction" thread (summarized in the > 2024-01-31 newsletter), one of the necessary parts for imbued TRUC to be > effective at replacing CPFP-CO is sibling eviction. A version of that > (currently only for opt-in TRUC) was merged into Bitcoin Core several=20 > months > ago: https://github.com/bitcoin/bitcoin/pull/29306 > > I note that none of the above was hidden or hard to find. All three of > the discussion summaries quoted above are linked on the Bitcoin Optech > topic page about v3 relay/TRUC, and two of them are also linked on the > topic pages about CPFP-CO and anchor outputs. Most of the other stuff I > found by searching the bitcoin/bitcoin repository for the word "imbue": > > - https://bitcoinops.org/en/topics/version-3-transaction-relay/ > - https://bitcoinops.org/en/topics/cpfp-carve-out/ > - https://bitcoinops.org/en/topics/anchor-outputs/ > > > Frankly, unless you can point to actual "significant discussion and=20 > > analysis" > > of the idea, it's dishonest and toxic of you to portray it as such as= =20 > > you > > should know better. > > I'm sorry you've been unable to keep up with protocol development and > are confusing that for me being dishonest and toxic. May I suggest you > subscribe to the weekly Optech newsletter? It's free. > > -Dave > --=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/1d532e88-d40a-4417-bdac-6c4bbf90c26en%40googlegroups.com. ------=_Part_1061645_1801039998.1721781745387 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave,

> I'm sorry you've been unable to keep up with proto= col development and
> are confusing that for me being dishonest and= toxic. May I suggest you
> subscribe to the weekly Optech newslett= er? It's free.

See my review comments on the imbuance mechanism = PR on bitcoin core, I
think it's broken in the sense that you can esca= pce the imbuanche mechanism
by playing on commitment output scriptpubk= ye / amount collision.

Bitcoin core is a public project so you'r= e free to access the 5 months old
comments now and make your own opini= on. For now, I think there is no bitcoin
core code available for a rob= ust imbuanche mechanism, so this whole roadmap
thing you're presentin= g in your post or in the bitcoin optech newsletter I don't
know if it'= s technically sound, and not a bit misleading for the bitcoin industry
players periodically reading it.

Best,
Antoine
ots ha= sh: a75c98ab5166c541ecba5e579639f359e82ff315df89b04264b29f8dfaa87502
<= br />
Le l= undi 22 juillet 2024 =C3=A0 23:10:33 UTC+1, David A. Harding a =C3=A9crit= =C2=A0:
On 20= 24-07-22 10:06, Peter Todd wrote:
> can [you] point to actual "significant discussion and analysi= s"
> of the idea

The idea for imbued TRUC was developed in part during a live
discussion with LN maintainers:
https://btctranscripts.com/lightning-specification/lightning-2= 024-01-15-specification-call/

I'm aware of three discussions about it on the Delving Bitcoin Foru= m:

-=20
https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-epheme= ral-anchors/418/2
-=20
https:/= /delvingbitcoin.org/t/sibling-eviction-for-v3-transactions/472#benefits-1
- (as previously linked)=20
https://delvin= gbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-sp= ends-with-v3-semantics/527

Each of those discussions was summarized by a Bitcoin Optech Newsletter= ,
a publication read by many Bitcoin and LN protocol developers
(disclosure: I co-author the newsletter):

"Adding this policy and automatically applying it to current LN= =20
anchors
will allow the CPFP carve-out rule to be removed, which is necessary= =20
for
cluster mempool to be implemented, which should allow making
replacements of all kinds more incentive-compatible in the future.&q= uot;

=20
https://bitcoinops.org/= en/newsletters/2024/01/31/#kindred-replace-by-fee

"Imbued v3 logic: In response to concerns voiced in the LN spec= =20
meeting
that it may take a long time for LN to design, implement, and deploy
these changes, Gregory Sanders proposed an intermediate stage with
temporary special treatment of transactions that look like current
anchors-style LN commitment transactions, allowing Bitcoin Core to
deploy cluster mempool without being blocked by LN development."= ;

https://bitcoinops.org/en/newslett= ers/2024/01/24/#imbued-v3-logic

"[...] research into the idea of automatically applying v3 tran= saction
relay policy to anchors-style LN commitment and fee-bumping=20
transactions
(see Newsletter #286 for the underlying imbued v3 proposal)."

=20
https://bitcoinops.org/en/newsletters/2024/02= /14/#what-would-have-happened-if-v3-semantics-had-been-applied-to-anchor-ou= tputs-a-year-ago

The word "imbue" is mentioned in 7 separate posts by 4 separa= te authors
in a Bitcoin Core discussion issue that includes comments from three
different LN implementation maintainers plus @petertodd, who I assumed
was you: https://github.com/bitcoin/bitcoin/issues/29319

That thread also links to a draft implementation of imbued v3, which wa= s
used for the Analysis forum post:
http= s://github.com/bitcoin/bitcoin/pull/29427

As discussed in the "sibling eviction" thread (summarized in = the
2024-01-31 newsletter), one of the necessary parts for imbued TRUC to b= e
effective at replacing CPFP-CO is sibling eviction. A version of that
(currently only for opt-in TRUC) was merged into Bitcoin Core several= =20
months
ago: https://github.com/bitcoin/bitcoin/pull/29306

I note that none of the above was hidden or hard to find. All three of
the discussion summaries quoted above are linked on the Bitcoin Optech
topic page about v3 relay/TRUC, and two of them are also linked on the
topic pages about CPFP-CO and anchor outputs. Most of the other stuff = I
found by searching the bitcoin/bitcoin repository for the word "im= bue":

- https://bitcoinops.org/en/topics/version-3-tr= ansaction-relay/
- https://bitcoinops.org/en/topics/cpfp-carve-out/
- https://bitcoinops.org/en/topics/anchor-outputs/

> Frankly, unless you can point to actual "significant discussi= on and=20
> analysis"
> of the idea, it's dishonest and toxic of you to portray it as = such as=20
> you
> should know better.

I'm sorry you've been unable to keep up with protocol developme= nt and
are confusing that for me being dishonest and toxic. May I suggest you
subscribe to the weekly Optech newsletter? It's free.

-Dave

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/1d532e88-d40a-4417-bdac-6c4bbf90c26en%40googlegroups.com.=
------=_Part_1061645_1801039998.1721781745387-- ------=_Part_1061644_1012886377.1721781745387--