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
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id B4C11C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jun 2022 13:24:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id B25BE83FC5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jun 2022 13:24:17 +0000 (UTC)
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
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 8jqRMf0CKSoL
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jun 2022 13:24:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com
[IPv6:2607:f8b0:4864:20::1129])
by smtp1.osuosl.org (Postfix) with ESMTPS id A658983FB8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jun 2022 13:24:15 +0000 (UTC)
Received: by mail-yw1-x1129.google.com with SMTP id
00721157ae682-31756c8143aso13522197b3.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jun 2022 06:24:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=YtpR47TTZE3xw8xLuM5NmxnhuZ4GcULSrHqzhtCgZRo=;
b=DTAK4NEfWNvf43f5W/jgZ+Pg1x9Y9ISHjyfWAnvRmifu6+/mKq92GuHIKTvl0rOMXB
ywdtrtXjQtW65tdF3PjaTTqnm2Prek0Rj50AsiASsHiRUbjpuIKjWPcgXg69vRxxX/HM
l+zk4jWOZVLgz1GP4yuSvhvyN9aNHh3xjCZxvaKIWAFv3gUWZcIHrj231LqouY723H5q
etp6PIeEl4BWdg5PSseAO7fW+lsKq1KikPArP8ZimfkdVevGbgX+tCAm26b3ztSZgrgQ
ASRtygp5R4AaKF9JsNZD8SNxcj2YweLS0PVmefzmwMlnpGhNlOsocnSD5Q3JCJgvsqFs
lKDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=YtpR47TTZE3xw8xLuM5NmxnhuZ4GcULSrHqzhtCgZRo=;
b=qzO+muc+PHEp7Op8AazkM1HpKoAK/jh9eseAC8aq47XS7ualgi88MKFAyClsNJ86V3
K/Rk6F520JFcdcL2QKwKK9xga6KQcR3nc0kiNpPFprFkdIzVA4YRUR+WrK/ltJSbK2GT
Yguv/FmiKWyXwaheioAUQWfzjoz//jwjBn+fYWt6q0qwRDjxDyyokClhLfUfeWJpbPIY
qu+1nzU16NdDu7Xorn3j+FwEujGC/CuapNgo8OugV/1u9i22ca9/h+jAGwdekt+44Vuk
UISOjMBxYQJJo0cSmqrTkTLMH1sMcSpnx9SYIUuplGqJjvwqGpgyaKoalTHUpHpHIW4G
0HsQ==
X-Gm-Message-State: AJIora/A0kgVEPmMRnBKSKcOR1eYc6+WeoyY5AnOoO0d4Gfuhf5n0Ct9
nTVNG337DiWbYdGLYtqIq+sD95k0nkG4tl/Ec+M=
X-Google-Smtp-Source: AGRyM1tcCZNi/Y5xg6MptOtnUm9rvQhrKZQEr7S/EExzmtfVXeFSza1YutUsm7JVfHkzrdPQzdhw5DmIvTAqHZqXnEg=
X-Received: by 2002:a0d:eb41:0:b0:30f:7e1b:1c56 with SMTP id
u62-20020a0deb41000000b0030f7e1b1c56mr5610558ywe.475.1655385854139; Thu, 16
Jun 2022 06:24:14 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GOh-7weEypT9JrzcwthZJqHOfj7sf9FMuqi5_FZv0g7w@mail.gmail.com>
<7aP7ve-x6uMLSY2a9ZvpkyEc7uOdWmCGOs-S2ly1klRKzm5kVT4zjC9i0V6k1R0Cr9Xloq6Z4zmZ0LfquOxFtyhrA0RgsfG4qq760T4dfZM=@protonmail.com>
<CAB3F3DuhMQn_fSiXqqzrUMhDm7D=AiKg4nSO71372WzJFCr9EQ@mail.gmail.com>
<dYLEcCTOYwMe7umkzbxdFz-sp5ZwqHU6DcpAg8M8p-ANg8QWSafISIzDXhbGiAHlV6eInfar2ll9oWviwox4SZ7QwfgqXkIbgq_fvcaUz0M=@protonmail.com>
In-Reply-To: <dYLEcCTOYwMe7umkzbxdFz-sp5ZwqHU6DcpAg8M8p-ANg8QWSafISIzDXhbGiAHlV6eInfar2ll9oWviwox4SZ7QwfgqXkIbgq_fvcaUz0M=@protonmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 16 Jun 2022 09:24:03 -0400
Message-ID: <CAB3F3DutbXiRXTHx-eEKyEvtq7edpV7AaHA3s1K+UtkyDuT2vQ@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000cd641405e1908df9"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s
security
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, 16 Jun 2022 13:24:17 -0000
--000000000000cd641405e1908df9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> It is not possible to guarantee that a transaction will be mined within N
blocks irrespective of fees. It is vulnerable if a project's security
relies on it, and should fix it by changing the security assumptions.
It's not possible to guarantee that any funds can be moved ever. But we
still build an entire system assuming we can via an interesting mix of
cryptography and incentives.
On Wed, Jun 15, 2022 at 9:45 PM alicexbt <alicexbt@protonmail.com> wrote:
> Hi Greg,
>
>
> The security of LN and other related systems are something like: "given
> proper fees offered, can a transaction be mined within N blocks?" You're
> simply not allowed to out-bid your attacker in certain circumstances due =
to
> today's miner incentive-incompatible relay policies.
>
>
> It is not possible to guarantee that a transaction will be mined within N
> blocks irrespective of fees. It is vulnerable if a project's security
> relies on it, and should fix it by changing the security assumptions.
> Miners can try full-rbf or other policy without core so I won't consider
> opt-in as incentive-incompatible.
>
> > ... arguments about how many people RBF being sufficient or not ...
>
> The idea that we should only build robust systems after the broken ones
> are attacked is not a serious argument.
>
>
> Its true and was even mentioned in PR #16171 that a policy is only useful
> if enough nodes and miners follow it. We should build robust systems but =
I
> don't think this change will help in doing it.
>
> This is a strawman.
>
> Full-RBF is a simple, obvious, incentive-compatible step to getting close=
r
> to more robust layer two systems. Fixing the rest of the holes is for
> future proposals which are a bit more involved and definitely less mature=
.
>
>
> I do not have issues with multiple RBF policies being tried out and
> full-rbf being one of them. My disagreements are with rationale, lack of
> basic options in Bitcoin Core to employ/disable different RBF policies
> and a few arguments made in support for full-rbf. Whether it appears
> strawman or offtopic on github, there should be a place to share these
> disagreements.
>
> If Knots has these knobs, just use Knots rather than lobby all
> implementations to have miner incentive incompatible knobs?
>
>
> Everyone can share options that would help users in the bitcoin
> implementation used by 90% nodes. I don't think this is reserved only for=
a
> few developers. I would personally use Knots and others are free to try t=
he
> suggestion or continue using Bitcoin Core.
>
> /dev/fd0
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Thursday, June 16th, 2022 at 6:32 AM, Greg Sanders <
> gsanders87@gmail.com> wrote:
>
> > If something relies on a policy which can be changed without breaking
> consensus rules, how is it secure in any case with or without full rbf?
>
> The security of LN and other related systems are something like: "given
> proper fees offered, can a transaction be mined within N blocks?" You're
> simply not allowed to out-bid your attacker in certain circumstances due =
to
> today's miner incentive-incompatible relay policies.
>
> There is also a time-value dimension to this with other simpler systems
> where your funds can be locked up for potentially weeks for similar reaso=
ns.
>
> > ... arguments about how many people RBF being sufficient or not ...
>
> The idea that we should only build robust systems after the broken ones
> are attacked is not a serious argument.
>
> > I am not opposed to full-rbf; rather, I am opposed to the notion that
> full-rbf will solve all problems
>
> This is a strawman.
>
> Full-RBF is a simple, obvious, incentive-compatible step to getting close=
r
> to more robust layer two systems. Fixing the rest of the holes is for
> future proposals which are a bit more involved and definitely less mature=
.
>
> > would suggest users to try Bitcoin Knots instead
> > Developers should provide basic RBF policy options rather than
> attempting to define what constitutes a good policy and removing the
> ability to disable something when necessary.
>
> If Knots has these knobs, just use Knots rather than lobby all
> implementations to have miner incentive incompatible knobs?
>
> Cheers,
> Greg
>
> On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Antoine,
>>
>>
>> Thanks for opening the pull request to add support for full-rbf in
>> Bitcoin Core. I have a few disagreements with the approach and questions=
.
>>
>> Recent discussions among LN devs have brought back on the surface
>> concerns about the security of multi-party funded transactions (coinjoin=
s,
>> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
>> low-fruit, naive DoS vector playable against the funding flow of any suc=
h
>> construction due to the lack of existent full-rbf transaction-relay
>> topology on today's p2p network [0] [1].
>>
>>
>> 1)If something relies on a policy which can be changed without breaking
>> consensus rules, how is it secure in any case with or without full rbf? =
If
>> I write a python script that expects user to enter char 'a' or 'b' but u=
ser
>> can enter 'c' and there is no code to handle exceptions or other chars,
>> will it be secure?
>>
>> 2)full-rbf is not default in the 2 open pull requests, so this experimen=
t
>> still relies on users changing RBF policies manually. If majority of nod=
es
>> use default opt-in policy, how would this affect vulnerable projects?
>>
>> If you're a mining operator looking to increase your income, you might b=
e
>> interested to experiment with full-rbf as a policy.
>>
>>
>> Miners can only increase their income if users replace transactions. 2-3=
%
>> transactions are replaced with opt-in RBF, if someone did not replace
>> earlier why would they do it with full RBF? Or even if we add some users=
in
>> it who could not signal for some reasons, do you think it would be anyth=
ing
>> above 5%?
>>
>> If you're a Bitcoin user or business and you don't like full-rbf, please
>> express an opinion on how it might affect your software/operations. I'm
>> always interested to learn more about mempool and transaction-relay
>> interactions with upper-layers and applications and to listen to feedbac=
k
>> in those areas, and I guess a lot of other Bitcoin researchers/devs too.=
I
>> know there have been a lot of concerns about full-rbf in the past, howev=
er
>> I believe the Bitcoin ecosystem has matured a lot since then.
>>
>>
>> I am not opposed to full-rbf; rather, I am opposed to the notion that
>> full-rbf will solve all problems and the lack of basic options in Bitcoi=
n
>> Core to employ/disable different RBF policies. There is also a speculati=
on
>> about making full RBF default in an year which isn't relevant to discuss=
at
>> this point without trying different RBF policies.
>>
>> I would suggest users to try Bitcoin Knots instead which already has an
>> option to disable all RBF policies if required, opt-in and full RBF poli=
cy.
>> This can also be done using GUI if not familiar with config option
>> mempoolreplacement=E2=80=8B.
>>
>> The rationale in PR #16171 was insufficient to justify removing it in th=
e
>> first place, had 2 NACKs and was reopened to merge it. Why bother with a
>> few lines of code that may allow someone disable it if required in local
>> mempool since it's only useful when a big percentage of miners utilize i=
t
>> and essentially underused according to the PR author? Developers should
>> provide basic RBF policy options rather than attempting to define what
>> constitutes a good policy and removing the ability to disable something
>> when necessary.
>>
>>
>> /dev/fd0
>>
>> Sent with Proton Mail <https://proton.me/> secure email.
>>
>> ------- Original Message -------
>> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Hi list,
>>
>> Recent discussions among LN devs have brought back on the surface
>> concerns about the security of multi-party funded transactions (coinjoin=
s,
>> dual-funded LN channels, on-chain DLCs, ...). It turns out there is a
>> low-fruit, naive DoS vector playable against the funding flow of any suc=
h
>> construction due to the lack of existent full-rbf transaction-relay
>> topology on today's p2p network [0] [1]. While it does not consist in a
>> direct loss of funds, if exploited well I think it's annoying enough to
>> inflict significant timevalue loss or fee-bumping waste
>> to the future providers or distributed swarm of users doing multi-party
>> funded transactions. Of course, it can be fixed one layer above by
>> introducing either fidelity bonds or a reliable centralized coordinator,
>> though at the price of an overhead per-participant ressources cost and l=
oss
>> in system openness [1].
>>
>> For that reason, I believe it would be beneficial to the flourishing of
>> multi-party funded transactions to fix the Dos vector by seeing a subset=
of
>> the network running full-rbf and enabling propagation of honest multi-pa=
rty
>> transactions to the interested miners, replacing potential non-signaling
>> double-spend from a malicious counterparty. Moving towards that directio=
n,
>> I've submitted a small patch against Bitcoin Core enabling it to turn on
>> full-rbf as a policy, still under review [3]. The default setting stays
>> **false**, i.e keeping opt-in RBF as a default replacement policy. I've
>> started to run the patch on a public node at 146.190.224.15.
>>
>> If you're a node operator curious to play with full-rbf, feel free to
>> connect to this node or spawn up a toy, public node yourself. There is a
>> ##uafrbf libera chat if you would like information on the settings or
>> looking for full-rbf friends (though that step could be automated in the
>> future by setting up a dedicated network bit and reserving a few outboun=
d
>> slots for them).
>>
>> If you're a mining operator looking to increase your income, you might b=
e
>> interested to experiment with full-rbf as a policy. Indeed, in the futur=
e I
>> believe the multi-party transactions issuers who need full-rbf to secure
>> their funding flow should connect by default to full-rbf peers. One can
>> conjecture that their transactions are likely to be more compelling in
>> their feerate as their liquidity needs are higher than the simple
>> transaction. For today, I think we have really few standards and bitcoin
>> softwares relying on multi-party funded transactions [4].
>>
>> If you're a Bitcoin user or business and you don't like full-rbf, please
>> express an opinion on how it might affect your software/operations. I'm
>> always interested to learn more about mempool and transaction-relay
>> interactions with upper-layers and applications and to listen to feedbac=
k
>> in those areas, and I guess a lot of other Bitcoin researchers/devs too.=
I
>> know there have been a lot of concerns about full-rbf in the past, howev=
er
>> I believe the Bitcoin ecosystem has matured a lot since then.
>>
>> Any mistakes or missing context is my own.
>>
>> Cheers,
>> Antoine
>>
>> [0] For more info about replace-by-fee, see
>> https://bitcoinops.org/en/topics/replace-by-fee/
>>
>> [1] For more details about the DoS vector, see
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00303=
3.html
>>
>> [2] E.g I think it does not affect the Lightning Pool service, as there
>> is a preliminary step where the participant funds are locked first in a
>> 2-of-2 with the coordinator before being committed in the multi-party ba=
tch
>> transaction.
>>
>> [3] https://github.com/bitcoin/bitcoin/pull/25353
>>
>> [4] E.g DLCs :
>> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transaction=
s.md
>> ; Lightning dual-funded channel :
>> https://github.com/lightning/bolts/pull/851
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
--000000000000cd641405e1908df9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-family:arial;font-size:14px"=
>It is not possible to guarantee that a transaction will be mined within N =
blocks irrespective of fees. It is vulnerable i</span><span style=3D"font-f=
amily:arial;font-size:14px">f a project's security relies on it,=C2=A0<=
/span><span style=3D"font-family:arial;font-size:14px">and should fix it by=
changing the security assumptions.</span><div><span style=3D"font-family:a=
rial;font-size:14px"><br></span></div><div><font face=3D"arial"><span style=
=3D"font-size:14px">It's not possible to guarantee=C2=A0that any funds =
can be moved ever. But we still build an entire system assuming we can via =
an interesting mix of cryptography and incentives.=C2=A0</span></font></div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Wed, Jun 15, 2022 at 9:45 PM alicexbt <<a href=3D"mailto:alicexbt@pr=
otonmail.com">alicexbt@protonmail.com</a>> wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:arial;font-s=
ize:14px">Hi Greg,</div><div style=3D"font-family:arial;font-size:14px"><br=
></div><div style=3D"font-family:arial;font-size:14px"><br></div><div style=
=3D"font-family:arial;font-size:14px"><blockquote type=3D"cite" style=3D"pa=
dding:0px 0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,229,229);fo=
nt-family:Arial,"Helvetica Neue",Helvetica,sans-serif;background-=
color:rgb(255,255,255)"><div dir=3D"ltr"><span><span style=3D"font-family:a=
rial">The security of LN and other related systems are something like: &quo=
t;given proper fees offered, can a transaction be mined within N blocks?&qu=
ot; You're simply not allowed to out-bid your attacker in certain circu=
mstances due to today's miner incentive-incompatible relay policies.</s=
pan></span></div></blockquote><br></div><div style=3D"font-family:arial;fon=
t-size:14px">It is not possible to guarantee that a transaction will be min=
ed within N blocks irrespective of fees. It is vulnerable i<span style=3D"b=
ackground-color:rgb(255,255,255);display:inline">f a project's security=
relies on it,<span>=C2=A0</span></span>and should fix it by changing the s=
ecurity assumptions. Miners can try full-rbf or other policy without core s=
o I won't consider opt-in as incentive-incompatible.</div><div style=3D=
"font-family:arial;font-size:14px"><br></div><div style=3D"font-family:aria=
l;font-size:14px"><blockquote type=3D"cite" style=3D"padding:0px 0px 0px 1r=
em;margin:0px;border-left:4px solid rgb(229,229,229);font-family:Arial,&quo=
t;Helvetica Neue",Helvetica,sans-serif;background-color:rgb(255,255,25=
5)"><div dir=3D"ltr"><span><font face=3D"arial"><span>> ... a</span></fo=
nt><span style=3D"font-family:arial">rguments about how many people RBF bei=
ng sufficient or not ...</span></span><div><span style=3D"font-family:arial=
"><br></span></div><span><font face=3D"arial"><span>The idea that we should=
only build robust systems after the broken ones are attacked is not a seri=
ous argument.</span></font></span></div></blockquote><br></div><div style=
=3D"font-family:arial;font-size:14px">Its true and was even mentioned in PR=
#16171 that a policy is only useful if enough nodes and miners follow it. =
We should build robust systems but I don't think this change will help =
in doing it.</div><div style=3D"font-family:arial;font-size:14px"><br></div=
><div style=3D"font-family:arial;font-size:14px"><blockquote type=3D"cite" =
style=3D"padding:0px 0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,=
229,229);font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;=
background-color:rgb(255,255,255)"><div dir=3D"ltr"><span><span style=3D"fo=
nt-family:arial">This is a strawman.</span></span><div><span style=3D"font-=
family:arial"><br></span></div><span><span style=3D"font-family:arial">Full=
-RBF is a simple, obvious, incentive-compatible step to getting closer to m=
ore robust layer two systems.<span>=C2=A0</span></span><span style=3D"font-=
family:arial">Fixing the rest of the holes is for future proposals which ar=
e a bit more involved and definitely less mature.</span></span></div></bloc=
kquote><br></div><div style=3D"font-family:arial;font-size:14px">I do not h=
ave issues with multiple RBF policies being tried out and full-rbf being on=
e of them. My disagreements are with rationale,=C2=A0<span>lack of basic op=
tions in Bitcoin Core to employ/disable different RBF policies</span> and a=
few arguments made in support for full-rbf. Whether it appears strawman or=
offtopic on github, there should be a place to share these disagreements.<=
/div><div style=3D"font-family:arial;font-size:14px"><br></div><div style=
=3D"font-family:arial;font-size:14px"><blockquote type=3D"cite" style=3D"pa=
dding:0px 0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,229,229);fo=
nt-family:Arial,"Helvetica Neue",Helvetica,sans-serif;background-=
color:rgb(255,255,255)"><div dir=3D"ltr"><span>If Knots has these knobs, ju=
st use Knots rather than lobby all implementations to have miner incentive =
incompatible knobs?</span></div></blockquote><br></div><div style=3D"font-f=
amily:arial;font-size:14px">Everyone can share options that would help user=
s in the bitcoin implementation used by 90% nodes. I don't think this i=
s reserved only for a few developers. I would personally use Knots and othe=
rs are free to try the suggestion or continue using Bitcoin Core.</div><div=
style=3D"font-family:arial;font-size:14px"><br></div><div style=3D"font-fa=
mily:arial;font-size:14px">/dev/fd0</div><div style=3D"font-family:arial;fo=
nt-size:14px"><br></div><div style=3D"font-family:arial;font-size:14px"><br=
></div>
<div style=3D"font-family:arial;font-size:14px">
<div>
</div>
<div>
Sent with <a href=3D"https://proton.me/" rel=3D"noopener noreferrer=
" target=3D"_blank">Proton Mail</a> secure email.
</div>
</div>
<div style=3D"font-family:arial;font-size:14px"><br></div><div>
------- Original Message -------<br>
On Thursday, June 16th, 2022 at 6:32 AM, Greg Sanders <<a href=
=3D"mailto:gsanders87@gmail.com" target=3D"_blank">gsanders87@gmail.com</a>=
> wrote:<br><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">> <span style=3D"font-family:arial;font-siz=
e:14px">If something relies on a policy which can be changed without breaki=
ng consensus rules, how is it secure in any case with or without full rbf?<=
/span><div><span style=3D"font-family:arial;font-size:14px"><br></span></di=
v><div><span style=3D"font-family:arial;font-size:14px">The security of LN =
and other related systems are something like: "given proper fees offer=
ed, can a transaction be mined within N blocks?" You're simply not=
allowed to out-bid your attacker in certain circumstances due to today'=
;s miner incentive-incompatible relay policies.</span><br></div><div><span =
style=3D"font-family:arial;font-size:14px"><br></span></div><div><span styl=
e=3D"font-family:arial;font-size:14px">There is also a time-value dimension=
to this with other simpler systems where your funds can be locked up for p=
otentially weeks for similar reasons.</span></div><div><font face=3D"arial"=
><span style=3D"font-size:14px"><br></span></font></div><div><font face=3D"=
arial"><span style=3D"font-size:14px">> ... a</span></font><span style=
=3D"font-family:arial;font-size:14px">rguments about how many people RBF be=
ing sufficient or not ...</span></div><div><span style=3D"font-family:arial=
;font-size:14px"><br></span></div><div><font face=3D"arial"><span style=3D"=
font-size:14px">The idea that we should only build robust systems after the=
broken ones are attacked is not a serious argument.</span></font></div><di=
v><font face=3D"arial"><span style=3D"font-size:14px"><br></span></font></d=
iv><div><font face=3D"arial"><span style=3D"font-size:14px">> </span></f=
ont><span style=3D"font-family:arial;font-size:14px">I am not opposed to fu=
ll-rbf; rather, I am opposed to the notion that full-rbf will solve all pro=
blems</span></div><div><span style=3D"font-family:arial;font-size:14px"><br=
></span></div><div><span style=3D"font-family:arial;font-size:14px">This is=
a strawman.</span></div><div><span style=3D"font-family:arial;font-size:14=
px"><br></span></div><div><span style=3D"font-family:arial;font-size:14px">=
Full-RBF is a simple, obvious, incentive-compatible step to getting closer =
to more robust layer two systems. </span><span style=3D"font-size:14px;font=
-family:arial">Fixing the rest of the holes is for future proposals which a=
re a bit more involved and definitely less mature.</span></div><div><br></d=
iv><div>> <span style=3D"font-family:arial;font-size:14px"> </span><span=
style=3D"font-family:arial;font-size:14px">would suggest users to try Bitc=
oin Knots instead</span></div><div>> <span style=3D"font-family:arial;fo=
nt-size:14px">Developers should provide basic RBF policy options rather tha=
n attempting to define what constitutes a good policy and removing the abil=
ity to disable something when necessary.</span></div><div><br></div><div>If=
Knots has these knobs, just use Knots rather than lobby all implementation=
s to have miner incentive incompatible knobs?</div><div><br></div><div>Chee=
rs,</div><div>Greg</div></div><br><div class=3D"gmail_quote"><div class=3D"=
gmail_attr" dir=3D"ltr">On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoi=
n-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a>> wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmai=
l_quote"><div style=3D"font-family:arial;font-size:14px"><span style=3D"col=
or:rgb(34,34,34)">Hi Antoine,</span><div style=3D"color:rgb(34,34,34)"><br>=
</div><div style=3D"color:rgb(34,34,34)"><br></div><div style=3D"color:rgb(=
34,34,34)">Thanks for opening the pull request to add support for full-rbf =
in Bitcoin Core. I have a few disagreements with the approach and questions=
.</div><div style=3D"color:rgb(34,34,34)"><br></div><div style=3D"color:rgb=
(34,34,34)"><blockquote style=3D"margin:0px;padding:0px 0px 0px 1rem;font-s=
ize:1em;border-left:4px solid rgb(229,229,229);color:rgb(0,0,0);font-family=
:Arial,"Helvetica Neue",Helvetica,sans-serif;background-color:rgb=
(255,255,255)" type=3D"cite"><span dir=3D"ltr">Recent discussions among LN =
devs have brought back on the surface concerns about the security of multi-=
party funded transactions (coinjoins, dual-funded LN channels, on-chain DLC=
s, ...). It turns out there is a low-fruit, naive DoS vector playable again=
st the funding flow of any such construction due to the lack of existent fu=
ll-rbf transaction-relay topology on today's p2p network [0] [1].<span>=
</span></span></blockquote><br></div><div style=3D"color:rgb(34,34,34)">1)=
If something relies on a policy which can be changed without breaking conse=
nsus rules, how is it secure in any case with or without full rbf? If I wri=
te a python script that expects user to enter char 'a' or 'b=
9; but user can enter 'c' and there is no code to handle exceptions=
or other chars, will it be secure? </div><div style=3D"color:rgb(34,34,34=
)"><br></div><div style=3D"color:rgb(34,34,34)">2)full-rbf is not default i=
n the 2 open pull requests, so this experiment still relies on users changi=
ng RBF policies manually. If majority of nodes use default opt-in policy, h=
ow would this affect vulnerable projects?</div><div style=3D"color:rgb(34,3=
4,34)"><br></div><div style=3D"color:rgb(34,34,34)"><blockquote style=3D"ma=
rgin:0px;padding:0px 0px 0px 1rem;font-size:1em;border-left:4px solid rgb(2=
29,229,229);color:rgb(0,0,0);font-family:Arial,"Helvetica Neue",H=
elvetica,sans-serif;background-color:rgb(255,255,255)" type=3D"cite"><span =
dir=3D"ltr">If you're a mining operator looking to increase your income=
, you might be interested to experiment with full-rbf as a policy.</span></=
blockquote><br></div><div style=3D"color:rgb(34,34,34)">Miners can only inc=
rease their income if users replace transactions. 2-3% transactions are rep=
laced with opt-in RBF, if someone did not replace earlier why would they do=
it with full RBF? Or even if we add some users in it who could not signal =
for some reasons, do you think it would be anything above 5%?</div><div sty=
le=3D"color:rgb(34,34,34)"><br></div><div style=3D"color:rgb(34,34,34)"><bl=
ockquote style=3D"margin:0px;padding:0px 0px 0px 1rem;font-size:1em;border-=
left:4px solid rgb(229,229,229);color:rgb(0,0,0);font-family:Arial,"He=
lvetica Neue",Helvetica,sans-serif;background-color:rgb(255,255,255)" =
type=3D"cite"><span dir=3D"ltr">If you're a Bitcoin user or business an=
d you don't like full-rbf, please express an opinion on how it might af=
fect your software/operations. I'm always interested to learn more abou=
t mempool and transaction-relay interactions with upper-layers and applicat=
ions and to listen to feedback in those areas, and I guess a lot of other B=
itcoin researchers/devs too. I know there have been a lot of concerns about=
full-rbf in the past, however I believe the Bitcoin ecosystem has matured =
a lot since then.</span></blockquote><br></div><div style=3D"color:rgb(34,3=
4,34)"><span>I am not opposed to full-rbf; rather, I am opposed to the noti=
on that full-rbf will solve all problems and the lack of basic options in B=
itcoin Core to employ/disable different RBF policies. There is also a specu=
lation about making full RBF default in an year which isn't relevant to=
discuss at this point without trying different RBF policies.</span></div><=
div style=3D"color:rgb(34,34,34)"><br></div><div style=3D"color:rgb(34,34,3=
4)">I would suggest users to try Bitcoin Knots instead which already has an=
option to disable all RBF policies if required, opt-in and full RBF policy=
. This can also be done using GUI if not familiar with config option<span> =
</span><code style=3D"font-family:ui-monospace,SFMono-Regular,Menlo,Monaco,=
Consolas,"Liberation Mono","Courier New",monospace;font=
-size:1em;white-space:pre-wrap;background-color:rgba(0,0,0,0)">mempoolrepla=
cement</code>=E2=80=8B.</div><div style=3D"color:rgb(34,34,34)"><br></div><=
div style=3D"color:rgb(34,34,34)"><span>The rationale in PR #16171 was insu=
fficient to justify removing it in the first place, had 2 NACKs and was reo=
pened to merge it. Why bother with a few lines of code that may allow someo=
ne disable it if required in local mempool since it's only useful when =
a big percentage of miners utilize it and essentially underused according t=
o the PR author? Developers should provide basic RBF policy options rather =
than attempting to define what constitutes a good policy and removing the a=
bility to disable something when necessary.</span></div><div style=3D"color=
:rgb(34,34,34)"><br></div><div style=3D"color:rgb(34,34,34)"><br></div><spa=
n style=3D"color:rgb(34,34,34)">/dev/fd0</span><br></div><div style=3D"font=
-family:arial;font-size:14px"><br></div>
<div style=3D"font-family:arial;font-size:14px">
<div>
</div>
<div>
Sent with <a rel=3D"noreferrer nofollow noopener" href=3D"https://p=
roton.me/" target=3D"_blank">Proton Mail</a> secure email.
</div>
</div>
<div style=3D"font-family:arial;font-size:14px"><br></div><div>
------- Original Message -------<br>
On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-d=
ev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"nore=
ferrer nofollow noopener" target=3D"_blank">bitcoin-dev@lists.linuxfoundati=
on.org</a>> wrote:<br><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">Hi list,<br><br>Recent discussions among LN de=
vs have brought back on the surface concerns about the security of multi-pa=
rty funded transactions (coinjoins, dual-funded LN channels, on-chain DLCs,=
...). It turns out there is a low-fruit, naive DoS vector playable against=
the funding flow of any such construction due to the lack of existent full=
-rbf transaction-relay topology on today's p2p network [0] [1]. While i=
t does not consist in a direct loss of funds, if exploited well I think it&=
#39;s annoying enough to inflict significant timevalue loss or fee-bumping =
waste <br>to the future providers or distributed swarm of users doing multi=
-party funded transactions. Of course, it can be fixed one layer above by i=
ntroducing either fidelity bonds or a reliable centralized coordinator, tho=
ugh at the price of an overhead per-participant ressources cost and loss in=
system openness [1].<br><br>For that reason, I believe it would be benefic=
ial to the flourishing of multi-party funded transactions to fix the Dos ve=
ctor by seeing a subset of the network running full-rbf and enabling propag=
ation of honest multi-party transactions to the interested miners, replacin=
g potential non-signaling double-spend from a malicious counterparty. Movin=
g towards that direction, I've submitted a small patch against Bitcoin =
Core enabling it to turn on full-rbf as a policy, still under review [3]. T=
he default setting stays **false**, i.e keeping opt-in RBF as a default rep=
lacement policy. I've started to run the patch on a public node at 146.=
190.224.15.<br><br>If you're a node operator curious to play with full-=
rbf, feel free to connect to this node or spawn up a toy, public node yours=
elf. There is a ##uafrbf libera chat if you would like information on the s=
ettings or looking for full-rbf friends (though that step could be automate=
d in the future by setting up a dedicated network bit and reserving a few o=
utbound slots for them).<br><br>If you're a mining operator looking to =
increase your income, you might be interested to experiment with full-rbf a=
s a policy. Indeed, in the future I believe the multi-party transactions is=
suers who need full-rbf to secure their funding flow should connect by defa=
ult to full-rbf peers. One can conjecture that their transactions are likel=
y to be more compelling in their feerate as their liquidity needs are highe=
r than the simple transaction. For today, I think we have really few standa=
rds and bitcoin softwares relying on multi-party funded transactions [4].<b=
r><br>If you're a Bitcoin user or business and you don't like full-=
rbf, please express an opinion on how it might affect your software/operati=
ons. I'm always interested to learn more about mempool and transaction-=
relay interactions with upper-layers and applications and to listen to feed=
back in those areas, and I guess a lot of other Bitcoin researchers/devs to=
o. I know there have been a lot of concerns about full-rbf in the past, how=
ever I believe the Bitcoin ecosystem has matured a lot since then.<br><br>A=
ny mistakes or missing context is my own.<br><br>Cheers,<br>Antoine<br><br>=
[0] For more info about replace-by-fee, see <a rel=3D"noreferrer nofollow n=
oopener" href=3D"https://bitcoinops.org/en/topics/replace-by-fee/" target=
=3D"_blank">https://bitcoinops.org/en/topics/replace-by-fee/</a><br><br>[1]=
For more details about the DoS vector, see <a rel=3D"noreferrer nofollow n=
oopener" href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/=
2021-May/003033.html" target=3D"_blank">https://lists.linuxfoundation.org/p=
ipermail/lightning-dev/2021-May/003033.html</a><br><br>[2] E.g I think it d=
oes not affect the Lightning Pool service, as there is a preliminary step w=
here the participant funds are locked first in a 2-of-2 with the coordinato=
r before being committed in the multi-party batch transaction.<br><br>[3] <=
a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/bitcoin/b=
itcoin/pull/25353" target=3D"_blank">https://github.com/bitcoin/bitcoin/pul=
l/25353</a><br><br>[4] E.g DLCs : <a rel=3D"noreferrer nofollow noopener" h=
ref=3D"https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transac=
tions.md" target=3D"_blank">https://github.com/discreetlogcontracts/dlcspec=
s/blob/master/Transactions.md</a> ; Lightning dual-funded channel : <a rel=
=3D"noreferrer nofollow noopener" href=3D"https://github.com/lightning/bolt=
s/pull/851" target=3D"_blank">https://github.com/lightning/bolts/pull/851</=
a><br></div>
</blockquote><br>
</div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
nofollow noopener" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a><br>
<a rel=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote><br>
</div></blockquote></div>
--000000000000cd641405e1908df9--
|