summaryrefslogtreecommitdiff
path: root/b8/aa028f7bdd9c8ec7e7dc62b6ef909a676c7401
blob: e6469760c1575c0f38e2dd5ccf14ef522e76dbe0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
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
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6E073C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 17 Jun 2022 01:34:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 31A20417E0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 17 Jun 2022 01:34:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 31A20417E0
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=gfBlm0M0
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 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, MANY_SPAN_IN_TEXT=2.199,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 7BpZWpta2rhU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 17 Jun 2022 01:34:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0D42D417D7
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com
 [IPv6:2607:f8b0:4864:20::12b])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 0D42D417D7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 17 Jun 2022 01:34:29 +0000 (UTC)
Received: by mail-il1-x12b.google.com with SMTP id a15so2074661ilq.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Jun 2022 18:34:29 -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=bIVFYwTWQeFy1BBnCMEZDheS/lU/V0zvGxWyY5EO07o=;
 b=gfBlm0M0gdRwsk9KpfMfLkwiD5YPplj9mmjgkLUTdCEEh7W56nnJ8cAYb5ZyKIszOA
 IiMAU5d/hWzPhkfV3lKhMsJjAT50+5kOFtJ4EfYNkw5/tXehgkvrEAWDkiLdSx6ZP4Po
 9fjaG5EDQsuKUxjf/vvNXPgnL5XHyDQqPQSnR10Rm2wVvFhSjX3tWAoD53/AE3fstsTh
 /Ls8vIVuf6nh9h3WV2vYbbRrcN2OaJ1MrzadjYcTu52x+wUTWLZHyNEokuo/rstEL6XW
 4Rd0kJqjSfVlkWZSsggY/gIJItZfx8dqKe/tIM11JvJMZtz534kqIUKfQdwU6GnjgsKi
 bdXQ==
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=bIVFYwTWQeFy1BBnCMEZDheS/lU/V0zvGxWyY5EO07o=;
 b=I4pQNfHtv82N6aDqQZVIaL10YfPs3P39HPG1A4QnEmWo8W8CYXA4hv4ALEd3iJzORV
 oAVIDVblZsEfPjeh423+Ex8n7ac0qcvcp3oP8Mps6+Gyo2R9pkDVZTNxnviiOyLP/mU1
 K9oFqYgdSXw6FqamwZAFT41BDrqrfgU40xosQyvJ4bSPpQQTlA1dUEuYF2IPKk/G5tGp
 brbRVhbhGQcZoM8+QWWGJ+ia5GupQt0wvl+2D40V0lt3KkTNund+3z2cTqC9i4ic2wEc
 vLF38DDevwVLYSvrtE0GxDKBO1ZVdYC1VOc44FCBXbHsfllAoTjKnnGyTRpl4XaQYs/E
 3UIw==
X-Gm-Message-State: AJIora8hsZmNnbNYHlWzVbTnorcT6pxf22eCo3DFXuudx7xu90lxc2eL
 g5CCtf1fRbkQueaCcZAR6ohOHp1F34dNqPBACGF2S3LAYHs=
X-Google-Smtp-Source: AGRyM1tWQ2hEo1av/hdkL45rZPVSBeC2N90iqEkZL3O67CfGnv/Rik+b0mSMDHtGpWAFRh3Xh5usqaJUPgOookOAO00=
X-Received: by 2002:a05:6e02:1645:b0:2d6:5dd3:e627 with SMTP id
 v5-20020a056e02164500b002d65dd3e627mr4381715ilu.268.1655429668535; Thu, 16
 Jun 2022 18:34:28 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GOh-7weEypT9JrzcwthZJqHOfj7sf9FMuqi5_FZv0g7w@mail.gmail.com>
 <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
In-Reply-To: <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 17 Jun 2022 02:34:17 +0100
Message-ID: <CALZpt+FJ-R9yCoMLP=Vcxk1U7n=-LKHUGctFZj0K-vTMsz==ew@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000058024005e19ac1cf"
X-Mailman-Approved-At: Fri, 17 Jun 2022 09:02:02 +0000
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: Fri, 17 Jun 2022 01:34:33 -0000

--00000000000058024005e19ac1cf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi alicexbt,


Thanks for taking time to review the pull request,


> 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?


