Re: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]

On Fri, Dec 02, 2022 at 05:35:39PM -0500, Antoine Riard via bitcoin-dev wrote:
> 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/021135.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.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 part
of why the community fought for taproot adoption.

Your proposal [5] that multi-party protocols use a different nVersion to signal
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=3 transactions are non-standard, we additionally have the problem 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 determine
   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 clearly
identified as being multiparty. In this case the privacy impact isn't as stark,
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/021175.html

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]