From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9745CC002D for ; Tue, 6 Dec 2022 05:04:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 47C87408F3 for ; Tue, 6 Dec 2022 05:04:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 47C87408F3 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm1 header.b=U5JzXVsL X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 SRbRSdk8h3OC for ; Tue, 6 Dec 2022 05:04:03 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D935C408F0 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by smtp4.osuosl.org (Postfix) with ESMTPS id D935C408F0 for ; Tue, 6 Dec 2022 05:04:02 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9F0F132009E2; Tue, 6 Dec 2022 00:03:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 06 Dec 2022 00:03:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1670303039; x=1670389439; bh=cEsngTJaKs41bwoQgEsItdh0GvmI WduEkXaxxnO3WGI=; b=U5JzXVsLsjKPPpQSmgh1fTT+317J1BO3EpA4dXNNZ4VC d96Q7Cl9ipne3XZKKngbGMvIAjLjGUSnUksLYfqFR4W3Y2+3F6VZmyc7eo8dpQnG cy2e65h6WWv/PREU9UdVdIWfg7SN3Hs26XMRd/g1wGpw/HVujYf+ikfj6ITKOarG VAmI5jPJlPwfjFe9/veZ4pGYqk3aFjKaPExvs7jMDijzCQ9Ivipw0d3x/Si/kzo+ 5ujURckS56j0FZ5mbD1oJaXW5+IDBI0/Qawzvhw1Ajc/DImDKcKJfFRbKptp5nAm jFsaaXWIW9HC7bEI81vN5OJXg0WsxKyPRk3iROegQw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgvrhcu vfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtthgvrh hnpeduvdetjeeiiefhvdehueeiuedvgefgtddtffdvtdffvdetheelleejgeduhfdvteen ucffohhmrghinheplhhinhhugihfohhunhgurghtihhonhdrohhrghdpphgvthgvrhhtoh guugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehpvghtvgesphgvthgvrhhtohguugdrohhrgh X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Dec 2022 00:03:58 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 9645E5F83F; Tue, 6 Dec 2022 00:03:56 -0500 (EST) Date: Tue, 6 Dec 2022 00:03:56 -0500 From: Peter Todd To: Antoine Riard , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EUnx+iPq6XGs1tpV" Content-Disposition: inline In-Reply-To: Subject: Re: [bitcoin-dev] Fwd: [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: Tue, 06 Dec 2022 05:04:05 -0000 --EUnx+iPq6XGs1tpV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2022 at 05:35:39PM -0500, Antoine Riard via bitcoin-dev wro= te: > To recall, the original technical motivation of this option, and the wider > smoother deployment was to address a DoS vector affecting another class of > use-case: multi-party transactions like coinjoin and contracting protocols > like Lightning [2] [3]. All of them expect to generate economic flows and > corresponding mining income. Since then, alternative paths to solve this > DoS vector have been devised, all with their own trade-offs and conceptual > issues [4] [5]. > [4] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/0211= 35.html > [5] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021= 144.html To be clear, these alternative paths all negatively impact privacy as they'= re creating yet more ways for bad actors such as Chainalysis to deanonymize transactions. We have a fundamental political tradeoff between the few centralized services trying to accept unconfirmed txs, and the huge number = of users - everyone else - who desires privacy. A big part of the promise of taproot was that we'd be able to eventually greatly improve the anonymity set of all transactions by making multi-party transactions indistinguishable from any other transaction. That's a huge pa= rt of why the community fought for taproot adoption. Your proposal [5] that multi-party protocols use a different nVersion to si= gnal full-rbf in their txouts negates that anonymity set for the obvious reason = that single-party wallets are discouraged from using it by the fact that a few services like Bitrefill complain about RBF transactions. Indeed, since nVersion=3D3 transactions are non-standard, we additionally have the proble= m that many more wallets won't even see such payments until a confirmation, or in = some cases due to bugs, never. Worse, this trade-offs is fundamental: it is impossible to design such a protocol without harming privacy. Why? Let's assume such a protocol was possible. To be compatible with how unconfirmed txs are accepted today the protocol would have to have the following two simultaneous properties: 1) Zeroconf services would need to be able to inspect the tx data and deter= mine whether or not the txout had opted into full-rbf. 2) Chainalysis services would need to be unable to inspect the tx data and determine whether or not the txout had opted into full-rbf. This is an obvious contradiction, and the only alternative of commit-reveal schemes is ridiculous and would *itself* create yet another privacy impact.= We do not need any further technical debate on this issue: this is a political tradeoff between a few centralized services and all other users that needs = to be decied by the community. No different than the blocksize wars. The v3 proposal Suhas mentions in [4] has similar privacy issues: again we'= re forcing a class of multiparty protocols to create transactions that are cle= arly identified as being multiparty. In this case the privacy impact isn't as st= ark, because the common case of cooperative actions in Lightning can use v2 transactions. But this is still a privacy impact that could be avoided by better mempool design. Eg as I showed in: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/02117= 5.html --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --EUnx+iPq6XGs1tpV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmOOzS8ACgkQLly11TVR LzdqCQ//XiqczJAFJO49aRIbpUcpP3HBHgNY6fv4GbvWczle5BnA0YvYupvlAaXz uOoUIoLGdUUyv3paHoaJ+ZiQ2vt8sgalSI1PVE18DKqmWNONMo3Ub8707qpLQ5ey WHOOQe/efckw9RufXQ0TqMYN7MIJ3z9d3SxGtM9Xv/sHsgtE94dOT71DIpU9wYcl zKOEaI9lfLSHf8k5BpR+CDqmMaz7/xBUsy0RVoevbOXsXDf8VR9GOj3cNlfXZ88J XkMLpyMLH6gxZgJwxoBpN2YtZ9HUgFQ671D+XN6JISEIElIZT6DEudlrF/aJxOoh qFsm+/50WtZOjAXJjahA61BDPN5D7rP/upQdPA+KB2Xb2GN8Ti5ghFldLZR0OCK/ N69jTRtWCjBVdJIHYq3ggVsWriqtFHzx3UQvEHa4MAo5Yvwi49d76Nn4K/LAVhXd 4PPE1cx4mskJXl2lGT9ta70Yxl9UGPXEYPqgBOz+5IpugCe4dzwQxdaLepgDZ4I3 z/25eznrj3U2lXEr3pMr4ad4xqxi7K5mQa0IFU1G90D8GZGtIBegpo+TY9JMV/YQ Jp1Mirft6r1hm0TWLFigwhx3OcnXQkqXYWBxC1YnxuCZ19TQXOAAhSSmmRgmgsjA o4tLoUGi9sqkPPmNuUHzudsquKsSQhKYfhGhLRJ0V1A8G31ZBEg= =t5U1 -----END PGP SIGNATURE----- --EUnx+iPq6XGs1tpV--