Date: Fri, 28 Oct 2022 03:21:53 +1000
From: Anthony Towns <aj@erisian.com.au>
To: John Carvalho <john@synonym.to>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y1q+MedepB1qUpBP@erisian.com.au>
References: <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92wfjTCF5UtbjezbEYWTUQ7t6FNZu1ow0pirJXGFoXJxCA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHTn92wfjTCF5UtbjezbEYWTUQ7t6FNZu1ow0pirJXGFoXJxCA@mail.gmail.com>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Precedence: list

On Thu, Oct 27, 2022 at 11:56:45AM +0200, John Carvalho via bitcoin-dev wrote:
> I took the time to read your whole post. Despite a diplomatic tone, I find
> your takeaways from all your references to remain conveniently biased for
> protecting the plan of RBF

Yes, I am heavily biased against zeroconf: there's no way I'd personally
be willing to trust it for my own incoming funds, no matter how much
evidence you show me that it's safe in practice. Show me a million
transactions where every single one worked fine, and I'm still going to
assume that the payment going to me is going to be the one that makes
the error rate tick up from 0% to 0.0001%. That's okay; just because I
wouldn't do something, doesn't mean other people shouldn't.

It does mean I'm not going to be a particularly good advocate for zeroconf
though. I mean, I might still be a fine advocate for giving people time
to react, making it clear what's going on, finding ways that might make
everyone happy, or just digging it to random technical details; but,
for me, I'm more interested in a world where chargebacks are impossible,
not where we just make the best of what was possible with technology
from five or ten years ago.

But that's fine: it just means that people, like yourself, who will
tolerate the risks of zeroconf, should be involved in the discussion.

> You show multiple examples where, when I read them, I assume the next thing
> you will say will be "so we really should stop trying to impose optional
> features, particularly when they affect existing use cases" but instead you
> persist.

Sure, that's natural: you read a sign saying "you can have any ice cream
you want for 5c" and think "Awesome, who wouldn't want cheap chocolate
ice cream!!" and see me going for a Golden Gaytime and think "wtf dude".
Different strokes.

For me, I see the gmaxwell github comment I quoted saying:

  There is also a matter of driving competent design rather than lazy
  first thing that works.

and think "yeah, okay, maybe we should be working harder to push lightning
adoption, rather than letting people stick with wallet UX from 2015"
and have altcoins take over >50% of payment volume.

Likewise,

  There is also a very clear pattern we've seen in the past where
  people take anything the system lets them do as strong evidence that
  they have a irrevocable right to use the system in that way, and that
  their only responsibility-- and if their usage harms the system it's
  the responsibility of the system to not permit it.

seems a pretty good match against your claim "I expect the things I do
with Bitcoin today to work FOREVER." Better to nip that thinking in the
bud; and even if the best time to do that was years ago, the second best
time to do it is still now.

By contrast, from the same post, I'd guess you're focussing on:

  Network behavior is one of the few bits of friction
  driving good technical design rather than "move fast, break things, and
  force everyone else onto my way of doing thing rather than discussing
  the design in public".

and thinking "yeah, move fast, break things, force everyone else --
that's exactly what's going on here, and shouldn't be".

But that's also okay: even when there is common ground to be found,
sometimes it requires actual work to get people who start from different
views to get there.

> The problem is that RBF has already been an option for years, and anyone
> that wants to use it can.

Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid
a DoS issue when utxos are jointly funded by untrusting partners, and,
aiui, that's the main motivation for addressing this now.

[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

The scenario he describes is: A, B, C create a tx:

  inputs: A1, B1, C1 [opts in to RBF]
  fees: normal
  outputs:
    [lightning channel, DLC, etc, who knows]

they all analyse the tx, and agree it looks great; however just before
publishing it, A spams the network with an alternative tx, double
spending her input:

  inputs: A1 [does not opt in to RBF]
  fees: low
  outputs: A

If A gets the timing right, that's bad for B and C because they've
populated their mempool with the 1st transaction, while everyone else
sees the 2nd one instead; and neither tx will replace the other. B and
C can't know that they should just cancel their transaction, eg:

  inputs: B1, C1 [opts in to RBF]
  fees: 50% above normal
  outputs:
    [smaller channel, refund, whatever]

and might instead waste time trying to fee bump the tx to get it mined,
or similar.

What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?

If you're right that opt-in RBF is enough, that question has a good
answer. I don't believe anyone's presented an answer to it in the 17
months since Antoine raised the concern.

> passive aggression
> escalation
> unfair advantage
> oppressive, dark-pattern design
> strong-arming and shoe-horning

Do you really think any of that was helping your cause?

Cheers,
aj