Your Lightning node software relies on far more software and hardware
components than the transaction-relay p2p network. One could list the
operating system on which is running your Lightning process or the compiler
toolchain turning out your Lightning source code in a binary artifact. Some
weird kernel's memory mapping change could allow access to your channel
funding keys, _without_ breaking the Bitcoin consensus rules [0]. Moreover,
your Lightning node is also relying on the existence of a global Internet
allowing your HTLC transaction to flow from your physical host to the crowd
of transactions confirming in the blockchain. Due to this "protocol
assumption" your channel balance would be vulnerable to any change in your
ISP routing policy, e.g refusing to accept your IPV4 traffic by a
sudden desiderata
to impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus
rules. Of course, the odds of your ISP operator adopting this behavior are
really low, mostly because your operator has to bind to social and economic
constraints to stay in business.


And I believe this imperative to stay in business is certainly not absent
in the incentives of the Bitcoin node operators. You're free to run any
policy on your node, especially one hardening the safety of your
operations beyond
the default one. However, if you start to a transaction-relay
non-compatible with miner incentives, you won't have an efficient view of
the blockspace demand, and from then won't be able to offer compelling
feerates to execute your business transactions to satisfy your client
needs. Or you won't consolidate your wallet UTXOs at times of low-demand.
Indeed, a sane visibility of the mempools might not be critical now for you=
r
Bitcoin operations, but this is not likely to become true with miner's
coinbase reward lowering with time and the system security relying on a
fruitful fee market.


So assuming there is a significant number of economically rational entities
running p2p nodes, I think it's a reasonable assumption for Lightning
developers that a policy maximizing miner's income and economic nodes
operations
will be widely run on the p2p network, and therefore lay its security model
on that. When there is a gap between the economically optimal policy
(full-rbf) and the effectively deployed one (optin), and this gap constitut=
es
a flaw for exploitation, I believe it's better to fix it.


If you have a different mode of thinking w.r.t how we should design
protocol in a trust-minimized, open, adversarial environment such as
Bitcoin, I'm curious to listen to it.


> If I write a python script that expects user to enter char 'a' or 'b' but
user can enter 'c' and there is no code to handle exceptions or other
chars, will it be secure?


Of course not. If you deliver any critical software, you should attach a
solid manual explaining all the corner cases and rough edges. Even better
would be to enshrine the manual directly in your software API to minimize
the footgunish behaviors. E.g, with any ECC library, forbidding to reuse
nonces. If your user still ignores or misread the manual and provides an
insecure input, there is not that much you can do.


By analogy, I believe that's the same with Lightning. One recommendation of
the deployment manual would be to be always connected to a full-rbf
transaction-relay topology. Defaulting to this rule and your node exposes
far more surface of attacks. Assuming the manual has been well-written (big
assumption!), I don't think the system designer would be to blame.


That said, one issue to confess with current Lightning is our lack of
understanding of what should be figured out in the LN user manual for safe
operations. I would say that's an active area of research [1] [2] [3]


> 2)full-rbf is not default in the 2 open pull requests, so this experiment
still relies on users changing RBF policies manually. If majority of nodes
use default opt-in policy, how would this affect vulnerable projects?


If we define the goal as ensuring there is a significant number of
transaction-relay routes between the L2s nodes requiring full-rbf and the
set of miners supporting this policy, and the set of miners is populated
enough, there is no need to convince the majority of nodes operators to
switch to full-rbf.


Beyond landing the 'full-rbf' pull request, in pursuit of a partial
full-rbf deployment, I'm thinking of reaching out to Lightning vendors to
recommend running LN nodes operators run their full-node with the setting
enabled. And also to few mining pool operators to advocate the potential
increase in their income.


Given there are like 17000 public LN nodes, if half of them adopt full-rbf
it should give already a good number of full-rbf transaction-relay routes
across the p2p network graph. When we're there, we can measure and think
more about how to tune the full-rbf sub-topology.


> 2-3% transactions are replaced with opt-in RBF, if someone did not
replace earlier why would they do it with full RBF?


Because it's breaking the reliability and security of their use-cases.
Use-cases which didn't exist a few years ago. The mempool DoS vector is
described here [4]. To the best of my understanding, it might affect a
bunch of use-cases, such as dual-funded channels, on-chain DLCs, p2p
coinjoins, batched submarine swaps out. With the attack described, the
honest set of users might not have visibility of the network mempools that
there is a malicious, low-cost, opt-out double-spend preventing the
propagation of their multi-party transaction. With the existence of a
full-rbf transaction-relay topology, the multi-party transaction is able to
replace the optout.


