Feedback-ID: i525146e8:Fastmail
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
Precedence: list


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