path: root/a4/f5e23559d5135b770fc7ab8eda67a8e0905b30

Return-Path: <pete@petertodd.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9745CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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: <xms:Ps2OYydlI74XTe3a8GpS860Dfh1VKfR3C9xCP4osXJ5JI0sjLao7_g>
 <xme:Ps2OY8M33RtdRy93DaFOnIf9lYc_IYqLqA789qkdLtAW-768SAIisrkfiy9lnkfEW
 IWb0TT4bTT5C6-ckuw>
X-ME-Received: <xmr:Ps2OYzhIbhaIt4WN8CL-b6kpAFiIwI6RfsqznZm7xvYffX4Zxzi25AWGMCE2>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehgdejlecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgvrhcu
 vfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtthgvrh
 hnpeduvdetjeeiiefhvdehueeiuedvgefgtddtffdvtdffvdetheelleejgeduhfdvteen
 ucffohhmrghinheplhhinhhugihfohhunhgurghtihhonhdrohhrghdpphgvthgvrhhtoh
 guugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
 ohhmpehpvghtvgesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:Ps2OY_97WgraH_V1fJSvNBc-PnXAG_6b3Yl6yUmSWCc1lwsEjfC6cQ>
 <xmx:Ps2OY-upRWEMSgKSM_bYciBw5ZeNoe1TdoXHreEzWvOX0vlPq6FD_g>
 <xmx:Ps2OY2EX3fBAcNk9u3s3DGVcLnPKUbuUt1uJ6fPDEIrd_qebjqmiLw>
 <xmx:P82OYyKosuPCJwqnVRqjWM2EiZIHo9e9s_FDazdOd0eSfxQYg8PFkg>
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 <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y47NPO4fscqZl8hr@petertodd.org>
References: <CACkWPs8-rZpGSJSEyLsg9gVAuPpHztXWSZvfGscGJCn05th0DQ@mail.gmail.com>
 <CALZpt+GnTE+LMSMHVt-E7Uq0FeuqrSKyr1m9OJa_yKkh6MrgzA@mail.gmail.com>
 <CALZpt+HFFwY4XECNZj3XLqnaumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="EUnx+iPq6XGs1tpV"
Content-Disposition: inline
In-Reply-To: <CALZpt+HFFwY4XECNZj3XLqnaumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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].

<snip>

> [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--