None of those use-cases were deployed a few years ago, and the
understanding of the interactions with the mempool policy is still nascent
among their operators. However, if we assume that layering is a way to grow=
 the
Bitcoin ecosystem, as I do, it is reasonable to expect they will constitute
a notable share of the Bitcoin transaction traffic during the next decade.


> I am not opposed to full-rbf; rather, I am opposed to the notion that
full-rbf will solve all problems


I wished we had a magic Silver Bullet (tm) solving all the Bitcoin
problems...


I'm only advocating a partial full-rbf deployment to solve a real precise
security issue affecting multi-party funded transactions. That said,
full-rbf is far from solving the known set of problems affecting the L2s
due to interactions with network mempools. E,g, see package relay
motivation [5]


> 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.


Selecting a full-node to underpin any serious Bitcoin infrastructure or
secure a significant stack of coins should be submitted to a fully-fledged
decision-making process. Many factors are likely to matter such as the
level of activity of the contributor community, the chain of trust w.r.t
dependencies, the security incident track records, the quality of the
documentation, the exhaustivity and robustness of the set of features, ...


This process might take tens of hours, to be duplicated by the number of
node operators who would have to do the full-node vending switch. If you
consider the cognitive cost at the level of the Bitcoin ecosystem, it's far
less costly to implement and review a few lines of codes in Bitcoin Core.


> 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.


Of course, this statement assumes there is a clear line between the
developers and the users. Developers are also Bitcoin users, and they're
modifying the software to suit their use-case needs. And that's exactly the
purpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good"
policy for a Lightning node, without actually seeking to change the
default. If they're parties interested in implementing more RBF policy
options in Bitcoin Core, I think they're free to propose such changes and
invest the engineering effort to do so. If you're interested in advancing
the state of policy options in Bitcoin Core, there are a lot of interesting
resources available and communities to encourage you in the learning
process to contribute to the codebase [6].


Antoine


[0] https://dirtycow.ninja

[1] https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md

[2] https://arxiv.org/pdf/2006.01418.pdf

[3] https://arxiv.org/pdf/2006.08513.pdf

[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.h=
tml

[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.htm=
l

[6] https://www.summerofbitcoin.org


Le jeu. 16 juin 2022 =C3=A0 00:15, alicexbt <alicexbt@protonmail.com> a =C3=
=A9crit :

> Hi Antoine,
>
>
> Thanks for opening the pull request to add support for full-rbf in Bitcoi=
n
> Core. I have a disagreements with the approach and questions.
>
> Recent discussions among LN devs have brought back on the surface concern=
s
> about the security of multi-party 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].
>
>
> 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? I=
f
> I write a python script that expects user to enter char 'a' or 'b' but us=
er
> 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 experiment
> still relies on users changing RBF policies manually. If majority of node=
s
> use default opt-in policy, how would this affect vulnerable projects?
>
> If you're a mining operator looking to increase your income, you might be
> 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 now even with full RBF? Or even if we add so=
me
> users in it who could not signal for some reasons, do you think it would =
be
> anything 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 feedback
> 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, howeve=
r
> 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 Bitcoin
> Core to employ/disable different RBF policies. There is also a speculatio=
n
> 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 polic=
y.
> 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 the
> 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 it
> 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 concern=
s
> about the security of multi-party 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 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 lo=
ss
> 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-par=
ty
> transactions to the interested miners, replacing potential non-signaling
> double-spend from a malicious counterparty. Moving 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]. 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 outbound
> slots for them).
>
> If you're a mining operator looking to increase your income, you might be
> interested to experiment with full-rbf as a policy. Indeed, in the future=
 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 feedback
> 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, howeve=
r
> 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/003033=
.html
>
> [2] E.g I think it does not affect the Lightning Pool service, as there i=
s
> 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 batch
> transaction.
>
> [3] https://github.com/bitcoin/bitcoin/pull/25353
>
> [4] E.g DLCs :
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions=
.md
> ; Lightning dual-funded channel :
> https://github.com/lightning/bolts/pull/851
>
>
>

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

