Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E9725C002D for ; Fri, 21 Oct 2022 21:13:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B01D660E6B for ; Fri, 21 Oct 2022 21:13:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B01D660E6B Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=muun-com.20210112.gappssmtp.com header.i=@muun-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=bXgJ+t6B X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8qJ84dPF0u5 for ; Fri, 21 Oct 2022 21:13:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 47998605A6 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by smtp3.osuosl.org (Postfix) with ESMTPS id 47998605A6 for ; Fri, 21 Oct 2022 21:13:54 +0000 (UTC) Received: by mail-wr1-x430.google.com with SMTP id a14so4035744wru.5 for ; Fri, 21 Oct 2022 14:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muun-com.20210112.gappssmtp.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=0rWnS0gjVo/IMXAZhIRT9c66/lSDkY0IXtUN5KA9tqw=; b=bXgJ+t6BcxDZwLxT776h7rSuGivBp2qKNMCNRZjsy4GL/JxTJd1sMOkRJeJj21xFIC 9qrBxoeRkQwLc9XDoZJJVqvKUpWXtWUeisbfiu1WXTBWnzeIknq+NSIBBkZY8uDSuDza P8ULyiLArYoRCfYbXXU32UOUeHEF61YjvCDgzNfqfq26/GgoTTVyflmotbHcgWanHjLx 8xE5Te2GRe1H6pzbMoDFUkPOLOBAhLacBXV+5umBLNzcRsriGp1p8uKP+Q37lNIrCh7K m0fSOXY+15rnI33w+mkSnns2AfNlaUunfYi5tepgm42LoQ/ijz3JCcjNCNHjIXYWT0g4 COBQ== 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=0rWnS0gjVo/IMXAZhIRT9c66/lSDkY0IXtUN5KA9tqw=; b=oWWOh/QvZydGWTtScAiDW824gAbprLXNP9ApGfYAzT7UDaDdp8Ceg6Fy0dC71w+b5z O7TSMJBuz4gr+wLbvgXCLAbHsJUqPjwDXUFXzUlbEBLka+Q8awdqwT2tgk+75deCbBgJ LEsrJkn6PKeYD+bt8ZqSl1VLMel4KGBD6+okoYKY0lfU022bWzAu/jmIRHkJ1aNscWQi Lw9X2FghINJjOdyA/ejx4avplVBDKU8NsYrCgMhKV2yybq75szgQggZOUh6UiU5rvmys enLh/0vsUYJ4pJjmzzTUwMLpGWmvAhuAgHQF4VsvCcqAIjDa/BO+njzHvmO9K/uiuky5 ojfQ== X-Gm-Message-State: ACrzQf20eRzNiYWgpxHwUCnyYz7NpAzBs7hDT2Yxt/J6DfDNvJFFFSHH U5zrBdLp8SR2KGEfxtvnvKrP2eu4USdedgrcpAqQ5PDo7eIeRw== X-Google-Smtp-Source: AMsMyM6UB0kXiQpL3yPotuMrxnIH0L8A+ggAH8/0FoRD3laufvP7wG/JdxYrJKo1NXKecvuwe3M1Uk6UQD855j5tjhk= X-Received: by 2002:a05:6000:1a85:b0:230:f238:a48c with SMTP id f5-20020a0560001a8500b00230f238a48cmr13141032wry.92.1666386832384; Fri, 21 Oct 2022 14:13:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dario Sneidermanis Date: Fri, 21 Oct 2022 18:13:41 -0300 Message-ID: To: Antoine Riard Content-Type: multipart/alternative; boundary="00000000000033fe0605eb91eb7f" X-Mailman-Approved-At: Fri, 21 Oct 2022 21:43:02 +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: Fri, 21 Oct 2022 21:13:56 -0000 --00000000000033fe0605eb91eb7f Content-Type: text/plain; charset="UTF-8" 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 sounds > reasonable to let existing services and applications adapt their software and > business models, doesn't come risk-free for the contracting protocols and > multi-party applications affected by the pinning DoS vector. Deferring ad > vitam aeternam left them exposed to disruptions when their traffic volume > 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 in 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 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 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 method 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 --00000000000033fe0605eb91eb7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 Riar= d <antoine.riard@gmail.com> wrote:
> Personally, I still think deferring full-rbf deploymen= t, while it sounds
> reasonable to let existing services and applicat= ions adapt their software and
> business models, doesn't come ris= k-free for the contracting protocols and
> multi-party applications a= ffected by the pinning DoS vector. Deferring ad
> vitam aeternam left= them exposed to disruptions when their traffic volume
> would start = to be significant. While those use-cases
> (splicing/dual-channels/co= llaborative 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 an= d some LDK users planning to use dual-funded soon.

To solve the atta= ck you described in [0], collaborative transaction protocols
(such as du= al-funded channels) need a *reliable* way to replace transactions.
Other= wise, protocol parties using full-RBF may see replacements succeed in 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 th= e 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 miner= s adopted it
immediately, it would take almost a year (assuming normal d= eployment times) for
it to be sufficiently deployed in the relaying laye= r to be considered reliable.
An opt-in full-RBF deployment, as currently= proposed (ie. without #25600), has
very little chance of getting us now= here near that kind of adoption.

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 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 betw= een 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 develope= rs, 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 eve= ry 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 alr= eady
> heavily loaded engineering priorities between solving the half= of dozen of
> Lightning vulnerabilities, working on the next consens= us changes or reviewing
> modularity refactoring of Bitcoin Core to e= xtend 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 des= cribed as burdening
the developers with solving every operational risk. = This deployment method
comparison's goal was precisely to soften the= burden on core devs.

Cheers,
Dario

[0] ht= tps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.htm= l
--00000000000033fe0605eb91eb7f--