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
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 29212C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Dec 2022 04:06:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id F20E960A9D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Dec 2022 04:06:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F20E960A9D
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=AFRYE1dc
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3E64-D0Z3qRj
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Dec 2022 04:06:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B12A760A77
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com
[IPv6:2607:f8b0:4864:20::d32])
by smtp3.osuosl.org (Postfix) with ESMTPS id B12A760A77
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Dec 2022 04:06:46 +0000 (UTC)
Received: by mail-io1-xd32.google.com with SMTP id n63so4559525iod.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Dec 2022 20:06:46 -0800 (PST)
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=7rsXpBGQATSZykUW7YdeW1FcagKABi0ddu/ljgG3QFQ=;
b=AFRYE1dcFT3KdW9Dum6BySoy9UHr6EFxHlNpBSY7jWB3EYZZwwHII+tpEhHm8LZCrX
USZ92b1cVjXheGMCdj5sXe8OE445JQgfXcQBl7xTCZTBrWwtJHxHg1KgcyCl4vXLl2Cp
3Gmtl08P26dbKsd70GCj+xm6O0A5qoMh9nB7gi0U76CMHBQ2t21d2pC6Cu3obQbhOd9Y
IDM2+cFNbxo4oKG+DoxD8I2EnqIGeVJS+FS3lj9spuJPeMk3XuGIOT2uwezZm1VW8h14
ggNhSaYcgBjpsVnY/U/GvZYP+bEr9dgmTAA6q4WQrLXU/Av9vx/yS3gr/5jy+okommKQ
VeQw==
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=7rsXpBGQATSZykUW7YdeW1FcagKABi0ddu/ljgG3QFQ=;
b=eDNuYxtxuyFxx9bYIs8orPjINrqS97e/+FRh+TtprHqv3b+RhBZaChFZ0u7xFeF87E
s14PEyAE/QZO+We2Ir4dVV/T5g3ASxjMA+CqjrkFTpgK+SnpeO4MIIq+lmZg1bdmymYO
MYDaVx6JnKnms3SmvvXdp66tEKXv7ISMU+FFWRHULTPtYl1i8xNfCumDKRpaAWJuI60z
4vnjGlxbeLTlqif9xF86YmNam3xPbwlDLNkIgOGdI/u6dKpOLVKyDXGrMZXwjr0hmGF5
Xzbi60etbbhIwv8l8RE+/DRcRFqJLs6WZJbwOMB4RVBDJ1oTqdAgI2Pnzkw5KzJoLhr6
LpIQ==
X-Gm-Message-State: ANoB5pmig9jG1WmD5r+/y/3uniANYkyJVAqaBFEYhLbnTB9tRBCiZ05S
lqF+A/nHUoWpJE82HWpE+wL+uRsVuJLYP41C1R58iU/aEQDaVQ==
X-Google-Smtp-Source: AA0mqf6I4cqPI7wn0JtB3OHj9+YO/1Cx/+l7ojgvY1v1bT9lntT9N/4lS+wRkVBq03fj1HrlX/Eg/fY/UAFyIqRaNzo=
X-Received: by 2002:a05:6638:3463:b0:38a:141c:414a with SMTP id
q35-20020a056638346300b0038a141c414amr9654830jav.179.1670299605505; Mon, 05
Dec 2022 20:06:45 -0800 (PST)
MIME-Version: 1.0
References: <mailman.15.1670068802.22993.bitcoin-dev@lists.linuxfoundation.org>
<CAHTn92zCFf+9yNgRZuoJ8L54fxJmPoOwcU3a9kSY5PLoYMk9dA@mail.gmail.com>
In-Reply-To: <CAHTn92zCFf+9yNgRZuoJ8L54fxJmPoOwcU3a9kSY5PLoYMk9dA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 5 Dec 2022 23:06:34 -0500
Message-ID: <CALZpt+F_B6MA18P9BQK9wKBE7hZzHa-tP6RiwTKaP=d9FrzujA@mail.gmail.com>
To: John Carvalho <john@synonym.to>
Content-Type: multipart/alternative; boundary="000000000000a79d6805ef20eea2"
X-Mailman-Approved-At: Tue, 06 Dec 2022 12:13:39 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 91, Issue 5
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: Tue, 06 Dec 2022 04:06:50 -0000
--000000000000a79d6805ef20eea2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi John,
Thanks for expressing your thoughts on the current state of
`-mempoolfullrbf`, from the perspective of a merchant and zero-conf
proponent. First and foremost, we're dealing with a nuanced and rich topic,
implying not only the inner workings of Bitcoin Core mempool policy rules,
the current topology of the peer-to-peer network and transactions
propagation across it, the miner block construction strategy, but even
further the consequences on multiple class of use-cases such as on-chain
payments, Ligthning and coinjoins.
In the present case, and as always, I'm only speaking for myself, based on
my years-long experience contributing to Bitcoin Core, the wider Lightning
ecosystem and few other open-source projects. While there is a
self-awareness of the scope of my statements expressed in one of my (rough)
domains of expertise, as usual I invite anyone to reason by oneself and
check my saying for opinions and wrongs.
That disclaimer said, in matters of feature removal, to the best of my
knowledge the Bitcoin Core's "decision-making" process should be followed
like any other code change, as documented by the CONTRIBUTING.md [0]. In
the conceptual appreciation of the change in soundness, of course the
ecosystem impacts or utility are lawfully decision grounds, as we've done
in the past for many Lightning/L2-related PRs.
W.r.t `mempoolfullrbf`, it has been argued on one-side it would a benefit
for some wallets usage (i.e replace non-signaling transactions from legacy
software [1]) and multi-party applications/ contracting protocols (i.e
remove a DoS vector [2]). On the other hand, it would change the security
model expectations of the 0confs operators. Whatever the evaluation one can
have of the soundness of those expectations, I think there is a lowering of
the technical bar one should reach to accomplish a double-spend.
During the last months of discussions, we had a mempool policy design
philosophy proposed aiming to accommodate all the Bitcoin use-cases alive
on the network, under the conditions they're not harming the network
interests [3]. Under this paradigm, we could have a policy regime for each
use-case, and we can devise another special rule to solve the DoS vector
affecting multi-party applications/contracting protocols have been proposed
[4].
With that in consideration, there is still the open question if this
mempool policy design philosophy proposed is sound enough in face of miner
incentives and won't generate asymmetries in mining incomes. Not only now,
but also in a future world where fee reward is most of miners income. To
the best of my understanding, there isn't an established and practical
model of miner incentives, at least among the Bitcoin Core developers. To
underscore, from my perspective this is where the conceptual discussion is
blocked, and where it would be opportune to spend time and energy on.
Anyone is invited to contribute on that front.
Zooming out, I believe the lack of current fullrbf hashrate shouldn't be a
disqualification that this mempool policy rule is not miner incentive
compatible. In the realm of science, the value of a model is its
performance to predict events, even if with a macro-system like Bitcoin
mining it might take years for the empirical confirmation to happen (namely
the exhaustion of mining reward). As we're seeing in physics, some lessons
of Einstein's general relativity expressed in the 1900 were only confirmed
by observation of solar eclipse in 1919.
In the meantime, as `mempoolfullrbf` is altering the security expectations
of the 0conf operators and on the other side the Lightning/coinjoins folks
have expressed low sensibility to the DoS vector [5], following a "first,
do not harm" philosophy, I think as an ecosystem we're better off to remove
the "risk-induction" `mempoolfullrbf` feature. Renewing here my position
previously expressed in #26438 [6] and #26525 [7].
Qualifying the existence of a harm in the eyes of the community, I think
this is valuable to have more merchants/services operators producing
effective usage data, from the past years, as Bitrefill has done as an
example [8]. Minding the lack of a verifiable process to attest the
authenticity of such merchant claims raises a methodological issue in the
discussion (and we could so in the future with cool ZKPs based on on-chain
data!)
Of course, I think we shouldn't lose sight of the existence of a
`mempoolfullrbf` patch, now widely disseminated across the ecosystem could
lead to a situation where only a minority of node operators using it would
damage the safety of the 0confs use-case. There is not that much the
Bitcoin Core project could do in that regard. While I think the project
aims to maximize the safety of the peer-to-peer network as a design
principle, including when we might have to restrain user choice, policy
rules are "soft" rules and the autonomy to modify them is only a function
of one's technical ability.
On the qualification of the Bitcoin Core as a political process, I think
this is an ignorance of the practice of day-to-day Core's process, where
the best code and reasonings are winning based on scientific and
engineering standards, even if we've always had a margin of improvements.
People are striving their best to ensure we follow an idea meritocracy
according to best open-source practice, and I think the project (and
Bitcoin itself in its 10+ years of history) wouldn't have survived so far
if it has been otherwise.
Finally, I can understand we have no economical data yet for the
multi-party funded and p2p coinjoins use-cases, as the specification
enabling them is still WIP and have not been implemented by all LN
softwares. I also fully understand the skepticism on how mempoolfullrbf
would solve a DoS vector for LN multi-party funded transactions, even if
I've done my best to describe the issue previously. I'm staying available
to demonstrate the pinning against a mainnet LN dual-funding flow if that
would convince you further, and then explain how the wide deployment of
mempoolfullrbf would block the DoS. I agree with you that instant channel
opening or splicing is very valuable, but there are a lot of additional
solutions that operators could deploy to have more fine-grained
risk-management.
All that said, I appreciate when anyone in the community raises the voice
to check-and-balance the work of Bitcoin Core contributors, this is really
needed for the health of the development process, as long as it's done in a
respectful and patient way.
Sincerely,
Antoine
[0] https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
[1] https://github.com/bitcoin/bitcoin/pull/26438#issuecomment-1304370679
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.h=
tml
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135=
.html
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/02114=
4.html
[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/02118=
3.html
[6] https://github.com/bitcoin/bitcoin/pull/26438#issuecomment-1305042950
[7] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006
[8] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282
Le lun. 5 d=C3=A9c. 2022 =C3=A0 12:26, John Carvalho <john@synonym.to> a =
=C3=A9crit :
> Antoine,
>
>
>> In the direction of removing the current option from Bitcoin Core, I
>> think the prerequisite to address are the qualification of enough econom=
ic
>> flows at risk and the presence of a sizable loss in miners income.
>
>
> Are such prerequisites for feature removal published somewhere? I don't
> see any reason why removing a controversial change should be harder than
> adding one. Generally, it is impossible to definitively attribute any
> change in network condition to one thing in such a complex system, and al=
so
> difficult to know how much time is required to express negative effects.
> The whole argument here is to prevent disruption of the status quo that h=
as
> lasted the whole history of Bitcoin, to avoid taking a speculative risk
> that full-RBF, at the expense of zero-conf, is maybe better for miners...
> or something.
>
> Further, I feel the mempoolfullrbf feature was rushed through while this
> controversy was growing, specifically to attempt to achieve this imaginar=
y
> protection of "sorry, that ship has sailed" which indicates an agenda tha=
t
> is counter to greater social consensus and status quo. We should not
> incentivize such behavior further by allowing this sort of feature
> sainthood.
>
> Beyond that, I think there is still the open question if we (we, as the
>> Bitcoin protocol development community, with all its stakeholders) shoul=
d
>> restrain user choice in policy settings in the name of preserving mining
>> income and established use-case stability.
>
>
> Removing the mempoolfullrbf feature is the opposite of restraining user
> choice.
>
> First, any incentivized user can still create and distribute patches for
> any given mempool policy, regardless of whether we remove the feature fro=
m
> Core, but it is important to note that extremely few have felt the need t=
o
> do so in the past.
>
> Second, the very debate here is about how it is mempoolfullrbf that
> removes the user choice of zero-conf services. With a first-seen policy i=
n
> place, users have *more* options, and Bitcoin is thus more useful, and th=
us
> more valuable to everyone. This is evident in that the feature of full-rb=
f
> is that it overrides any ability for users to signal intent of how they
> wish their transaction to be handled by nodes and miners. This is useful
> info to miners, as they make more money by facilitating use cases than by
> fee-minimizers painting everything as RBF. User-signaling is a useful
> feature for the mempool, full-RBF removes that feature.
>
> Third, when Bitcoin Core adds special support for specific policies, it
> positions itself as a political authority and influencer. It is not Core'=
s
> place to support one subjective policy more than another, particularly wh=
en
> it conflicts with years of status quo and breaks the current user space,
> and likely resulting in more doublespent user experiences.
>
> To recall, the original technical motivation of this option, and the wide=
r
>> smoother deployment was to address a DoS vector affecting another class =
of
>> use-case: multi-party transactions like coinjoin and contracting protoco=
ls
>> like Lightning [2] [3]. All of them expect to generate economic flows an=
d
>> corresponding mining income. Since then, alternative paths to solve this
>> DoS vector have been devised, all with their own trade-offs and conceptu=
al
>> issues [4] [5].
>
>
> I am particularly skeptical that users sending Bitcoin to themselves
> (coinjoin) could ever be more incentive-compatible than fast-paced commer=
ce
> & priority competition. I am also skeptical that mempoolfullrbf actually
> solves LN risks any better than opt-in RBF by default by LN implementatio=
ns
> and wallets.
>
> Further, zero-conf support reduces friction for LN adoption by allowing u=
s
> to make instant, seamless UX within wallets when onboarding, rebalancing,
> and splicing.
>
> --
> John Carvalho
> CEO, Synonym.to <http://synonym.to/>
>
>
>
>>
>> Date: Fri, 2 Dec 2022 17:35:39 -0500
>> From: Antoine Riard <antoine.riard@gmail.com>
>> To: Bitcoin Protocol Discussion
>> <bitcoin-dev@lists.linuxfoundation.org>
>> Subject: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in
>> immediate danger
>> Message-ID:
>> <
>> CALZpt+HFFwY4XECNZj3XLqnaumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com>
>> Content-Type: text/plain; charset=3D"utf-8"
>>
>> Hi Daniel,
>>
>> >From my understanding of GAP600, you're operating a zero-conf risk
>> analysis
>> business, which is integrated and leveraged by payment
>> processors/liquidity
>> providers and merchants. A deployment of fullrbf by enough full-node
>> operators and a subset of the mining hashrate would lower the cost of
>> double-spend attack by lamda users, therefore increasing the risk exposu=
re
>> of your users. This increased risk exposure could lead you to alter the
>> acceptance of incoming zero-conf transactions, AFAICT in a similar
>> reasoning as exposed by Bitrefill earlier this year [0].
>>
>> About the statistics you're asking for considerations, few further
>> questions, on those 1.5M transactions per month, a) how many are
>> Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many
>> are excluded from zeroconf due to factors like RBF, long-chain of
>> unconfirmed ancestors or too high-value and c) what has been the average
>> feerate (assuming a standard size of 200 bytes) ?
>>
>> My personal position on fullrbf is still the same as expressed in #26525
>> [1]. As a community, I think we still don't have conceptual consensus on
>> deploying full-rbf, nor to remove it. In the direction of removing the
>> current option from Bitcoin Core, I think the prerequisite to address ar=
e
>> the qualification of enough economic flows at risk and the presence of a
>> sizable loss in miners income. Beyond that, I think there is still the
>> open
>> question if we (we, as the Bitcoin protocol development community, with
>> all
>> its stakeholders) should restrain user choice in policy settings in the
>> name of preserving mining income and established use-case stability.
>>
>> To recall, the original technical motivation of this option, and the wid=
er
>> smoother deployment was to address a DoS vector affecting another class =
of
>> use-case: multi-party transactions like coinjoin and contracting protoco=
ls
>> like Lightning [2] [3]. All of them expect to generate economic flows an=
d
>> corresponding mining income. Since then, alternative paths to solve this
>> DoS vector have been devised, all with their own trade-offs and conceptu=
al
>> issues [4] [5].
>>
>> Best,
>> Antoine
>>
>
--000000000000a79d6805ef20eea2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi John,<br><br>Thanks for expressing your thoughts on the=
current state of `-mempoolfullrbf`, from the perspective of a merchant and=
zero-conf proponent. First and foremost, we're dealing with a nuanced =
and rich topic, implying not only the inner workings of Bitcoin Core mempoo=
l policy rules, the current topology of the peer-to-peer network and transa=
ctions propagation across it, the miner block construction strategy, but ev=
en further the consequences on multiple class of use-cases such as on-chain=
payments, Ligthning and coinjoins.<br><br>In the present case, and as alwa=
ys, I'm only speaking for myself, based on my years-long experience con=
tributing to Bitcoin Core, the wider Lightning ecosystem and few other open=
-source projects. While there is a self-awareness of the scope of my statem=
ents expressed in one of my (rough) domains of expertise, as usual I invite=
anyone to reason by oneself and check my saying for opinions and wrongs.<b=
r><br>That disclaimer said, in matters of feature removal, to the best of m=
y knowledge the Bitcoin Core's "decision-making" process shou=
ld be followed like any other code change, as documented by the CONTRIBUTIN=
G.md [0]. In the conceptual appreciation of the change in soundness, of cou=
rse the ecosystem impacts or utility are lawfully decision grounds, as we&#=
39;ve done in the past for many Lightning/L2-related PRs.<br><br>W.r.t `mem=
poolfullrbf`, it has been argued on one-side it would a benefit for some wa=
llets usage (i.e replace non-signaling transactions from legacy software [1=
]) and multi-party applications/ contracting protocols (i.e remove a DoS ve=
ctor [2]). On the other hand, it would change the security model expectatio=
ns of the 0confs operators. Whatever the evaluation one can have of the sou=
ndness of those expectations, I think there is a lowering of the technical =
bar one should reach to accomplish a double-spend.<br><br>During the last m=
onths of discussions, we had a mempool policy design philosophy proposed ai=
ming to accommodate all the Bitcoin use-cases alive on the network, under t=
he conditions they're not harming the network interests [3]. Under this=
paradigm, we could have a policy regime for each use-case, and we can devi=
se another special rule to solve the DoS vector affecting multi-party appli=
cations/contracting protocols have been proposed [4].<br><br>With that in c=
onsideration, there is still the open question if this mempool policy desig=
n philosophy proposed is sound enough in face of miner incentives and won&#=
39;t generate asymmetries in mining incomes. Not only now, but also in a fu=
ture world where fee reward is most of miners income. To the best of my und=
erstanding, there isn't an established and practical model of miner inc=
entives, at least among the Bitcoin Core developers. To underscore, from my=
perspective this is where the conceptual discussion is blocked, and where =
it would be opportune to spend time and energy on. Anyone is invited to con=
tribute on that front.<br><br>Zooming out, I believe the lack of current fu=
llrbf hashrate shouldn't be a disqualification that this mempool policy=
rule is not miner incentive compatible. In the realm of science, the value=
of a model is its performance to predict events, even if with a macro-syst=
em like Bitcoin mining it might take years for the empirical confirmation t=
o happen (namely the exhaustion of mining reward). As we're seeing in p=
hysics, some lessons of Einstein's general relativity expressed in the =
1900 were only confirmed by observation of solar eclipse in 1919.<br><br>In=
the meantime, as `mempoolfullrbf` is altering the security expectations of=
the 0conf operators and on the other side the Lightning/coinjoins folks ha=
ve expressed low sensibility to the DoS vector [5], following a "first=
, do not harm" philosophy, I think as an ecosystem we're better of=
f to remove the "risk-induction" `mempoolfullrbf` feature. Renewi=
ng here my position previously expressed in #26438 [6] and #26525 [7].<br><=
br>Qualifying the existence of a harm in the eyes of the community, I think=
this is valuable to have more merchants/services operators producing effec=
tive usage data, from the past years, as Bitrefill has done as an example [=
8]. Minding the lack of a verifiable process to attest the authenticity of =
such merchant claims raises a methodological issue in the discussion (and w=
e could so in the future with cool ZKPs based on on-chain data!)<br><br>Of =
course, I think we shouldn't lose sight of the existence of a `mempoolf=
ullrbf` patch, now widely disseminated across the ecosystem could lead to a=
situation where only a minority of node operators using it would damage th=
e safety of the 0confs use-case. There is not that much the Bitcoin Core pr=
oject could do in that regard. While I think the project aims to maximize t=
he safety of the peer-to-peer network as a design principle, including when=
we might have to restrain user choice, policy rules are "soft" r=
ules and the autonomy to modify them is only a function of one's techni=
cal ability.<br><br>On the qualification of the Bitcoin Core as a political=
process, I think this is an ignorance of the practice of day-to-day Core&#=
39;s process, where the best code and reasonings are winning based on scien=
tific and engineering standards, even if we've always had a margin of i=
mprovements. People are striving their best to ensure we follow an idea mer=
itocracy according to best open-source practice, and I think the project (a=
nd Bitcoin itself in its 10+ years of history) wouldn't have survived s=
o far if it has been otherwise.<br><br>Finally, I can understand we have no=
economical data yet for the multi-party funded and p2p coinjoins use-cases=
, as the specification enabling them is still WIP and have not been impleme=
nted by all LN softwares. I also fully understand the skepticism on how mem=
poolfullrbf would solve a DoS vector for LN multi-party funded transactions=
, even if I've done my best to describe the issue previously. I'm s=
taying available to demonstrate the pinning against a mainnet LN dual-fundi=
ng flow if that would convince you further, and then explain how the wide d=
eployment of mempoolfullrbf would block the DoS. I agree with you that inst=
ant channel opening or splicing is very valuable, but there are a lot of ad=
ditional solutions that operators could deploy to have more fine-grained ri=
sk-management.<br><br>All that said, I appreciate when anyone in the commun=
ity raises the voice to check-and-balance the work of Bitcoin Core contribu=
tors, this is really needed for the health of the development process, as l=
ong as it's done in a respectful and patient way. <br><br>Sincerely,<br=
>Antoine<br><br>[0] <a href=3D"https://github.com/bitcoin/bitcoin/blob/mast=
er/CONTRIBUTING.md">https://github.com/bitcoin/bitcoin/blob/master/CONTRIBU=
TING.md</a><br>[1] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26438=
#issuecomment-1304370679">https://github.com/bitcoin/bitcoin/pull/26438#iss=
uecomment-1304370679</a><br>[2] <a href=3D"https://lists.linuxfoundation.or=
g/pipermail/lightning-dev/2021-May/003033.html">https://lists.linuxfoundati=
on.org/pipermail/lightning-dev/2021-May/003033.html</a><br>[3] <a href=3D"h=
ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.=
html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/=
021135.html</a><br>[4] <a href=3D"https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2022-November/021144.html">https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2022-November/021144.html</a><br>[5] <a href=3D"http=
s://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021183.ht=
ml">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/0=
21183.html</a><br>[6] <a href=3D"https://github.com/bitcoin/bitcoin/pull/26=
438#issuecomment-1305042950">https://github.com/bitcoin/bitcoin/pull/26438#=
issuecomment-1305042950</a><br>[7] <a href=3D"https://github.com/bitcoin/bi=
tcoin/pull/26525#issuecomment-1319499006">https://github.com/bitcoin/bitcoi=
n/pull/26525#issuecomment-1319499006</a><br>[8] <a href=3D"https://github.c=
om/bitcoin/bitcoin/pull/26525#issuecomment-1332823282">https://github.com/b=
itcoin/bitcoin/pull/26525#issuecomment-1332823282</a><br></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 5 d=
=C3=A9c. 2022 =C3=A0=C2=A012:26, John Carvalho <<a href=3D"mailto:john@s=
ynonym.to">john@synonym.to</a>> a =C3=A9crit=C2=A0:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Antoine,</div>=
<div>=C2=A0</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">In the d=
irection of removing the current option from Bitcoin Core, I think the prer=
equisite to address are the qualification of enough economic flows at risk =
and the presence of a sizable loss in miners income.=C2=A0</blockquote><div=
dir=3D"ltr"><br></div><div>Are such prerequisites for feature removal publ=
ished somewhere? I don't see any reason why removing a controversial ch=
ange should=C2=A0be harder than adding one. Generally, it is impossible to =
definitively attribute any change in network condition to one thing in such=
a complex system, and also difficult to know how much time is required to =
express negative effects. The whole argument here is to prevent disruption =
of the status quo that has lasted the whole history of Bitcoin, to avoid ta=
king a speculative risk that full-RBF, at the expense of zero-conf, is mayb=
e better for miners... or something.</div><div><br></div><div>Further, I fe=
el the mempoolfullrbf=C2=A0feature was rushed through while this controvers=
y was growing, specifically to attempt to achieve this imaginary protection=
of "sorry, that ship has sailed" which indicates an agenda that =
is counter to greater social consensus and status quo. We should not incent=
ivize such behavior further by allowing this sort of feature sainthood.=C2=
=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">B=
eyond that, I think there is still the open question if we (we, as the Bitc=
oin protocol development community, with all its stakeholders) should restr=
ain user choice in policy settings in the name of preserving mining income =
and established use-case stability.</blockquote><div dir=3D"ltr"><br></div>=
<div>Removing the mempoolfullrbf feature is the opposite of restraining use=
r choice.=C2=A0</div><div><br></div><div>First, any incentivized user can s=
till create and distribute patches for any given mempool policy, regardless=
of whether we remove the feature from Core, but it is important to note th=
at extremely few have felt the need to do so in the past.</div><div><br></d=
iv><div>Second, the very debate here is about how it is mempoolfullrbf that=
removes the user choice of zero-conf services. With a first-seen policy in=
place, users have *more* options, and Bitcoin is thus more useful, and thu=
s more valuable to everyone. This is evident in that the feature of full-rb=
f is that it overrides any ability for users to signal intent of how they w=
ish their transaction to be handled by nodes and miners. This is useful inf=
o to miners, as they make more money by facilitating use cases than by fee-=
minimizers painting everything as RBF. User-signaling is a useful feature f=
or the mempool, full-RBF removes that feature.</div><div><br></div><div>Thi=
rd, when Bitcoin Core adds special support for specific policies, it positi=
ons itself as a political authority and influencer. It is not Core's pl=
ace to support one subjective policy more than another, particularly when i=
t conflicts with years of status quo and breaks the current user space, and=
likely resulting in more doublespent user experiences.</div><div><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">To recall, the original =
technical motivation of this option, and the wider smoother deployment was =
to address a DoS vector affecting another class of use-case: multi-party tr=
ansactions like coinjoin and contracting protocols like Lightning [2] [3]. =
All of them expect to generate economic flows and corresponding mining inco=
me. Since then, alternative paths to solve this DoS vector have been devise=
d, all with their own trade-offs and conceptual issues [4] [5].</blockquote=
><div dir=3D"ltr"><br></div><div dir=3D"ltr">I am particularly skeptical th=
at users sending Bitcoin to themselves (coinjoin) could ever be more incent=
ive-compatible than fast-paced commerce & priority competition. I am al=
so skeptical that mempoolfullrbf actually solves LN risks any better than o=
pt-in RBF by default by LN implementations and wallets.=C2=A0</div><div dir=
=3D"ltr"><br></div><div dir=3D"ltr">Further, zero-conf support reduces fric=
tion for LN adoption by allowing us to make instant, seamless UX within wal=
lets when onboarding, rebalancing, and splicing.=C2=A0</div><div dir=3D"ltr=
"><br clear=3D"all"><div><div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"c=
olor:rgb(34,34,34)">--</span><br style=3D"color:rgb(34,34,34)"><div dir=3D"=
ltr" style=3D"color:rgb(34,34,34)"><div dir=3D"ltr">John Carvalho</div><div=
dir=3D"ltr">CEO,=C2=A0<a href=3D"http://synonym.to/" style=3D"color:rgb(17=
,85,204)" target=3D"_blank">Synonym.to</a><br><div><br></div></div></div></=
div></div></div></div><br><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><br><br>
Date: Fri, 2 Dec 2022 17:35:39 -0500<br>
From: Antoine Riard <<a href=3D"mailto:antoine.riard@gmail.com" target=
=3D"_blank">antoine.riard@gmail.com</a>><br>
To: Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
Subject: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 immediate=C2=A0 =C2=A0 =C2=A0 =C2=A0danger<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:CALZpt%2BHFFwY4XECNZj3XLq=
naumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com" target=3D"_blank">CALZpt+HFFwY=
4XECNZj3XLqnaumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=3D"utf-8"<br>
<br>
Hi Daniel,<br>
<br>
>From my understanding of GAP600, you're operating a zero-conf risk =
analysis<br>
business, which is integrated and leveraged by payment processors/liquidity=
<br>
providers and merchants. A deployment of fullrbf by enough full-node<br>
operators and a subset of the mining hashrate would lower the cost of<br>
double-spend attack by lamda users, therefore increasing the risk exposure<=
br>
of your users. This increased risk exposure could lead you to alter the<br>
acceptance of incoming zero-conf transactions, AFAICT in a similar<br>
reasoning as exposed by Bitrefill earlier this year [0].<br>
<br>
About the statistics you're asking for considerations, few further<br>
questions, on those 1.5M transactions per month, a) how many are<br>
Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many<br=
>
are excluded from zeroconf due to factors like RBF, long-chain of<br>
unconfirmed ancestors or too high-value and c) what has been the average<br=
>
feerate (assuming a standard size of 200 bytes) ?<br>
<br>
My personal position on fullrbf is still the same as expressed in #26525<br=
>
[1]. As a community, I think we still don't have conceptual consensus o=
n<br>
deploying full-rbf, nor to remove it. In the direction of removing the<br>
current option from Bitcoin Core, I think the prerequisite to address are<b=
r>
the qualification of enough economic flows at risk and the presence of a<br=
>
sizable loss in miners income. Beyond that, I think there is still the open=
<br>
question if we (we, as the Bitcoin protocol development community, with all=
<br>
its stakeholders) should restrain user choice in policy settings in the<br>
name of preserving mining income and established use-case stability.<br>
<br>
To recall, the original technical motivation of this option, and the wider<=
br>
smoother deployment was to address a DoS vector affecting another class of<=
br>
use-case: multi-party transactions like coinjoin and contracting protocols<=
br>
like Lightning [2] [3]. All of them expect to generate economic flows and<b=
r>
corresponding mining income. Since then, alternative paths to solve this<br=
>
DoS vector have been devised, all with their own trade-offs and conceptual<=
br>
issues [4] [5].<br>
<br>
Best,<br>
Antoine<br>
</blockquote></div></div>
</blockquote></div>
--000000000000a79d6805ef20eea2--
|