<div dir=3D"ltr"><p style=3D"margin:0px;font-stretch:normal;line-height:nor=
mal;color:rgb(0,0,0)"><span style=3D"font-variant-ligatures:no-common-ligat=
ures"><font face=3D"arial, sans-serif">Hi alicexbt,</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Thanks for taking time to review the pull request,</=
font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; 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?<span class=3D"gmail-Apple-converted-space">=C2=A0</sp=
an></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Your Lightning node software relies on far more soft=
ware and hardware components than the transaction-relay p2p network.=C2=A0<=
/font></span><span style=3D"font-family:arial,sans-serif">One could list th=
e operating system on which is running your Lightning process or the compil=
er toolchain turning out=C2=A0</span><span style=3D"font-family:arial,sans-=
serif">your Lightning source code in a binary artifact. Some weird kernel&#=
39;s memory mapping change could allow access to=C2=A0</span><span style=3D=
"font-family:arial,sans-serif">your channel funding keys, _without_ breakin=
g the Bitcoin consensus rules [0]. Moreover, your Lightning node is also=C2=
=A0</span><span style=3D"font-family:arial,sans-serif">relying on the exist=
ence of a global Internet allowing your HTLC transaction to flow from your =
physical host=C2=A0</span><span style=3D"font-family:arial,sans-serif">to t=
he crowd of transactions confirming in the blockchain. Due to this &quot;pr=
otocol assumption&quot; your channel balance=C2=A0</span><span style=3D"fon=
t-family:arial,sans-serif">would be vulnerable to any change in your ISP ro=
uting policy, e.g refusing to accept your IPV4 traffic by a sudden=C2=A0</s=
pan><span style=3D"font-family:arial,sans-serif">desiderata to impose an IP=
V6 supremacy. Still _without_ breaking the Bitcoin consensus rules. Of cour=
se, the odds of=C2=A0</span><span style=3D"font-family:arial,sans-serif">yo=
ur ISP operator adopting this behavior are really low, mostly because your =
operator has to bind to social and=C2=A0</span><span style=3D"font-family:a=
rial,sans-serif">economic constraints to stay in business.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">And I believe this imperative to stay in business is=
 certainly not absent in the incentives of the Bitcoin node=C2=A0</font></s=
pan><span style=3D"font-family:arial,sans-serif">operators. You&#39;re free=
 to run any policy on your node, especially one hardening the safety of you=
r operations</span><span class=3D"gmail-Apple-converted-space" style=3D"fon=
t-family:arial,sans-serif">=C2=A0</span><span style=3D"font-family:arial,sa=
ns-serif">beyond the default one. However, if you start to a transaction-re=
lay non-compatible with miner incentives, you=C2=A0</span><span style=3D"fo=
nt-family:arial,sans-serif">won&#39;t have an efficient view of the blocksp=
ace demand, and from then won&#39;t be able to offer compelling feerates=C2=
=A0</span><span style=3D"font-family:arial,sans-serif">to execute your busi=
ness transactions to satisfy your client needs. Or you won&#39;t consolidat=
e your=C2=A0</span><span style=3D"font-family:arial,sans-serif">wallet UTXO=
s at </span>times<span style=3D"font-family:arial,sans-serif"> of low-deman=
d. Indeed, a sane visibility of the mempools might not be critical now for=
=C2=A0</span><span style=3D"font-family:arial,sans-serif">your Bitcoin oper=
ations, but this is not likely to become true with miner&#39;s coinbase rew=
ard lowering with time=C2=A0</span><span style=3D"font-family:arial,sans-se=
rif">and the system security </span>relying<span style=3D"font-family:arial=
,sans-serif"> on a fruitful fee market.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">So assuming there is a significant number of economi=
cally rational entities running p2p nodes, I think it&#39;s a=C2=A0</font><=
/span><span style=3D"font-family:arial,sans-serif">reasonable assumption fo=
r Lightning developers that a policy maximizing miner&#39;s income and econ=
omic nodes=C2=A0</span><span style=3D"font-family:arial,sans-serif">operati=
ons will be widely run on the p2p network, and therefore lay its security m=
odel on that. When there is a=C2=A0</span><span style=3D"font-family:arial,=
sans-serif">gap between the economically optimal policy (full-rbf) and the =
effectively deployed one (optin), and this gap=C2=A0</span><span style=3D"f=
ont-family:arial,sans-serif">constitutes a flaw for exploitation, I believe=
 it&#39;s better to fix it.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">If you have a different mode of thinking w.r.t how w=
