summaryrefslogtreecommitdiff
path: root/d1/bfb1dc22d4f6ef4fecf3dbca0eca5c123253eb
blob: d20622e37e8d4f43db341b3a9d13d60fa28b14ef (plain)
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
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C2EABC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:33:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A991741626
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:33:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A991741626
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=WUzmXsJw
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id QNzxXhbXJhUq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:33:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7A4B341621
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [IPv6:2a00:1450:4864:20::52c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7A4B341621
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:33:02 +0000 (UTC)
Received: by mail-ed1-x52c.google.com with SMTP id z18so21463244edb.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 02 Nov 2022 06:33:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=jHFAmX7UngdKyooHP5toYd51Ywma3v51WwT3jy7CPho=;
 b=WUzmXsJwpVqNhWMUFnomzTxsqs1Tien01POmJ4kAcPMUbbYEA9si5bCSdZbPyAJZ5h
 0nMoTOABuS00/k7K4y3pl4EyG+WwdQeHpTlpFyf9lh6flpF44Cww7Xyh55wvIG92r8vB
 0uiS0Ufq5y7Cz5UVYCIZMWzrQGNF5/y5INfJIvxNhKDAbDWEerA26J8Ie9GhWv3L5iQ9
 p27rNMFLzgzwyIn1DhJPS7d0cDglU9NWqlpKCizCxbZwfkJLRq8r68euCYUYRI2Qp103
 Wgyo0a+tK+hc9lHkg30O/NZEObXX18gwwzQf3/UzCIzZQ3W4jUFM5TBbKovo72JDV7XQ
 gOsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=jHFAmX7UngdKyooHP5toYd51Ywma3v51WwT3jy7CPho=;
 b=GpBG4boqjn7AdA+kFXR1kjMdYg/Fm2vER5QQH4Uyid6jN82ClJeA4J6IBRGSVf5955
 p1oBvs/NlIpcK+YuW5VEs+dKKhdDGQ2eP386rHNMNjKFJwBKFZCOGsTAnHw6awlLqM35
 2gOXiC1ANcIRxS5u53nwosVnCADlOKD2/fD3N0UoAG4pmSvCpcfLQFtji24l7IyOxUb0
 SeQ+Lhhmq7N4WipVgfoYzjMX3RlCaUHNDN3kSBmg/83tuldOCh1BcIVQMyo1Y7ekqFST
 8J20tQWeXo3IdagX3aO6JWBIVgHLROS0OO3adWXgLWWg3ar6vQWJf7tbSde+x1b+Smpu
 Zy7w==
X-Gm-Message-State: ACrzQf3oNtlrHX0onmTkytm3QdbtOyn9u28WhWbj6UcehgblXEZdqthH
 s804Mlmv12aIPdRycRTKHSZ0VZtAmx3IR6paKQrmGg4MLcg=
X-Google-Smtp-Source: AMsMyM4f7j0B1DEqXhOfi9/23445J0bz+dx+c7ECxHUFpwYH6FDVOHNSD2vz9gpOhSJXpJqE72JkWeBnLZBdujOarXA=
X-Received: by 2002:a05:6402:3487:b0:463:9585:ae40 with SMTP id
 v7-20020a056402348700b004639585ae40mr11925918edc.31.1667395980278; Wed, 02
 Nov 2022 06:33:00 -0700 (PDT)
MIME-Version: 1.0
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
 <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
 <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>
 <Y2HfAVTgj6qZb49q@erisian.com.au>
In-Reply-To: <Y2HfAVTgj6qZb49q@erisian.com.au>
From: Greg Sanders <gsanders87@gmail.com>
Date: Wed, 2 Nov 2022 09:32:49 -0400
Message-ID: <CAB3F3DsHGSv1A6kHq_2F5OkugSxUpvhCWz=MvJLRX=iSxXeBPw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000001ac0cf05ec7ce152"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Wed, 02 Nov 2022 13:33:04 -0000

--0000000000001ac0cf05ec7ce152
Content-Type: text/plain; charset="UTF-8"

> I think that's a huge oversimplification of "rational" -- otherwise
you might as well say that deliberately pinning txs is also rational,
because it allows the person doing the pinning to steal funds from their
counterparty by forcing a timeout to expire.

To be clear, a pinner is attempting to *not* pay
the most fees, by definition. If we're somehow sure something is a pin,
we should not allow it, because miners rationally do not want it vs
an "honest" bid for fees. V3 design is one attempt to carve out a safe
space for fee bidding. Carving out a safe space for *non-bidding* is not the
same thing.

I think this mostly boils down having knobs or not. I'm fine with knobs
with paternalistic defaults, especially when a non-zero percentage of users
disagree with a value in either direction.

Greg

On Tue, Nov 1, 2022 at 11:07 PM Anthony Towns <aj@erisian.com.au> wrote:

> On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev
> wrote:
> > For 0-conf services we have potential thieves who are willing
> > to *out-bid themselves* to have funds come back to themselves. It's not a
> > "legitimate" use-case, but a rational one.
>
> I think that's a huge oversimplification of "rational" -- otherwise
> you might as well say that deliberately pinning txs is also rational,
> because it allows the person doing the pinning to steal funds from their
> counterparty by forcing a timeout to expire.
>
> There's no need for us as developers, or us as node operators, to support
> every use case that some individual might find rational at some point in
> time. After all, it might be individually rational for someone to want the
> subsidy to stop decreasing, or to include 8MB of transactions per block.
>
> Note that it's also straightforwardly rational and incentive compatible
> for miners to not want this patch to be available, under the following
> scenario:
>
>  - a significant number of on-chain txs are for zeroconf services
>  - fee income would be reduced if zeroconf services went away
>    (both directly due to the absence of zeroconf payments, and by
>    reducing mempool pressure, reducing fee income from the on-chain txs
>    that remain)
>  - miners adopting fullrbf would cause zeroconf services to go away,
>    (and won't enable a comparable volume of new services that generates
>    comparable transaction volume)
>  - including the option in core would make other miners adopting
>    fullrbf more likely
>
> I think the first three of those are fairly straightforward and objective,
> at least at this point in time. The last is just a risk; but without
> any counterbalancing benefit, why take it?
>
> Gaining a few thousand sats due to high feerate replacement txs from
> people exploiting zeroconf services for a few months before all those
> services shutdown doesn't make up for the lost fee income over the months
> or years it might have otherwise taken people to naturally switch to
> some better alternative.
>
> Even if fullrbf worked for preventing pinning that likely doesn't directly
> result in much additional fee income: once you know that pinning doesn't
> work, you just don't try it, which means there's no opportunity for
> miners to profit from a bidding war from the pinners counterparties
> repeatedly RBFing their preferred tx to get it mined.
>
> That also excludes second order risks: if you can't do zeroconf with BTC
> anymore, do you switch to ERC20 tokens, and then trade your BTC savings
> for ETH or USDT, and do enough people do that to lower the price of BTC?
> If investors see BTC being less used for payments, does that lower their
> confidence in bitcoin's future, and cause them to sell?
>
> > Removing a
> > quite-likely-incentive-compatible option from the software just
> encourages
> > miners to adopt an additional patch
>
> Why shouldn't miners adopt an additional patch if they want some unusual
> functionality?
>
> Don't we want/expect miners to have the ability to change the code in
> meaningful ways, at a minimum to be able to cope with the scenario where
> core somehow gets coopted and releases bad code, or to be able to deal
> with the case where an emergency patch is needed?
>
> Is there any evidence miners even want this option? Peter suggested
> that some non-signalling replacements were being mined already [0], but
> as far as I can see [1] all of those are simply due to the transaction
> they replaced not having propagated in the first place (or having been
> evicted somehow? hard to tell without any data on the original tx).
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html
> [1] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292692367
>
> > 2) Forcing miners to honor fees left on the table with respect to 0-conf,
> > or forcing them to run a custom patchset to go around it, is a step
> > backwards.
>
> As you already acknowledged, any miner that wants this behaviour can just
> pick up the patch (or could run Knots, which already has the feature
> enabled by default). It's simply false to say miners are being forced
> to do anything, no matter what we do here.
>
> If the direction you're facing is one where you're moving towards making
> life easier for people to commit fraud, and driving away businesses
> that aren't doing anyone harm, without achieving anything much else;
> then taking a step backwards seems like a sensible thing to do to me.
>
> (I remain optimistic about coming up with better RBF policy, and willing
> to be gung ho about everyone switching over to it even if it does kill
> off zeroconf, provided it actually does some good and we give people 6
> months or more notice that it's definitely happening and what exactly
> the new rules will be, though)
>
> Cheers,
> aj
>

