Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 359B4C002D for ; Sun, 23 Oct 2022 23:10:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 0B00440180 for ; Sun, 23 Oct 2022 23:10:30 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0B00440180 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=MG1WEUUl X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5szHqQbAcmL for ; Sun, 23 Oct 2022 23:10:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5728840134 Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by smtp2.osuosl.org (Postfix) with ESMTPS id 5728840134 for ; Sun, 23 Oct 2022 23:10:28 +0000 (UTC) Received: by mail-il1-x135.google.com with SMTP id o2so1058059ilo.8 for ; Sun, 23 Oct 2022 16:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=so9hvh64tI+ZMIbTCL2I1dkWT7Yo8AwVD63c1xdDLrY=; b=MG1WEUUlc1wa/iBRDKa5Ap00KqM54Y6E/ueP78/7GfEQWyNbmhnF0XwYa7xW2VIc2X 28qboTgoFOzPUUhwpPVKuNUCDShcxhuI4ksMnQnDgS66Ms8VoIlVsSbAuFPJ6Hs1EQ5I MLuVzh5jK/Bu9BtmLozqX/7Sq52HnZBxepyAZsVO0ci6wFhfvqa68UXCClj1VRvL3wNY GSYGI5r5fUUyu73DPJf0MaCsfhA1MipI7oJIxXlYGvdjJbsUhbgRchP5BG9Jp6hVIPl2 LRkq2FSyw/Aq9vt99lUnsfJ4Tp3u8OLZ4sLEDUkuctrKOjDXecsMjCFfsCyROcVwIyp6 NgzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=so9hvh64tI+ZMIbTCL2I1dkWT7Yo8AwVD63c1xdDLrY=; b=Lvs0iSL94vmNeXyY4kP9T7cFWbIe0E95zJYq1SuFk0T07YtTWAY9jnhgOBqMSsVgF/ a3VDMJZaxMEIuTx1ec+/k2tf4hMsELI/W05I90bTxonrY/igu1dDjaqc7veHRkPokRWg 80+y6gXjmbkEJGIkzJfbtOVrkEubwoli+6PVtDFroAdSo8u7sOLOy5AUzMGO0/fs03fo WzulIRd/RXjjUqT5o62DOBqAyvzaPxCr5rsXKWDwBU70pNve63gVXvhHXWx3r2rLLeMz XXu14q7gQg+pvjs811xdt4JQpfxjgIL3MvYWb+P2pQXAXhjun5dZbmuthymqagC1/GOj lCTg== X-Gm-Message-State: ACrzQf1WpF2FOeUfntuzJPRMhRD/O6BwnyAjmfi8Fy6OtTnZYONtuW0X fniT6/N1Y+2aPZKqnTDnKQcPcfACtvwdhEX4ktc6CnGhkps= X-Google-Smtp-Source: AMsMyM4aRPgALLnUtaPkeSHrH/deXqO2YgazYUfmPlM3v3ilr8ioYV7yPRjaV0etgPZugQsVqu3OPKJRbukU7at08E0= X-Received: by 2002:a92:ca0d:0:b0:2fc:24a6:9115 with SMTP id j13-20020a92ca0d000000b002fc24a69115mr20629831ils.70.1666566627222; Sun, 23 Oct 2022 16:10:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Sun, 23 Oct 2022 19:10:16 -0400 Message-ID: To: Dario Sneidermanis Content-Type: multipart/alternative; boundary="000000000000cf6bd105ebbbc71a" X-Mailman-Approved-At: Sun, 23 Oct 2022 23:48:36 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Analysis of full-RBF deployment methods X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2022 23:10:30 -0000 --000000000000cf6bd105ebbbc71a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dario, Thanks for providing more thoughts to the discussion! > Notice that #26323 (option 5 in the OP) has the advantage of getting us to a > reliable full-RBF network the fastest (in particular, much faster than th= e > current opt-in deployment) while not threatening zero-conf applications > until > the activation time. That is, #26323 gives us a way in which we don't nee= d > to > choose between the security of one use case versus the other. We can have > both. For sure, contracting protocols and multi-party applications exposed by the lack of full-rbf are still young overall, though as they attract more volume they're also likely to become honeypots for any competing services providers interested to hijack economic traffic (kinda the same concern than channel jamming...) At the same time, we still have 0confs services more exposed by full-rbf, a bit stuck between Scylla and Charybdis. As commented on #26323, I'm personally fine with this approach, and I fully opine that providing a clear and predictable time point to 0confs operators is very valuable. Even more, I think May 1st 2023, is a bit too early, 10-12 months sounds more reasonable. At the same time, I believe it's the opinion of a few developers and other Bitcoin service operators that the Core project is taking too much responsibility in taking for the network by shipping full-rbf=3Dtrue. (Really I'm 50/50 between those 2 opinions, as I'm the author of both #26305 and #25600 and concept ACK on #26323, and any process forward would sounds good to me) > I don't think asking for a predictable deployment timeline for a change that > would put some applications at increased risk could be described as > burdening > the developers with solving every operational risk. This deployment metho= d > comparison's goal was precisely to soften the burden on core devs. I can understand the confusion here. As it has been discussed on your original thread, from my comprehension, the idea has been raised of a optech working group or something to build collaboration between wallet devs, merchant devs and protocol devs around "Bitcoin payment" issues like FX risk, additional layers of security for 0confs, RBF and CPFP, etc [0]. While again, I reassert that such a multi-stakeholder forum could be really fruitful for the ecosystem at large, I don't know if it should be a prerequisite that we solve all the potential payment issues before proceeding with full-rbf deployment. However I'm keeping aware about the interdependency between full-rbf and operational, legal and business issues that one encounters running a Bitcoin merchant/service, not easy to make everything works I can guess. [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021076= .html Best, Antoine Le ven. 21 oct. 2022 =C3=A0 17:13, Dario Sneidermanis a = =C3=A9crit : > Hello Antoine, > > Thanks for taking the time to answer every email with detailed analysis! = I > can > see it's a lot of work. I'll answer inline. > > On Thu, Oct 20, 2022 at 10:50 PM Antoine Riard > wrote: > > Personally, I still think deferring full-rbf deployment, while it sound= s > > reasonable to let existing services and applications adapt their > software and > > business models, doesn't come risk-free for the contracting protocols a= nd > > multi-party applications affected by the pinning DoS vector. Deferring = ad > > vitam aeternam left them exposed to disruptions when their traffic volu= me > > would start to be significant. While those use-cases > > (splicing/dual-channels/collaborative constructions) were mostly > vaporware a > > year ago when I raised the issue, it turns out they have become a far > more > > tangible reality today. Beyond the 3 coinjoins services > > (Wasabi/Joinmarket/Whirlpool), we have new things like ln-vortex, or > Phoenix > > wallet and some LDK users planning to use dual-funded soon. > > To solve the attack you described in [0], collaborative transaction > protocols > (such as dual-funded channels) need a *reliable* way to replace > transactions. > Otherwise, protocol parties using full-RBF may see replacements succeed i= n > their > own mempool, only to find out they weren't relayed to a miner once it's > too late > (ie. once the replacement that won is mined). > > I'm calling a full-RBF deployment reliable to the point at which any > full-RBF-enabled node can broadcast a replacement and get it relayed all > the way > to a miner in a reliable manner (ie. with high-enough probability). > > Even if we deployed opt-out (or mandatory!) full-RBF now and miners > adopted it > immediately, it would take almost a year (assuming normal deployment > times) for > it to be sufficiently deployed in the relaying layer to be considered > reliable. > An opt-in full-RBF deployment, as currently proposed (ie. without #25600)= , > has > very little chance of getting us nowhere near that kind of adoption. > > Notice that #26323 (option 5 in the OP) has the advantage of getting us t= o > a > reliable full-RBF network the fastest (in particular, much faster than th= e > current opt-in deployment) while not threatening zero-conf applications > until > the activation time. That is, #26323 gives us a way in which we don't nee= d > to > choose between the security of one use case versus the other. We can have > both. > > > I'm still looking forward to having more forums and communication > channels > > between business/services operators and protocol developers, it sounds > like > > functional responsibilities between protocol and application layers > could be > > better clarified. However, I don't know if it should be the > responsibility of > > developers to solve every operational risk encumbered by a Bitcoin > business, > > like FX risk. I don't deny the interdependency between network policy > rules > > and business risk, I'm just saying Bitcoin protocol developers have > already > > heavily loaded engineering priorities between solving the half of dozen > of > > Lightning vulnerabilities, working on the next consensus changes or > reviewing > > modularity refactoring of Bitcoin Core to extend the feature set in a > soft way > > (among tons of other examples). > > I don't think asking for a predictable deployment timeline for a change > that > would put some applications at increased risk could be described as > burdening > the developers with solving every operational risk. This deployment metho= d > comparison's goal was precisely to soften the burden on core devs. > > Cheers, > Dario > > [0] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033= .html > --000000000000cf6bd105ebbbc71a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dario,

Thanks for providing more thoughts to the= discussion!

> Notice that #26323 (option 5 in the OP) has the ad= vantage of getting us to a
> reliable full-RBF network the fastest (i= n particular, much faster than the
> current opt-in deployment) while= not threatening zero-conf applications
> until
> the activatio= n time. That is, #26323 gives us a way in which we don't need
> t= o
> choose between the security of one use case versus the other. We = can have
> both.

For sure, contracting protocols and multi-par= ty applications exposed by the lack of full-rbf are still young overall, th= ough as they attract more volume they're also likely to become honeypot= s for any competing services providers interested to hijack economic traffi= c (kinda the same concern than channel jamming...) At the same time, we sti= ll have 0confs services more exposed by full-rbf, a bit stuck between Scyll= a and Charybdis.

As commented on #26323, I'm personally fine wit= h this approach, and I fully opine that providing a clear and predictable t= ime point to 0confs operators is very valuable. Even more, I think May 1st = 2023, is a bit too early, 10-12 months sounds more reasonable.

At th= e same time, I believe it's the opinion of a few developers and other B= itcoin service operators that the Core project is taking too much responsib= ility in taking for the network by shipping full-rbf=3Dtrue.

(Really= I'm 50/50 between those 2 opinions, as I'm the author of both #263= 05 and #25600 and concept ACK on #26323, and any process forward would soun= ds good to me)

> I don't think asking for a predictable deplo= yment timeline for a change that
> would put some applications at inc= reased risk could be described as
> burdening
> the developers = with solving every operational risk. This deployment method
> compari= son's goal was precisely to soften the burden on core devs.

I ca= n understand the confusion here. As it has been discussed on your original = thread, from my comprehension, the idea has been raised of a optech working= group or something to build collaboration between wallet devs, merchant de= vs and protocol devs around "Bitcoin payment" issues like FX risk= , additional layers of security for 0confs, RBF and CPFP, etc [0]. While ag= ain, I reassert that such a multi-stakeholder forum could be really fruitfu= l for the ecosystem at large, I don't know if it should be a prerequisi= te that we solve all the potential payment issues before proceeding with fu= ll-rbf deployment. However I'm keeping aware about the interdependency = between full-rbf and operational, legal and business issues that one encoun= ters running a Bitcoin merchant/service, not easy to make everything works = I can guess.

[0] https://lists.linuxfoundation.org= /pipermail/bitcoin-dev/2022-October/021076.html

Best,
Antoine=

Le=C2=A0ven. 21 oct. 2022 =C3=A0=C2=A017:13, Dario Sneidermanis <dario@muun.com> a =C3=A9crit=C2=A0:
= Hello Antoine,

Thanks for taking the time to answer every email with= detailed analysis! I can
see it's a lot of work. I'll answer in= line.

On Thu, Oct 20, 2022 at 10:50 PM Antoine Riard <antoine.riard@gmail.com> wrote:
> Personally, I still think deferring full-rbf deployme= nt, while it sounds
> reasonable to let existing services and applica= tions adapt their software and
> business models, doesn't come ri= sk-free for the contracting protocols and
> multi-party applications = affected by the pinning DoS vector. Deferring ad
> vitam aeternam lef= t them exposed to disruptions when their traffic volume
> would start= to be significant. While those use-cases
> (splicing/dual-channels/c= ollaborative constructions) were mostly vaporware a
> year ago when I= raised the issue, it turns out they have become a far more
> tangibl= e reality today. Beyond the 3 coinjoins services
> (Wasabi/Joinmarket= /Whirlpool), we have new things like ln-vortex, or Phoenix
> wallet a= nd some LDK users planning to use dual-funded soon.

To solve the att= ack you described in [0], collaborative transaction protocols
(such as d= ual-funded channels) need a *reliable* way to replace transactions.
Othe= rwise, protocol parties using full-RBF may see replacements succeed in thei= r
own mempool, only to find out they weren't relayed to a miner once= it's too late
(ie. once the replacement that won is mined).

= I'm calling a full-RBF deployment reliable to the point at which anyfull-RBF-enabled node can broadcast a replacement and get it relayed all t= he way
to a miner in a reliable manner (ie. with high-enough probability= ).

Even if we deployed opt-out (or mandatory!) full-RBF now and mine= rs adopted it
immediately, it would take almost a year (assuming normal = deployment times) for
it to be sufficiently deployed in the relaying lay= er to be considered reliable.
An opt-in full-RBF deployment, as currentl= y proposed (ie. without #25600), has
very little chance of getting us no= where near that kind of adoption.

Notice that #26323 (option 5 in th= e OP) has the advantage of getting us to a
reliable full-RBF network the= fastest (in particular, much faster than the
current opt-in deployment)= while not threatening zero-conf applications until
the activation time.= That is, #26323 gives us a way in which we don't need to
choose bet= ween the security of one use case versus the other. We can have both.
> I'm still looking forward to having more forums and communicatio= n channels
> between business/services operators and protocol develop= ers, it sounds like
> functional responsibilities between protocol an= d application layers could be
> better clarified. However, I don'= t know if it should be the responsibility of
> developers to solve ev= ery operational risk encumbered by a Bitcoin business,
> like FX risk= . I don't deny the interdependency between network policy rules
>= and business risk, I'm just saying Bitcoin protocol developers have al= ready
> heavily loaded engineering priorities between solving the hal= f of dozen of
> Lightning vulnerabilities, working on the next consen= sus changes or reviewing
> modularity refactoring of Bitcoin Core to = extend the feature set in a soft way
> (among tons of other examples)= .

I don't think asking for a predictable deployment timeline for= a change that
would put some applications at increased risk could be de= scribed as burdening
the developers with solving every operational risk.= This deployment method
comparison's goal was precisely to soften th= e burden on core devs.

Cheers,
Dario

[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/= 2021-May/003033.html
--000000000000cf6bd105ebbbc71a--