e should design protocol in a trust-minimized, open,=C2=A0</font></span><sp=
an style=3D"font-family:arial,sans-serif">adversarial</span><span class=3D"=
gmail-Apple-converted-space" style=3D"font-family:arial,sans-serif">=C2=A0<=
/span><span style=3D"font-family:arial,sans-serif">environment such as Bitc=
oin, I&#39;m curious to listen to it.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; If I write a python script that expects user to=
 enter char &#39;a&#39; or &#39;b&#39; but user can enter &#39;c&#39; and t=
here is no code to handle exceptions or other chars, will it be secure?</fo=
nt></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Of course not. If you deliver any critical software,=
 you should attach a solid manual explaining all the=C2=A0</font></span><sp=
an style=3D"font-family:arial,sans-serif">corner cases and rough edges. Eve=
n better would be to enshrine the manual directly in your software API=C2=
=A0</span><span style=3D"font-family:arial,sans-serif">to minimize the foot=
gunish behaviors. E.g, with any ECC library, forbidding to reuse nonces. If=
 your=C2=A0</span>user<span style=3D"font-family:arial,sans-serif"> still i=
gnores or misread the manual and provides an insecure input, there is </spa=
n>not that<span style=3D"font-family:arial,sans-serif"> much you can do.</s=
pan></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">By analogy, I believe that&#39;s the same with Light=
ning. One recommendation of the deployment manual would=C2=A0</font></span>=
<span style=3D"font-family:arial,sans-serif">be to be always connected to a=
 full-rbf transaction-relay topology. Defaulting to this rule and your node=
=C2=A0</span><span style=3D"font-family:arial,sans-serif">exposes far more =
surface of attacks. Assuming the manual has been well-written (big assumpti=
on!), I don&#39;t t</span><span style=3D"font-family:arial,sans-serif">hink=
 the system designer would be to blame.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">That said, one issue to confess with current Lightni=
ng is our lack of understanding of what should be figured out in=C2=A0</fon=
t></span><span style=3D"font-family:arial,sans-serif">the LN user manual fo=
r safe operations. I would say that&#39;s an active area of research [1] [2=
] [3]</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; 2)full-rbf is not default in the 2 open pull re=
quests, so this experiment still relies on users changing RBF policies manu=
ally. If majority of nodes use default opt-in policy, how would this affect=
 vulnerable projects?</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">If we define the goal as ensuring there is a signifi=
cant number of transaction-relay routes=C2=A0</font></span><span style=3D"f=
ont-family:arial,sans-serif">between the L2s nodes requiring full-rbf and t=
he set of miners supporting this policy, and=C2=A0</span><span style=3D"fon=
t-family:arial,sans-serif">the set of miners is populated enough, there is =
no need to convince the majority of nodes=C2=A0</span><span style=3D"font-f=
amily:arial,sans-serif">operators to switch to full-rbf.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Beyond landing the &#39;full-rbf&#39; pull request, =
in pursuit of a partial full-rbf deployment,=C2=A0</font></span><span style=
=3D"font-family:arial,sans-serif">I&#39;m thinking of reaching out to Light=
ning vendors to recommend running LN nodes operators</span><span class=3D"g=
mail-Apple-converted-space" style=3D"font-family:arial,sans-serif">=C2=A0</=
span><span style=3D"font-family:arial,sans-serif">run their full-node with =
the setting enabled. And also to few mining pool operators to=C2=A0</span><=
span style=3D"font-family:arial,sans-serif">advocate the potential increase=
 in their income.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Given there are like 17000 public LN nodes, if half =
of them adopt full-rbf it should give=C2=A0</font></span><span style=3D"fon=
t-family:arial,sans-serif">already a good number of full-rbf transaction-re=
lay routes across the p2p network graph.=C2=A0</span><span style=3D"font-fa=
mily:arial,sans-serif">When we&#39;re there, we can measure and think more =
about how to tune the full-rbf sub-topology.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; 2-3% transactions are replaced with opt-in RBF,=
 if someone did not replace earlier why would they do it with full RBF?</fo=
nt></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Because it&#39;s breaking the reliability and securi=
ty of their use-cases. Use-cases which didn&#39;t exist=C2=A0</font></span>=
<span style=3D"font-family:arial,sans-serif">a few years ago. The mempool D=
oS vector is described here [4]. To the best of my understanding, it might=
=C2=A0</span><span style=3D"font-family:arial,sans-serif">affect a bunch of=
 use-cases, such as dual-funded channels, on-chain DLCs, p2p </span>coinjoi=
ns<span style=3D"font-family:arial,sans-serif">, batched submarine=C2=A0</s=
pan><span style=3D"font-family:arial,sans-serif">swaps out. With the attack=
 described, the honest set of users might not have visibility of the networ=
k=C2=A0</span><span style=3D"font-family:arial,sans-serif">mempools that th=
ere is a malicious, low-cost, opt-out double-spend preventing the propagati=
on of their multi-party=C2=A0</span><span style=3D"font-family:arial,sans-s=
erif">transaction. With the existence of a full-rbf transaction-relay topol=
ogy, the multi-party transaction=C2=A0</span><span style=3D"font-family:ari=
al,sans-serif">is able to replace the </span>optout<span style=3D"font-fami=
ly:arial,sans-serif">.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">None of those use-cases were deployed a few years ag=
o, and the understanding of the interactions with the=C2=A0</font></span><s=
pan style=3D"font-family:arial,sans-serif">mempool policy is still nascent =
among their operators. However, if we assume that layering is a way to grow=
=C2=A0</span><span style=3D"font-family:arial,sans-serif">the Bitcoin ecosy=
stem, as I do, it is reasonable to expect they will constitute a notable sh=
are of the=C2=A0</span><span style=3D"font-family:arial,sans-serif">Bitcoin=
 transaction traffic during the next decade.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; I am not opposed to full-rbf; rather, I am oppo=
sed to the notion that full-rbf will solve all problems</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">I wished we had a magic Silver Bullet (tm) solving a=
ll the Bitcoin problems...</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">I&#39;m only advocating a partial full-rbf deploymen=
t to solve a real precise security issue affecting=C2=A0</font></span><span=
 style=3D"font-family:arial,sans-serif">multi-party funded transactions. Th=
at said, full-rbf is far from solving the known set of problems=C2=A0</span=
><span style=3D"font-family:arial,sans-serif">affecting the L2s due to inte=
ractions with network mempools. E,g, see package relay motivation [5]</span=
></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; I would suggest users to try Bitcoin Knots inst=
ead which already has an option to disable all RBF policies if required, op=
t-in and full RBF policy.</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Selecting a full-node to underpin any serious Bitcoi=
n infrastructure or secure a significant stack of coins=C2=A0</font></span>=
<span style=3D"font-family:arial,sans-serif">should be submitted to a fully=
-fledged decision-making process. Many factors are likely to </span>matter<=
span style=3D"font-family:arial,sans-serif"> such as=C2=A0</span><span styl=
e=3D"font-family:arial,sans-serif">the level of activity of the contributor=
 community, the chain of trust w.r.t dependencies, the security incident t<=
/span><span style=3D"font-family:arial,sans-serif">rack records, the qualit=
y of the documentation, the exhaustivity and robustness of the set of featu=
res, ...</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">This process might take tens of hours, to be duplica=
ted by the number of node operators who would have to=C2=A0</font></span><s=
pan style=3D"font-family:arial,sans-serif">do the full-node vending switch.=
 If you consider the cognitive cost at the level of the Bitcoin=C2=A0</span=
><span style=3D"font-family:arial,sans-serif">ecosystem, it&#39;s far less =
costly to implement and </span>review a few<span style=3D"font-family:arial=
,sans-serif"> lines of codes in Bitcoin Core.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; Developers should provide basic RBF policy opti=
ons rather than attempting to define what constitutes a good policy and rem=
oving the ability to disable something when necessary.</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Of course, this statement assumes there is a clear l=
ine between the developers and the users. Developers=C2=A0</font></span><sp=
an style=3D"font-family:arial,sans-serif">are also Bitcoin users, and they&=
#39;re modifying the software to suit their use-case needs. And that&#39;s =
exactly=C2=A0</span><span style=3D"font-family:arial,sans-serif">the purpos=
e of the &#39;full-rbf&#39; PR I&#39;m proposing, aiming to propose a &quot=
;good&quot; policy for a Lightning node, without actually seeking to change=
 the default. If they&#39;re=C2=A0</span><span style=3D"font-family:arial,s=
