From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not
Date: Tue, 23 Jul 2024 17:42:25 -0700 (PDT) [thread overview]
Message-ID: <1d532e88-d40a-4417-bdac-6c4bbf90c26en@googlegroups.com> (raw)
In-Reply-To: <6c222c758e10e8061ccdcc180b1826a3@dtrt.org>
[-- Attachment #1.1: Type: text/plain, Size: 5413 bytes --]
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 bitcoin
core code available for a robust imbuanche mechanism, so this whole roadmap
thing you're presenting 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 hash: a75c98ab5166c541ecba5e579639f359e82ff315df89b04264b29f8dfaa87502
Le lundi 22 juillet 2024 à 23:10:33 UTC+1, David A. Harding a écrit :
> 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-specification-call/
>
> I'm aware of three discussions about it on the Delving Bitcoin Forum:
>
> -
>
> https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/2
> -
>
> https://delvingbitcoin.org/t/sibling-eviction-for-v3-transactions/472#benefits-1
> - (as previously linked)
>
> https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-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
> anchors
> will allow the CPFP carve-out rule to be removed, which is necessary
> 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
> 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
> transactions
> (see Newsletter #286 for the underlying imbued v3 proposal)."
>
>
>
> https://bitcoinops.org/en/newsletters/2024/02/14/#what-would-have-happened-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
> 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
> > analysis"
> > of the idea, it's dishonest and toxic of you to portray it as such as
> > 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
>
--
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/1d532e88-d40a-4417-bdac-6c4bbf90c26en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10651 bytes --]
next prev parent reply other threads:[~2024-07-24 0:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:56 [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
2024-07-18 23:04 ` [bitcoindev] " Antoine Riard
2024-07-19 1:05 ` Peter Todd
2024-07-19 13:52 ` Antoine Riard
2024-07-19 14:38 ` Peter Todd
2024-07-19 23:58 ` Antoine Riard
2024-07-20 0:46 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-21 2:06 ` Antoine Riard
2024-07-21 20:17 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-22 1:59 ` 'Anonymous User' via Bitcoin Development Mailing List
2024-07-24 0:44 ` Antoine Riard
2024-07-24 0:35 ` Antoine Riard
2024-07-19 12:41 ` /dev /fd0
2024-07-19 23:56 ` Antoine Riard
2024-07-20 5:57 ` /dev /fd0
2024-07-20 15:08 ` Peter Todd
2024-07-21 2:13 ` Antoine Riard
2024-07-21 6:16 ` /dev /fd0
2024-07-21 2:12 ` Antoine Riard
2024-07-19 18:26 ` [bitcoindev] " Murch
2024-07-20 14:10 ` Peter Todd
2024-07-20 6:41 ` David A. Harding
2024-07-20 15:03 ` Peter Todd
2024-07-20 15:30 ` Peter Todd
2024-07-21 15:35 ` David A. Harding
2024-07-21 20:25 ` Peter Todd
2024-07-24 0:38 ` Antoine Riard
2024-07-21 2:10 ` Antoine Riard
2024-07-22 15:10 ` Peter Todd
2024-07-24 0:41 ` Antoine Riard
2024-07-22 11:45 ` [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Peter Todd
2024-07-22 16:43 ` David A. Harding
2024-07-22 20:06 ` Peter Todd
2024-07-22 22:08 ` David A. Harding
2024-07-23 11:29 ` Peter Todd
2024-07-24 0:42 ` Antoine Riard [this message]
2024-07-22 17:13 ` [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d532e88-d40a-4417-bdac-6c4bbf90c26en@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox