From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B61D4C002D for ; Wed, 2 Nov 2022 15:05:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 90C728143F for ; Wed, 2 Nov 2022 15:05:10 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 90C728143F Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=HLUEuyJW 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUrQqz3RI2JU for ; Wed, 2 Nov 2022 15:05:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 57E3A81443 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.osuosl.org (Postfix) with ESMTPS id 57E3A81443 for ; Wed, 2 Nov 2022 15:05:09 +0000 (UTC) Date: Wed, 02 Nov 2022 15:04:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1667401506; x=1667660706; bh=3DAnxQIhdxQDXDNFUlYAykUa5606zATrhokL6hIT92I=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=HLUEuyJWpxuXgAx4YWjaNBHThUNKgM/MGZYVLCSUFWIdu02zt/He5vwnU8sXdfZZ9 Me6cf0YfeN8CDZJ8eZRGJMuPasBoxWG9XJjvbAFQdWlDieMJ7Lyg/0hCQrSHXP771p hHiqzKh70wBdYGx7EacBo7qVAYGALYAj1Nqaf3iMeAXN7fwnzmoRz+/xTJbUOa22o/ 4Fat2whF3TmzunFiAv9f4xpmJCjSs3O3hI5NsX6yhK2rDUt4JGH4MzZY5XEbADHf+x My8eN0i9epRZsFSDHCrPpK0j1qDhJVlT4g0PC6DXJNmnFlGsJYZ2WT35uLUhPBqxQh xSdHYPoaQQjLg== To: Peter Todd , Bitcoin Protocol Discussion From: AdamISZ Message-ID: In-Reply-To: References: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net> Feedback-ID: 11565511:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 02 Nov 2022 15:23:18 +0000 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, 02 Nov 2022 15:05:10 -0000 ------- Original Message ------- On Thursday, October 20th, 2022 at 23:08, Peter Todd via bitcoin-dev wrote: > On Wed, Oct 19, 2022 at 03:17:51AM +0000, alicexbt via bitcoin-dev wrote: >=20 > > > And the > > > impression I got from the PR review club discussion more seemed like > > > devs making assumptions about businesses rather than having talked to > > > them (eg "[I] think there are fewer and fewer businesses who absolute= ly > > > cannot survive without relying on zeroconf. Or at least hope so"). > >=20 > > Even I noticed this since I don't recall the developers of the 3 main c= oinjoin implementations that are claimed to be impacted by opt-in RBF makin= g any remarks. >=20 >=20 > FYI I personally asked Max Hillebrand from Wasabi about full-rbf last nig= ht. > He gave me permission to republish our conversation: >=20 > > Hey, I wanted to know if you had any comments on full-rbf re: wasabi? >=20 >=20 > Doesn't really affect us, afaik > The cj doesn't signal rbf right now > And I guess it's a DoS vector if any input double spent will be relayed a= fter successful signing > But we have way bigger / cheaper DoS vectors that don't get "exploited" > So probably doesn't matter > Wasabi client handles replacements / reorgs gracefully, so should be alri= ght > We don't yet "use" rbf in the sense of fee bumping tx, but we should / wi= ll eventually >=20 > I haven't asked Joinmarket yet. But the impact on their implementation sh= ould > be very similar. >=20 Hi Peter, Re: Joinmarket Yes, it's largely as you would expect. First, we did not ever signal opt-in= RBF in coinjoins (it'd be nice if we had CPFP as a user-level tool in the = wallet, to speed up low fee coinjoins, but nobody's done it). Second, yes we have DOS vectors of the trivial kind based on non-protocol-c= ompletion (signatures) and RBF would be another one, I don't think it chang= es our security model at all really (coinjoins being atomic, intrinsically)= . Nothing in the logic of the protocol relies on unconfirmed txs. Maker *ma= y* reannounce offers when they see broadcast but it's probabilistic (depend= s on distribution of funds in (BIP32) accounts), and they do / do not reann= ounce anyway for various reasons (reconnections on different message channe= ls, confirmation of a coinjoin). We should probably take a new look at it i= f this becomes the norm but there shouldn't be any security issue. Cheers, AdamISZ/waxwing