ans-serif">parties interested in implementing more RBF policy options in Bi=
tcoin Core, I think they&#39;re free to propose such=C2=A0</span><span styl=
e=3D"font-family:arial,sans-serif">changes and invest the engineering effor=
t to do so. If you&#39;re interested in advancing the state of=C2=A0</span>=
<span style=3D"font-family:arial,sans-serif">policy options in Bitcoin Core=
, there are a lot of interesting </span>resources<span style=3D"font-family=
:arial,sans-serif"> available and communities to=C2=A0</span><span style=3D=
"font-family:arial,sans-serif">encourage you in the learning process to con=
tribute to the codebase [6].</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Antoine</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[0] <a href=3D"https://dirtycow.ninja">https://dirty=
cow.ninja</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[1] <a href=3D"https://github.com/t-bast/lightning-d=
ocs/blob/master/pinning-attacks.md">https://github.com/t-bast/lightning-doc=
s/blob/master/pinning-attacks.md</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[2] <a href=3D"https://arxiv.org/pdf/2006.01418.pdf"=
>https://arxiv.org/pdf/2006.01418.pdf</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[3] <a href=3D"https://arxiv.org/pdf/2006.08513.pdf"=
>https://arxiv.org/pdf/2006.08513.pdf</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[4] <a href=3D"https://lists.linuxfoundation.org/pip=
ermail/lightning-dev/2021-May/003033.html">https://lists.linuxfoundation.or=
g/pipermail/lightning-dev/2021-May/003033.html</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[5] <a href=3D"https://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2022-May/020493.html">https://lists.linuxfoundation.org/=
pipermail/bitcoin-dev/2022-May/020493.html</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[6] <a href=3D"https://www.summerofbitcoin.org">http=
s://www.summerofbitcoin.org</a></font></span></p>
<br class=3D"gmail-Apple-interchange-newline"></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 16 juin 2022 =C3=
=A0=C2=A000:15, alicexbt &lt;<a href=3D"mailto:alicexbt@protonmail.com">ali=
cexbt@protonmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)">Hi Anto=
ine,</div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34=
)"><br></div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34=
,34)"><br></div><div style=3D"font-family:arial;font-size:14px;color:rgb(34=
,34,34)">Thanks for opening the pull request to add support for full-rbf in=
 Bitcoin Core. I have a disagreements with the approach and questions.</div=
><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><br></=
div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><bl=
ockquote type=3D"cite" style=3D"padding:0px 0px 0px 1rem;margin:0px;border-=
left-width:4px;border-left-style:solid;border-left-color:rgb(229,229,229);c=
olor:rgb(0,0,0);font-family:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans=
-serif;background-color:rgb(255,255,255)"><span dir=3D"ltr">Recent discussi=
ons among LN devs have brought back on the surface concerns about the secur=
ity of multi-party funded transactions (coinjoins, dual-funded LN channels,=
 on-chain DLCs, ...). It turns out there is a low-fruit, naive DoS vector p=
layable against the funding flow of any such construction due to the lack o=
f existent full-rbf transaction-relay topology on today&#39;s p2p network [=
0] [1].<span>=C2=A0</span></span></blockquote><br></div><div style=3D"font-=
family:arial;font-size:14px;color:rgb(34,34,34)">1)If something relies on a=
 policy which can be changed without breaking consensus rules, how is it se=
cure in any case with or without full rbf? If I write a python script that =
expects user to enter char &#39;a&#39; or &#39;b&#39; but user can enter &#=
39;c&#39; and there is no code to handle exceptions or other chars, will it=
 be secure?=C2=A0=C2=A0</div><div style=3D"font-family:arial;font-size:14px=
;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:1=
4px;color:rgb(34,34,34)">2)full-rbf is not default in the 2 open pull reque=
sts, so this experiment still relies on users changing RBF policies manuall=
y. If majority of nodes use default opt-in policy, how would this affect vu=
lnerable projects?</div><div style=3D"font-family:arial;font-size:14px;colo=
r:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;c=
olor:rgb(34,34,34)"><blockquote type=3D"cite" style=3D"padding:0px 0px 0px =
1rem;margin:0px;border-left-width:4px;border-left-style:solid;border-left-c=
olor:rgb(229,229,229);color:rgb(0,0,0);font-family:Arial,&quot;Helvetica Ne=
ue&quot;,Helvetica,sans-serif;background-color:rgb(255,255,255)"><span dir=
=3D"ltr">If you&#39;re a mining operator looking to increase your income, y=
ou might be interested to experiment with full-rbf as a policy.</span></blo=
ckquote><br></div><div style=3D"font-family:arial;font-size:14px;color:rgb(=
34,34,34)">Miners can only increase their income if users replace transacti=
ons. 2-3% transactions are replaced with opt-in RBF, if someone did not rep=
lace earlier why would they do it now even with full RBF? Or even if we add=
 some users in it who could not signal for some reasons, do you think it wo=
