Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 892B8C002D for ; Wed, 12 Oct 2022 16:11:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4FBEE410C0 for ; Wed, 12 Oct 2022 16:11:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4FBEE410C0 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=wuille.net header.i=@wuille.net header.a=rsa-sha256 header.s=protonmail3 header.b=ak8zxqNn X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNudvrLdRVKs for ; Wed, 12 Oct 2022 16:11:23 +0000 (UTC) X-Greylist: delayed 23:52:57 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org F3F3C409FE Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21]) by smtp4.osuosl.org (Postfix) with ESMTPS id F3F3C409FE for ; Wed, 12 Oct 2022 16:11:22 +0000 (UTC) Date: Wed, 12 Oct 2022 16:11:05 +0000 Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=wuille.net header.i=@wuille.net header.b="ak8zxqNn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail3; t=1665591069; x=1665850269; bh=58eYscuIZr3S6zYRY3jhajOC2sSSlCnbgxKZjH1PVvU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=ak8zxqNnAKhhHe4bqu6UC67PeaZnsx4xe4al9a0aMBjGrWJBb0XTH5Qeh9UwP7Y9+ z5ISsLq6QjwjYEpBEz+UNmijuiZiO164aZjL8xGv7Sye+aTL+Lc6gZxLCYZbIMLcw7 JUPhSSbhapnb2Wv+nO/X/TP09Ee8iKNlPN+AT/nvWVVBfMq5ftt9kajzopV7xbi4Zg Qw7xLN87QPep5IyXHTfkDQieHxmOI1Z/mKIl6HSfNBxDyw/3CojaAoLYRfkNIUpDmo lJdK4ORyofgoFgTSqD/+Q8HqFBJVDJ4UQ7749LyIVTFkCrbUTB/DIC4yW6qHz6m6A7 rK9nzv61O7mnQ== To: Anthony Towns From: Pieter Wuille Message-ID: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net> In-Reply-To: References: Feedback-ID: 19463299:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 12 Oct 2022 17:51:40 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 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: Wed, 12 Oct 2022 16:11:25 -0000 On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns wrote: > On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev w= rote: >=20 > > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin= -dev bitcoin-dev@lists.linuxfoundation.org wrote: > >=20 > > > Thanks for the fast answer! It seems I missed the link to the PR, sor= ry for the > > > confusion. I'm referring to the opt-in flag for full-RBF from #25353 > > > (https://github.com/bitcoin/bitcoin/pull/25353). > > > It is not clear to me why you believe the merging of this particular = pull request poses an immediate risk to you. >=20 >=20 > Did you see the rest of Dario's reply, bottom-posted after the quoted > text? Namely: Oh, my mail client for some reason chose to hide all that. Dario, I'm sorry= for missing this; I see now that you were certainly aware of what the PR u= nder consideration did. Further comments inline. > On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via > > The question then is whether an opt-in flag for full-RBF will have enou= gh > > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its > > objective of allowing nodes participating in multi-party funding protoc= ols > > to assume that they can rely on full-RBF. If it is, then zero-conf appl= ications > > will be at severe risk (per the logic in the initial email). >=20 >=20 > That logic seems reasonably sound to me: >=20 > - if adding the option does nothing, then there's no point adding it, > and no harm in restricting it to test nets only >=20 > - if adding the option does do something, then businesses using zero-conf > need to react immediately, or will go from approximately zero risk of > losing funds, to substantial risk >=20 > (I guess having the option today may allow you to manually switch your > node over to supporting fullrbf in future when the majority of the networ= k > supports it, without needing to do an additional upgrade in the meantime; > but that seems like a pretty weak benefit) I certainly recognize that adding the flag is a likely step towards, over t= ime, the full RBF policy becoming more widely adopted on the network. That = is presumably the reason why people are in favor of having the flag, even d= efault off - including me. I believe that policy's adoption is inevitable e= ventually, but the speed at which that is achieved is certainly a function = of availability and adopted of software which provides the option. That said, I think it's a bit of a jump to conclude that the only two optio= ns are that either the existence of the flag either has no effect at all, o= r poses an immediate threat to those relying on its absence. In my view, it= is just what I said: a step towards getting full RBF on the network, by al= lowing experimentation and socializing the notion that developers believe i= t is time. So I have a hard time imagining how it would change anything *im= mediately* on the network at large (without things like default on and/or p= referential peering, ...), but I still believe it's an important step. Cheers, --=20 Pieter