--0000000000001ac0cf05ec7ce152
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; I think that&#39;s a huge oversimplification of =
&quot;rational&quot; -- otherwise<br></div>you might as well say that delib=
erately pinning txs is also rational,<br>because it allows the person doing=
 the pinning to steal funds from their<br>counterparty by forcing a timeout=
 to expire.<div><br></div><div>To be clear, a pinner is attempting to *not*=
 pay</div><div>the most fees, by definition. If we&#39;re somehow sure some=
thing is a pin,</div><div>we should not allow it, because miners rationally=
 do not want it vs</div><div>an &quot;honest&quot; bid for fees. V3 design =
is one attempt to carve out a safe</div><div>space for fee bidding. Carving=
 out a safe space for *non-bidding* is not the</div><div>same thing.</div><=
div><br></div><div>I think this mostly boils down having knobs or not. I&#3=
9;m fine with knobs with paternalistic defaults, especially when a non-zero=
 percentage of users disagree with a value in either direction.</div><div><=
br></div><div>Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Tue, Nov 1, 2022 at 11:07 PM Anthony Towns &lt;<=
a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Oct 31, 2022 a=
t 12:25:46PM -0400, Greg Sanders via bitcoin-dev wrote:<br>
&gt; For 0-conf services we have potential thieves who are willing<br>
&gt; to *out-bid themselves* to have funds come back to themselves. It&#39;=
s not a<br>
&gt; &quot;legitimate&quot; use-case, but a rational one.<br>
<br>
I think that&#39;s a huge oversimplification of &quot;rational&quot; -- oth=
erwise<br>
you might as well say that deliberately pinning txs is also rational,<br>
because it allows the person doing the pinning to steal funds from their<br=
>
counterparty by forcing a timeout to expire.<br>
<br>
There&#39;s no need for us as developers, or us as node operators, to suppo=
rt<br>
every use case that some individual might find rational at some point in<br=
>
time. After all, it might be individually rational for someone to want the<=
br>
subsidy to stop decreasing, or to include 8MB of transactions per block.<br=
>
<br>
Note that it&#39;s also straightforwardly rational and incentive compatible=
<br>
for miners to not want this patch to be available, under the following<br>
scenario:<br>
<br>
=C2=A0- a significant number of on-chain txs are for zeroconf services<br>
=C2=A0- fee income would be reduced if zeroconf services went away<br>
=C2=A0 =C2=A0(both directly due to the absence of zeroconf payments, and by=
<br>
=C2=A0 =C2=A0reducing mempool pressure, reducing fee income from the on-cha=
in txs<br>
=C2=A0 =C2=A0that remain)<br>
=C2=A0- miners adopting fullrbf would cause zeroconf services to go away,<b=
r>
=C2=A0 =C2=A0(and won&#39;t enable a comparable volume of new services that=
 generates<br>
=C2=A0 =C2=A0comparable transaction volume)<br>
=C2=A0- including the option in core would make other miners adopting<br>
=C2=A0 =C2=A0fullrbf more likely<br>
<br>
I think the first three of those are fairly straightforward and objective,<=
br>
at least at this point in time. The last is just a risk; but without<br>
any counterbalancing benefit, why take it?<br>
<br>
Gaining a few thousand sats due to high feerate replacement txs from<br>
people exploiting zeroconf services for a few months before all those<br>
services shutdown doesn&#39;t make up for the lost fee income over the mont=
hs<br>
or years it might have otherwise taken people to naturally switch to<br>
some better alternative.<br>
<br>
Even if fullrbf worked for preventing pinning that likely doesn&#39;t direc=
tly<br>
result in much additional fee income: once you know that pinning doesn&#39;=
t<br>
work, you just don&#39;t try it, which means there&#39;s no opportunity for=
<br>
miners to profit from a bidding war from the pinners counterparties<br>
repeatedly RBFing their preferred tx to get it mined.<br>
<br>
That also excludes second order risks: if you can&#39;t do zeroconf with BT=
C<br>
anymore, do you switch to ERC20 tokens, and then trade your BTC savings<br>
for ETH or USDT, and do enough people do that to lower the price of BTC?<br=
>
If investors see BTC being less used for payments, does that lower their<br=
>
confidence in bitcoin&#39;s future, and cause them to sell?<br>
<br>
&gt; Removing a<br>
&gt; quite-likely-incentive-compatible option from the software just encour=
ages<br>
&gt; miners to adopt an additional patch<br>
<br>
Why shouldn&#39;t miners adopt an additional patch if they want some unusua=
l<br>
functionality?<br>
<br>
Don&#39;t we want/expect miners to have the ability to change the code in<b=
r>
meaningful ways, at a minimum to be able to cope with the scenario where<br=
>
core somehow gets coopted and releases bad code, or to be able to deal<br>
with the case where an emergency patch is needed?<br>
<br>
Is there any evidence miners even want this option? Peter suggested<br>
that some non-signalling replacements were being mined already [0], but<br>
as far as I can see [1] all of those are simply due to the transaction<br>
they replaced not having propagated in the first place (or having been<br>
evicted somehow? hard to tell without any data on the original tx).<br>
<br>
[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-October/021012.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html</a><br>
[1] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1=
292692367" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/=
bitcoin/pull/26287#issuecomment-1292692367</a><br>
<br>
&gt; 2) Forcing miners to honor fees left on the table with respect to 0-co=
nf,<br>
&gt; or forcing them to run a custom patchset to go around it, is a step<br=
>
&gt; backwards.<br>
<br>
As you already acknowledged, any miner that wants this behaviour can just<b=
r>
pick up the patch (or could run Knots, which already has the feature<br>
enabled by default). It&#39;s simply false to say miners are being forced<b=
r>
to do anything, no matter what we do here. <br>
<br>
If the direction you&#39;re facing is one where you&#39;re moving towards m=
aking<br>
life easier for people to commit fraud, and driving away businesses<br>
that aren&#39;t doing anyone harm, without achieving anything much else;<br=
>
then taking a step backwards seems like a sensible thing to do to me.<br>
<br>
(I remain optimistic about coming up with better RBF policy, and willing<br=
>
to be gung ho about everyone switching over to it even if it does kill<br>
off zeroconf, provided it actually does some good and we give people 6<br>
months or more notice that it&#39;s definitely happening and what exactly<b=
r>
the new rules will be, though)<br>
<br>
Cheers,<br>
aj<br>
</blockquote></div>

--0000000000001ac0cf05ec7ce152--