uld be anything above 5%?</div><div style=3D"font-family:arial;font-size:14=
px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-size=
:14px;color:rgb(34,34,34)"><blockquote type=3D"cite" style=3D"padding:0px 0=
px 0px 1rem;margin:0px;border-left-width:4px;border-left-style:solid;border=
-left-color:rgb(229,229,229);color:rgb(0,0,0);font-family:Arial,&quot;Helve=
tica Neue&quot;,Helvetica,sans-serif;background-color:rgb(255,255,255)"><sp=
an dir=3D"ltr">If you&#39;re a Bitcoin user or business and you don&#39;t l=
ike full-rbf, please express an opinion on how it might affect your softwar=
e/operations. I&#39;m always interested to learn more about mempool and tra=
nsaction-relay interactions with upper-layers and applications and to liste=
n to feedback in those areas, and I guess a lot of other Bitcoin researcher=
s/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"font-family:arial;font-size:14p=
x;color:rgb(34,34,34)"><span>I am not opposed to full-rbf; rather, I am opp=
osed to the notion that full-rbf will solve all problems and the lack of ba=
sic options in Bitcoin Core to employ/disable different RBF policies. There=
 is also a speculation about making full RBF default in an year which isn&#=
39;t relevant to discuss at this point without trying different RBF policie=
s.</span></div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,=
34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;color:rgb(=
34,34,34)">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=
 <code>mempoolreplacement</code>=E2=80=8B.</div><div style=3D"font-family:a=
rial;font-size:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-famil=
y:arial;font-size:14px;color:rgb(34,34,34)"><span>The rationale in PR #1617=
1 was insufficient to justify removing it in the first place, had 2 NACKs a=
nd was reopened to merge it. Why bother with a few lines of code that may a=
llow someone disable it if required in local mempool since it&#39;s only us=
eful when a big percentage of miners utilize it and essentially underused a=
ccording to the PR author? Developers should provide basic RBF policy optio=
ns rather than attempting to define what constitutes a good policy and remo=
ving the ability to disable something when necessary.</span></div><div styl=
e=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><br></div><div s=
tyle=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><br></div><di=
v style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)">/dev/fd0</=
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 Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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&#39;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&#39;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&#39;ve started to run the patch on a public node at 146.=
190.224.15.<br><br>If you&#39;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&#39;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&#39;re a Bitcoin user or business and you don&#39;t like full-=
rbf, please express an opinion on how it might affect your software/operati=
ons. I&#39;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 href=3D"https://bitcoinops.o=
rg/en/topics/replace-by-fee/" rel=3D"noreferrer nofollow noopener" target=
=3D"_blank">https://bitcoinops.org/en/topics/replace-by-fee/</a><br><br>[1]=
 For more details about the DoS vector, see <a href=3D"https://lists.linuxf=
oundation.org/pipermail/lightning-dev/2021-May/003033.html" rel=3D"noreferr=
er nofollow noopener" 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 href=3D"https://github.com/bitcoin/bitcoin/pull/25353" rel=3D"noreferrer =
nofollow noopener" target=3D"_blank">https://github.com/bitcoin/bitcoin/pul=
l/25353</a><br><br>[4] E.g DLCs : <a href=3D"https://github.com/discreetlog=
contracts/dlcspecs/blob/master/Transactions.md" rel=3D"noreferrer nofollow =
noopener" target=3D"_blank">https://github.com/discreetlogcontracts/dlcspec=
s/blob/master/Transactions.md</a> ; Lightning dual-funded channel : <a href=
=3D"https://github.com/lightning/bolts/pull/851" rel=3D"noreferrer nofollow=
 noopener" target=3D"_blank">https://github.com/lightning/bolts/pull/851</a=
><br></div>

        </blockquote><br>
    </div></blockquote></div>

--00000000000058024005e19ac1cf--