1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 79F44C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2022 17:22:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 4CCCF401C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2022 17:22:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4CCCF401C9
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 81sqA-wl9RxA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2022 17:22:04 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2EBAA400C4
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp2.osuosl.org (Postfix) with ESMTPS id 2EBAA400C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2022 17:22:04 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1oo6Zr-00044t-8V; Fri, 28 Oct 2022 03:22:01 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 28 Oct 2022 03:21:53 +1000
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>
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] On mempool policy consistency
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Oct 2022 17:22:05 -0000
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
|
