public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Antoine Riard <antoine.riard@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling
Date: Wed, 2 Nov 2022 10:04:03 -0400	[thread overview]
Message-ID: <Y2J40/Cd40fUlFjj@petertodd.org> (raw)
In-Reply-To: <CALZpt+GZAd-vYMzUMicg0c9OyyWExtT5EH61Hms6NNOM19ddZA@mail.gmail.com>

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

On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev wrote:
> Hi list,
> 
> Reading Suhas's post on mempool policy consistency rules, and the grounded
> suggestion that as protocol developers we should work on special policy
> rules to support each reasonable use case on the network rather to arbiter
> between class of use-cases in the design of an
> unified set of rules, reminded me there is another solution to solve
> multi-party funding pinning rather than wide deployment of fullrbf. This
> was communicated to me a while back, and it was originally dismissed
> because of the privacy trade-offs (and potential slight fees overhead
> cost). However, if widely adopted, they might sound acceptable to
> contracting protocol developers and operators.

Strong NACK.

Zeroconf is, at best, a very marginal usecase. The only services that have
spoken up in support of it are Bitrefill and Muun, and the latter says they're
working to get rid of their vulnerability to it. People attempting to make it
secure have repeatedly done sybil attacks against the network in attempts to
measure transaction propagation. And of course, if transaction fees and full
mempools are in our near future - as is widely expected - mempool consistency
will even further diminish making zeroconf even harder to achieve.

Incurring a bunch of engineering costs and harming privacy for the sake of
continuing this nonsense is ridiculous.

If anything, we should be moving to full-RBF so we can undo the privacy cost
that is opt-in-RBF: right now 30% of transactions are having to harm their
privacy by signalling support for it. Full-RBF will allow that wallet
distinguisher to be eliminated.

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

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

  parent reply	other threads:[~2022-11-02 14:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02  2:21 Antoine Riard
2022-11-02 13:58 ` Greg Sanders
2022-11-02 14:04 ` Peter Todd [this message]
2022-11-02 14:19   ` Greg Sanders
2022-11-02 14:33     ` Peter Todd
2022-11-02 15:00       ` Greg Sanders

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y2J40/Cd40fUlFjj@petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=antoine.riard@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox