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
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
|
Return-Path: <john@synonym.to>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D54BAC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2022 14:56:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 9A0FE4091F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2022 14:56:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9A0FE4091F
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com
header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=ZqKz2BSJ
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_NONE=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 vV55NKd9dX2h
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2022 14:56:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C7600408EE
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com
[IPv6:2607:f8b0:4864:20::d2e])
by smtp4.osuosl.org (Postfix) with ESMTPS id C7600408EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2022 14:56:36 +0000 (UTC)
Received: by mail-io1-xd2e.google.com with SMTP id b192so3171174iof.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2022 06:56:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=synonym-to.20210112.gappssmtp.com; s=20210112;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=XbIX67es0vDYKtu6JVaj5EVR8ofq7SYxpB/st6YCMbM=;
b=ZqKz2BSJzp8NRip9DauaN790uio7AgO8zOlgCcX2qlMmThGJIb9dt+Mh7I581CiZZS
HSPXDRC/9AQuDhtzbZlNhnmpkZBwFZFEp4jlNsnJLy+pIESy1hkc++a2kmwFFiq9XUYC
Ptm4LQ0GgeQ7Dd0CbYiVuHdIMxk6J6JDE7o5PMn4sEa6t55tLw/PPeRtP5cAYz/39rUh
+wnVxZISYCAjuoTp36lZ+mB9qd3+MuqJ0KJIIwCPOFBmNswfNFRu5+TBaAENeKuxXQFv
PBR3PY+D3dY8Nm/OHPBwDTTRVzyVUu9xr1KKl72tFGKJOO28WzLL4LzvADQx8YWMFEgP
c6Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=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=XbIX67es0vDYKtu6JVaj5EVR8ofq7SYxpB/st6YCMbM=;
b=pGR+UTzzT+oddASz2CgGaRtvRrkwI6UjxyFkjamWqA2TrmuOL+h/YMSr5R12D5JsKV
+MDFvMNdwRJIjWR1IzLXX8G3Lo+xT4F4RBcSRjXhlD+zmqC7j6dVBfjInb2LWg6Hy/Oo
we9XDiyeqYs/5ACYQJFmqfSgH/4m2aie7afC+wecsSvlIE7fD7meWA3OUlbOxm4U5xUv
p9GRdhCzMAfuKvtAoSb0RHytLjFALLfVVl2/lIExQFm5Av27xaA1J5vYuQs5J18Mpc3w
O/cQqTSElfnGVG3OauSIUGbAo55jq7djiOcB9+MQe8/xAlmjJ8Zk7vgOmCwpX+NJLBAI
PxhQ==
X-Gm-Message-State: ANoB5pm+Dv4IJKiHEksoNwKB9uBL2y6F1480Pb6snsZUj529FENIzGKT
O3ui2lYh3RLI09aNMw+rNPN2AkUaEZHoBv0WbFaCHqIV92g7aGMu
X-Google-Smtp-Source: AA0mqf4mHW/JbmBS3y7nycnJmqLvamiEvoEjvpPygiPAaDB3t54cBWhVkr6j6dcrMndXcJvXf3nVnAAHxH3h+sS+hgE=
X-Received: by 2002:a02:cc34:0:b0:389:f6ea:d939 with SMTP id
o20-20020a02cc34000000b00389f6ead939mr18181270jap.222.1670770595383; Sun, 11
Dec 2022 06:56:35 -0800 (PST)
MIME-Version: 1.0
References: <CAHTn92zBcMp7Fn27aCV75V7GEzUcP2-cDcGN+CKe5+SRgyt2ow@mail.gmail.com>
<etg4FvUcuYL3LQxf-uu9UhLjGP9nabMMsLjYt2nxD4qbfEr6Pfft3ImDr0u6_CnYXxmHCd02hsgztB0zpVP82jSO0LrP45bt74b1GPtr3RM=@protonmail.com>
In-Reply-To: <etg4FvUcuYL3LQxf-uu9UhLjGP9nabMMsLjYt2nxD4qbfEr6Pfft3ImDr0u6_CnYXxmHCd02hsgztB0zpVP82jSO0LrP45bt74b1GPtr3RM=@protonmail.com>
From: John Carvalho <john@synonym.to>
Date: Sun, 11 Dec 2022 14:56:24 +0000
Message-ID: <CAHTn92w8fm1aeMp29EG+_yFeVY7OpKOKuBtJephg6wyXkY_tdQ@mail.gmail.com>
To: Michael Folkson <michaelfolkson@protonmail.com>,
Bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d6e54605ef8e97f0"
X-Mailman-Approved-At: Sun, 11 Dec 2022 15:23:26 +0000
Subject: Re: [bitcoin-dev]
=?utf-8?q?Rethinking_=E2=80=9CIncentive_Compatibili?=
=?utf-8?q?ty=E2=80=9D_Within_the_Bitcoin_Protocol?=
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: Sun, 11 Dec 2022 14:56:39 -0000
--000000000000d6e54605ef8e97f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
While I appreciate your reference links, and will check them out (thanks!),
I do not appreciate your repeated takes about my character or quality of
experience. I have been in Bitcoin for 10 years, I build with it, I manage
a Bitcoin company with 8 engineers, and, modesty aside, there aren't very
many non-engineers that grasp how Bitcoin works as well as I do. I put lots
of time into Bitcoin, and do my best to scrutinize all concepts presented
to me.
When I post in github, you mention I should be banned and you ignore my
substantive arguments. If I post on the list here, you imply I am a noob,
have difficulty understanding, and that I'm biased by business. This is not
useful other than some, probably false, notion that maybe you can position
yourself as superior or myself as dismissable.
My post is an analysis on incentives and how we understand them when
designing for Bitcoin. You explained a bit about what the mempool is for,
and some dynamics about it, but you may notice that doing something like
mempoolfullrbf is actually inconsistent with a goal of mempool harmony. It
is a disruptive change, therefore a tradeoff. The arguments for making that
tradeoff use some oversimplified concepts, in my opinion.
So, I am questioning the quality of current theory, and showing how it
might be insufficient.
- Do you think it is possible that a fully replaceable mempool, and
obsoletion of zero-conf (merchant/consumer) use cases could result in less
overall mining income? If not, why not?
- Could this, and other active management by Bitcoin Core engineers, result
in an overall less valuable, less useful Bitcoin, and is that bad for
miners/security?
- Do you think it is inconsistent that on one hand, Bitcoiners argue that
miners do not control Bitcoin, yet Bitcoin Core is biasing decisions to
cater to mining incentives over user incentives? Should miners do what
users want, and might that be their actual incentive?
- Do you think it is Core's place to influence or steer policy based on
speculation about what may happen in the future, even when it conflicts
with the present and past?
*These* are the interesting questions. Do you have reasoned answers?
You suggest you are comfortable outsourcing your understanding and
decisions to others, well I am not, and my post was meant to show some
reasons why. It is important that Bitcoiners question how, when, and
whether Bitcoin software is changed, regardless of their ability to create
or audit code.
Please analyze my ideas instead of me, thank you. Or, you could stay out of
it and outsource that to someone else as well.
~John
On Sun, Dec 11, 2022 at 1:58 PM Michael Folkson <
michaelfolkson@protonmail.com> wrote:
> Hey John
>
> There was a discussion [0] started by Lisa on the mailing list last year
> on whether there is any point to a full node maintaining a mempool last
> year which you may find interesting. I also recommend Gloria's presentati=
on
> [1] from Adopting Bitcoin last year on transaction relay policy.
>
> I think those are better resources than anything I could write. But I
> guess I'd summarize it like this. The job of the P2P/mempool/policy
> protocol devs in setting defaults is to ensure anyone can effectively
> propagate a consensus valid transaction across the network ultimately
> making its way into miners' mempools without harming network health (full
> node uptime, DoS attacks etc) and to give higher layers built on top of t=
he
> Bitcoin network the best chance to succeed. If they totally screwed up th=
at
> job with the defaults or they were unable to cater for a particular use
> case within default policy then there is always the alternative of
> submitting consensus valid transactions directly to miners bypassing the
> P2P network entirely. But clearly it is much better if the P2P network
> functions smoothly and every transaction isn't forced to be directly
> submitted to a miner. It is policy too of course rather than consensus so
> if the full node operator wants to change from the defaults they are free
> to do so without risking being forked off the network or risking a chain
> split.
>
> > I know some of you may scoff at my bias for use cases like zero-conf,
> but what I am trying to convey is a possible folly in active management,
> speculation, and misapplied game theory that may permeate many Bitcoin Co=
re
> decisions and designs, even beyond the mempoolrbf / zero-conf debate.
>
> This stuff is difficult to follow and understand especially for people wh=
o
> haven't been into Bitcoin for long or are trying to build Bitcoin
> businesses full time, there are lots of subtleties. I've certainly
> struggled at many points in my learning journey and I'm sure I will
> continue to do so in future. So there is no scoffing (from me at least) a=
t
> individuals trying to learn and businesses trying to thrive and provide
> services to their customers. Unfortunately there are occasionally scenari=
os
> where trade-offs have to be weighed up and decisions have to be made wher=
e
> some people aren't happy. You may disagree but I'm a lot more comfortable
> delegating responsibility for policy defaults to those who have worked fu=
ll
> time in this area for years than say consensus changes where I think we a=
ll
> have a responsibility to ensure suboptimal or worse harmful changes aren'=
t
> made to the consensus rules. I thought your input on the CTV discussion
> earlier in the year was really positive for example. On this topic though=
I
> think you could do with doing some more reading as there is *a lot*=E2=80=
=8B of
> past discussion. I'm sure those who work in this area full time would be
> happy to answer any questions you have if you do.
>
> Thanks
> Michael
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/0195=
72.html
> [1]:
> https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-t=
ransaction-relay-policy/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoin-dev =
<
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> As we debate mempoolfullrbf, and I familiarize myself with related PRs
> from engineers trying to reign in all of the possible behaviors that make
> it inconsistent, I can=E2=80=99t help but think about how I see people us=
ing the
> term =E2=80=9Cincentive-compatible=E2=80=9D and how it seems to be awfull=
y presumptive.
>
> The idea that a single Bitcoin transaction can be =E2=80=9Cincentive-comp=
atible=E2=80=9D
> by simply restricting it to having a higher fee or fee rate is theoretica=
l,
> likely narrow, and not totally objective. RBF is inherently a
> fee-minimization tool, which as a concept, as I understand
> =E2=80=9Cincentive-compatibility=E2=80=9D to be about miners in this cont=
ext, makes RBF to
> be anti-incentives; miners are fee maximizers.
>
> Miners want the most fees per block, and per lifetime, do they not? If
> miners, and the mempool, are prioritizing for the smallest txns with the
> highest fees, over the longest acceptable amount of time, this may confli=
ct
> with extra-mempool behaviors that result in more txns per block / per
> lifetime.
>
> If this isn=E2=80=99t making sense yet, let me summarize by how such a pr=
oblem
> would express: a per-transaction fee-minimized, fully replaceable mempool
> as policy, that appears to always require the highest fee per txn, but
> ultimately includes less txns per block and less fees per lifetime.
> Basically, less use cases, less users, less txns =E2=80=94 all to enforce=
a
> misunderstood theory and predictive speculation of what people want out o=
f
> the system and what miners will do about it.
>
> Simply, we probably want designs that fill blocks, and we don=E2=80=99t n=
eed to do
> anything at all to facilitate bidding on a use case like replacement.
>
> Bidding does not require protocol enforcement, it is miner-subjective. So
> why are we pursuing it? Why do we even have RBF? Why are we trying to cle=
an
> up all of the mess RBF creates with more and more code? If bidding is
> already accepted as incentive-compatible, and Bitcoin already allows
> setting a fee, then replacement requires no special code at all.
>
> I would think a holistic definition of what is incentive-compatible would
> be something more like what is =E2=80=9Cmarket compatible=E2=80=9D and en=
ables the
> complementary goals & incentives of every user in the system to make it
> thrive.
>
> It has been shown that users control Bitcoin (UASF) and thus ultimately
> miners would be incentivized to do what users want, up to the point of
> inability or loss. Correct?
>
> So, in contrast, how would the opposite, a user-compatible design,
> express? Well, I think the idea of txns being able to signal intent and
> desired behavior is more interesting (more useful) than a mempool that
> overrides all intent with RBF, and possibly more incentive-compatible tha=
n
> mempoolfullrbf as concept.
>
> Since we can=E2=80=99t be sure what the market wants, but we can be sure =
that the
> more users we have, making the most possible txns, at the highest possibl=
e
> prices, will yield the most valuable Bitcoin, and thus the most hashpower=
,
> we could entertain giving users the most ways to express their intent, th=
e
> most flexibility.
>
> The most basic design would be to simply have no mempool policy at all,
> and let market incentives emerge on their own, but we have a status quo t=
o
> consider, and most users do not have the technical expertise to express
> their own policies with misc patches and hacks of their Bitcoin Core
> software.
>
> I know this is a bit of a high-level abstract perspective, but I think it
> is important to respect such dynamics when making smaller decisions. It
> certainly is not our charge to prioritize what miners want any more than
> any other user type, nor is it within our ability to predict the future o=
r
> fully model incentives of all players across all use cases.
>
> I know some of you may scoff at my bias for use cases like zero-conf, but
> what I am trying to convey is a possible folly in active management,
> speculation, and misapplied game theory that may permeate many Bitcoin Co=
re
> decisions and designs, even beyond the mempoolrbf / zero-conf debate.
>
> So, what to do?
>
> =E2=80=94
>
> John Carvalho
> CEO, Synonym.to
>
>
>
--000000000000d6e54605ef8e97f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">While I appreciate your reference links, and will check th=
em out (thanks!), I do not appreciate your repeated takes about my characte=
r or quality of experience. I have been in Bitcoin for 10 years, I build wi=
th it, I manage a Bitcoin company with 8 engineers, and, modesty aside, the=
re aren't very many non-engineers that grasp how Bitcoin works as well =
as I do. I put lots of time into Bitcoin, and do my best to scrutinize all =
concepts presented to me.=C2=A0<div><br></div><div>When I post in github, y=
ou mention I should be banned and you ignore my substantive arguments. If I=
post on the list here, you imply I am a noob, have difficulty understandin=
g,=C2=A0and that I'm biased by business. This is not useful other than =
some, probably false, notion that maybe you can position yourself as superi=
or or myself as dismissable.</div><div><br></div><div>My post is an analysi=
s on incentives and how we understand them when designing for Bitcoin. You =
explained a bit about what the mempool is for, and some dynamics about it, =
but you may notice that doing something like mempoolfullrbf is actually inc=
onsistent with a goal of mempool harmony. It is a disruptive change, theref=
ore a tradeoff. The arguments for making that tradeoff use some oversimplif=
ied concepts, in my opinion.</div><div><br></div><div>So, I am questioning =
the quality of current theory, and showing how it might be insufficient.=C2=
=A0</div><div><br></div><div>- Do you think it is possible that a fully rep=
laceable mempool, and obsoletion of zero-conf (merchant/consumer) use cases=
could result in less overall mining income? If not, why not?=C2=A0=C2=A0</=
div><div>- Could this, and other active management by Bitcoin Core engineer=
s, result in an overall less valuable, less useful Bitcoin, and is that bad=
for miners/security?=C2=A0</div><div>- Do you think it is inconsistent tha=
t on one hand, Bitcoiners argue that miners do not control Bitcoin, yet Bit=
coin Core is biasing=C2=A0decisions to cater to mining incentives over=C2=
=A0user=C2=A0incentives? Should miners do what users want, and might that b=
e their actual incentive?=C2=A0</div><div>- Do you think it is Core's p=
lace to influence or steer policy based on speculation about what may happe=
n in the future, even when it=C2=A0conflicts with the present and past?=C2=
=A0</div><div><br></div><div>*These* are the interesting=C2=A0questions. Do=
you have reasoned answers?</div><div><br></div><div>You suggest you are co=
mfortable outsourcing your understanding and decisions to others, well I am=
not, and my post was meant to show some reasons why. It is important that =
Bitcoiners question how, when, and whether Bitcoin software is changed, reg=
ardless of their ability to create or audit code.<br></div><div><br></div><=
div>Please analyze my ideas instead of me, thank you. Or, you could stay ou=
t of it and outsource that to someone else as well.</div><div><br></div><di=
v>~John</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Sun, Dec 11, 2022 at 1:58 PM Michael Folkson <<a href=3D=
"mailto:michaelfolkson@protonmail.com">michaelfolkson@protonmail.com</a>>=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div st=
yle=3D"font-family:Arial;font-size:14px">Hey John</div><div style=3D"font-f=
amily:Arial;font-size:14px"><br></div><div style=3D"font-family:Arial;font-=
size:14px">There was a discussion [0] started by Lisa on the mailing list l=
ast year on whether there is any point to a full node maintaining a mempool=
last year which you may find interesting. I also recommend Gloria's pr=
esentation [1] from Adopting Bitcoin last year on transaction relay policy.=
</div><div style=3D"font-family:Arial;font-size:14px"><br></div><div style=
=3D"font-family:Arial;font-size:14px">I think those are better resources th=
an anything I could write. But I guess I'd summarize it like this. The =
job of the P2P/mempool/policy protocol devs in setting defaults is to ensur=
e anyone can effectively propagate a consensus valid transaction across the=
network ultimately making its way into miners' mempools without harmin=
g network health (full node uptime, DoS attacks etc) and to give higher lay=
ers built on top of the Bitcoin network the best chance to succeed. If they=
totally screwed up that job with the defaults or they were unable to cater=
for a particular use case within default policy then there is always the a=
lternative of submitting consensus valid transactions directly to miners by=
passing the P2P network entirely. But clearly it is much better if the P2P =
network functions smoothly and every transaction isn't forced to be dir=
ectly submitted to a miner. It is policy too of course rather than consensu=
s so if the full node operator wants to change from the defaults they are f=
ree to do so without risking being forked off the network or risking a chai=
n split.</div><div style=3D"font-family:Arial;font-size:14px"><br></div><di=
v style=3D"font-family:Arial;font-size:14px">> I know some of you may sc=
off at my bias for use cases like zero-conf, but what I am trying to convey=
is a possible folly in active management, speculation, and misapplied game=
theory that may permeate many Bitcoin Core decisions and designs, even bey=
ond the mempoolrbf / zero-conf debate.</div><div style=3D"font-family:Arial=
;font-size:14px"><br></div><div style=3D"font-family:Arial;font-size:14px">=
This stuff is difficult to follow and understand especially for people who =
haven't been into Bitcoin for long or are trying to build Bitcoin busin=
esses full time, there are lots of subtleties. I've certainly struggled=
at many points in my learning journey and I'm sure I will continue to =
do so in future. So there is no scoffing (from me at least) at individuals =
trying to learn and businesses trying to thrive and provide services to the=
ir customers. Unfortunately there are occasionally scenarios where trade-of=
fs have to be weighed up and decisions have to be made where some people ar=
en't happy. You may disagree but I'm a lot more comfortable delegat=
ing responsibility for policy defaults to those who have worked full time i=
n this area for years than say consensus changes where I think we all have =
a responsibility to ensure suboptimal or worse harmful changes aren't m=
ade to the consensus rules. I thought your input on the CTV discussion earl=
ier in the year was really positive for example. On this topic though I thi=
nk you could do with doing some more reading as there is <b>a lot</b>=E2=80=
=8B of past discussion. I'm sure those who work in this area full time =
would be happy to answer any questions you have if you do.</div><div style=
=3D"font-family:Arial;font-size:14px"><br></div><div style=3D"font-family:A=
rial;font-size:14px">Thanks</div><div style=3D"font-family:Arial;font-size:=
14px">Michael</div><div style=3D"font-family:Arial;font-size:14px"><br></di=
v><div style=3D"font-family:Arial;font-size:14px">[0]:=C2=A0<span><a rel=3D=
"noreferrer nofollow noopener" href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2021-October/019572.html" target=3D"_blank">https://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019572.html</a></=
span></div><div style=3D"font-family:Arial;font-size:14px">[1]:=C2=A0<span>=
<a rel=3D"noreferrer nofollow noopener" href=3D"https://btctranscripts.com/=
adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/" tar=
get=3D"_blank">https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-=
gloria-zhao-transaction-relay-policy/</a></span></div><div style=3D"font-fa=
mily:Arial;font-size:14px"><br></div>
<div style=3D"font-family:Arial;font-size:14px">
<div>
<div style=3D"font-family:arial;font-size:14px"><span style=3D"colo=
r:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;tex=
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;back=
ground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fon=
t-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospac=
e,monospace"><span style=3D"font-size:14px">--<br>Michael Folkson<br>Email:=
michaelfolkson at </span></span></span><a href=3D"http://protonmail.com/" =
style=3D"line-height:normal;text-decoration:underline;font-family:SFMono-Re=
gular,Consolas,"Liberation Mono",Menlo,monospace,monospace;font-s=
ize:14px;font-style:normal;font-weight:400;letter-spacing:normal;text-inden=
t:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px" rel=3D"noo=
pener noreferrer" target=3D"_blank">protonmail.com</a><span style=3D"color:=
rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;text-=
indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;backgr=
ound-color:rgb(255,255,255);float:none;display:inline"><span style=3D"font-=
family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace,=
monospace"><span style=3D"font-size:14px"> </span></span></span><br></div><=
div style=3D"font-family:arial;font-size:14px"><span style=3D"color:rgb(38,=
42,51);font-style:normal;font-weight:400;letter-spacing:normal;text-indent:=
0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;background-co=
lor:rgb(255,255,255);float:none;display:inline"><span style=3D"font-family:=
SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace,monospa=
ce"><span style=3D"font-size:14px">Keybase: michaelfolkson<br>PGP: 43ED C99=
9 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</span></span></span><br></div>
</div>
=20
<div>
=20
</div>
</div>
<div style=3D"font-family:Arial;font-size:14px"><br></div><div>
------- Original Message -------<br>
On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoi=
n-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">As we debate mempoolfullrbf, and I familiarize=
myself with related PRs from engineers trying to reign in all of the possi=
ble behaviors that make it inconsistent, I can=E2=80=99t help but think abo=
ut how I see people using the term =E2=80=9Cincentive-compatible=E2=80=9D a=
nd how it seems to be awfully presumptive.<br><br>The idea that a single Bi=
tcoin transaction can be =E2=80=9Cincentive-compatible=E2=80=9D by simply r=
estricting it to having a higher fee or fee rate is theoretical, likely nar=
row, and not totally objective. RBF is inherently a fee-minimization tool, =
which as a concept, as I understand =E2=80=9Cincentive-compatibility=E2=80=
=9D to be about miners in this context, makes RBF to be anti-incentives; mi=
ners are fee maximizers.<br><br>Miners want the most fees per block, and pe=
r lifetime, do they not? If miners, and the mempool, are prioritizing for t=
he smallest txns with the highest fees, over the longest acceptable amount =
of time, this may conflict with extra-mempool behaviors that result in more=
txns per block / per lifetime.<br><br>If this isn=E2=80=99t making sense y=
et, let me summarize by how such a problem would express: a per-transaction=
fee-minimized, fully replaceable mempool as policy, that appears to always=
require the highest fee per txn, but ultimately includes less txns per blo=
ck and less fees per lifetime. Basically, less use cases, less users, less =
txns=E2=80=8A=E2=80=94=E2=80=8Aall to enforce a misunderstood theory and pr=
edictive speculation of what people want out of the system and what miners =
will do about it.<br><br>Simply, we probably want designs that fill blocks,=
and we don=E2=80=99t need to do anything at all to facilitate bidding on a=
use case like replacement.<br><br>Bidding does not require protocol enforc=
ement, it is miner-subjective. So why are we pursuing it? Why do we even ha=
ve RBF? Why are we trying to clean up all of the mess RBF creates with more=
and more code? If bidding is already accepted as incentive-compatible, and=
Bitcoin already allows setting a fee, then replacement requires no special=
code at all.<br><br>I would think a holistic definition of what is incenti=
ve-compatible would be something more like what is =E2=80=9Cmarket compatib=
le=E2=80=9D and enables the complementary goals & incentives of every u=
ser in the system to make it thrive.<br><br>It has been shown that users co=
ntrol Bitcoin (UASF) and thus ultimately miners would be incentivized to do=
what users want, up to the point of inability or loss. Correct?<br><br>So,=
in contrast, how would the opposite, a user-compatible design, express? We=
ll, I think the idea of txns being able to signal intent and desired behavi=
or is more interesting (more useful) than a mempool that overrides all inte=
nt with RBF, and possibly more incentive-compatible than mempoolfullrbf as =
concept.<br><br>Since we can=E2=80=99t be sure what the market wants, but w=
e can be sure that the more users we have, making the most possible txns, a=
t the highest possible prices, will yield the most valuable Bitcoin, and th=
us the most hashpower, we could entertain giving users the most ways to exp=
ress their intent, the most flexibility.<br><br>The most basic design would=
be to simply have no mempool policy at all, and let market incentives emer=
ge on their own, but we have a status quo to consider, and most users do no=
t have the technical expertise to express their own policies with misc patc=
hes and hacks of their Bitcoin Core software.<br><br>I know this is a bit o=
f a high-level abstract perspective, but I think it is important to respect=
such dynamics when making smaller decisions. It certainly is not our charg=
e to prioritize what miners want any more than any other user type, nor is =
it within our ability to predict the future or fully model incentives of al=
l players across all use cases.<br><br>I know some of you may scoff at my b=
ias for use cases like zero-conf, but what I am trying to convey is a possi=
ble folly in active management, speculation, and misapplied game theory tha=
t may permeate many Bitcoin Core decisions and designs, even beyond the mem=
poolrbf / zero-conf debate.<br><br>So, what to do?<br><br>=E2=80=94<br><br>=
John Carvalho<br>CEO, Synonym.to</div>
</blockquote><br>
</div></blockquote></div>
--000000000000d6e54605ef8e97f0--
|