From: Anthony Towns <aj@erisian•com.au>
To: John Carvalho <john@synonym•to>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Fri, 28 Oct 2022 03:21:53 +1000 [thread overview]
Message-ID: <Y1q+MedepB1qUpBP@erisian.com.au> (raw)
In-Reply-To: <CAHTn92wfjTCF5UtbjezbEYWTUQ7t6FNZu1ow0pirJXGFoXJxCA@mail.gmail.com>
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
next prev parent reply other threads:[~2022-10-27 17:22 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
2022-10-27 9:56 ` John Carvalho
2022-10-27 17:21 ` Anthony Towns [this message]
2022-10-27 17:35 ` Suhas Daftuar
2022-10-27 17:44 ` Greg Sanders
2022-10-27 19:00 ` Greg Sanders
2022-11-08 9:28 ` AdamISZ
2022-11-10 14:38 ` email
2022-11-03 21:06 email
2022-11-07 14:32 ` Peter Todd
2022-11-07 14:47 ` Erik Aronesty
2022-11-08 14:54 ` email
2022-11-09 12:05 ` email
-- strict thread matches above, loose matches on Subject: below --
2022-10-26 23:52 Anthony Towns
2022-10-27 12:36 ` Gloria Zhao
2022-10-27 15:37 ` Anthony Towns
2022-10-27 18:17 ` Luke Dashjr
2022-10-27 13:49 ` Greg Sanders
2022-10-27 15:00 ` Peter Todd
2022-10-27 20:29 ` Antoine Riard
2022-10-30 2:24 ` Anthony Towns
2022-10-29 7:45 ` David A. Harding
2022-10-30 1:02 ` Anthony Towns
2022-10-30 2:40 ` Anthony Towns
2022-10-30 11:06 ` email
2022-10-31 13:02 ` Suhas Daftuar
2022-10-31 16:25 ` Greg Sanders
2022-10-31 17:21 ` email
2022-10-31 17:51 ` Peter Todd
2022-11-04 10:28 ` email
2022-11-02 3:07 ` Anthony Towns
2022-11-02 13:32 ` Greg Sanders
2022-11-02 19:50 ` Antoine Riard
2022-11-05 2:35 ` Peter Todd
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=Y1q+MedepB1qUpBP@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=john@synonym$(echo .)to \
/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