summaryrefslogtreecommitdiff
path: root/ac/c432bfd907c7f5eef68ee20737cee4275133f0
blob: f345b38e8f554104835689656828c255aafb3d5d (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
Return-Path: <prayank@tutanota.de>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C3007C000B;
 Mon, 14 Feb 2022 17:59:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id A1B8360AFE;
 Mon, 14 Feb 2022 17:59:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=tutanota.de
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id P-kG4R4ja8td; Mon, 14 Feb 2022 17:59:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 8A4A260672;
 Mon, 14 Feb 2022 17:59:39 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
 by w1.tutanota.de (Postfix) with ESMTP id 94744FBF4F4;
 Mon, 14 Feb 2022 17:59:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1644861577; 
 s=s1; d=tutanota.de;
 h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;
 bh=pzkHbuHhIapVVukvhtvdzaDH+025dQeEEs/ZXd97Gr8=;
 b=m00H9Cg6iBg8mlShNdLo7Oz+XOEi2c2ON3OFH5eoadEa8LuFOPe1quB0prvBvwj1
 4/8TJf7m9sNrZcGLxg0oUR7d1Xd0yO24L+AJyBktSsAxc7gpTZpEzbiWpvLLI1tOQIr
 fnmO4mAHQrXZlkGawoDf6dGEzdV35FBGidHuj65ohYhCZ1UpFfO/8iLWvHY4B/Fuhhj
 1v177UHTKkFSbm0VQrGkL0RS/mgd3fPDozZxK/4RuImWcgSnLJe4+HQE7Cs/g5xvXFz
 frtALUnKP/XvrT/S8OMx1LTxHkKO7lDstksuhXW6E2KtBSeG9ORS9o4Nw0aPQusxujF
 AEgH2eq6Zg==
Date: Mon, 14 Feb 2022 18:59:37 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <MvtNxL0--3-2@tutanota.de>
In-Reply-To: <bVli6fbpw1DaoPi7BqJrwWoAaseanAgWiNFQ7zyL3uOkxk2d1Kv4OCEOXzZxK5ir-p4qyvyFsd4BebPEvrYCP_2jyJ147EtyTWIVpH13dKE=@protonmail.com>
References: <MvlgjLW--3-2@tutanota.de>
 <aTVwIe_-6PUKYZ4btOUF8axaX_CzpStUta2_mOzX_5nN1NomU_OinXIRFHsswr7-O-C-i60ViTfeAyLVxYH490YZo65m8hlUy9KnY5OPEwo=@protonmail.com>
 <Mvqek99--B-2@tutanota.de>
 <bVli6fbpw1DaoPi7BqJrwWoAaseanAgWiNFQ7zyL3uOkxk2d1Kv4OCEOXzZxK5ir-p4qyvyFsd4BebPEvrYCP_2jyJ147EtyTWIVpH13dKE=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_259166_1108191932.1644861577583"
X-Mailman-Approved-At: Mon, 14 Feb 2022 18:03:33 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
 Lightning Dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2
 projects with multiple RBF policies
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: Mon, 14 Feb 2022 17:59:41 -0000

------=_Part_259166_1108191932.1644861577583
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> That's not an argument not to do it though if you take a longer term pers=
pective on building the strongest possible foundation for Lightning or othe=
r Layer 2 projects. The security benefit would just be delayed until a sign=
ificant majority of Bitcoin Core users upgraded to a version including thos=
e new policy rules.

1.An attacker does not require significant majority for such attacks.=20
2.We aren't fixing the things that are broken. We can change the policy in =
core several times and still not achieve the goal and maybe create new issu=
es.

> A network where *all* full nodes are running the same policy rules is cle=
arly not an option available to us without making policy rules effective co=
nsensus rules and forking/kicking those old versions off the network.

A network with a policy already widely used exists right now.=20

> Definitely agree. It is a really interesting research area and lots of op=
portunities for simulations and experiments on the default or custom signet=
 networks. Especially if we fill blocks with auto-generated transactions an=
d/or reduce block sizes and create an artificial fee market.

I don't think I can convince everyone to do this however it will be helpful=
. I will try a few things on regtest and share results if I find anything i=
nteresting.


--=20
Prayank

A3B1 E430 2298 178F



Feb 14, 2022, 22:32 by michaelfolkson@protonmail.com:

> > This is the assumption which I don't agree with and hence asked some qu=
estions in my email. A new RBF policy used by default in Core will not impr=
ove the security of projects that are vulnerable to multiple RBF policies o=
r rely on these policies in a way that affects their security.=C2=A0
>
> Right, not immediately. If and when new policy rules are included in a Bi=
tcoin Core release it would take a while before a significant majority of t=
he network were running those new policy rules (barring some kind of urgenc=
y, an attacker exploiting a systemic security flaw etc). That's not an argu=
ment not to do it though if you take a longer term perspective on building =
the strongest possible foundation for Lightning or other Layer 2 projects. =
The security benefit would just be delayed until a significant majority of =
Bitcoin Core users upgraded to a version including those new policy rules.
>
> >=C2=A0> Bitcoin Core with different versions are used at any point and n=
ot sure if this will ever change.
>
> Sure there will always be some stray full nodes running extremely old ver=
sions but the general direction of travel is more and more full nodes upgra=
ding to newer versions. A network where *all* full nodes are running the sa=
me policy rules is clearly not an option available to us without making pol=
icy rules effective consensus rules and forking/kicking those old versions =
off the network.
>
> >=C2=A0> Maybe some experiments on signet might help in knowing more issu=
es associated with multiple RBF policies.
>
> Definitely agree. It is a really interesting research area and lots of op=
portunities for simulations and experiments on the default or custom signet=
 networks. Especially if we fill blocks with auto-generated transactions an=
d/or reduce block sizes and create an artificial fee market.
>
> --
> Michael Folkson
> Email: michaelfolkson at > protonmail.com <http://protonmail.com/>> Keyba=
se: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
>
> ------- Original Message -------
>  On Monday, February 14th, 2022 at 5:18 AM, Prayank <prayank@tutanota.de>=
 wrote:
> =20
>
>> > I suspect as with defaults generally most users will run whatever the =
defaults are as they won't care to change them (or even be capable of chang=
ing them if they are very non-technical).
>>
>>
>> 30% nodes are using 0.21.1 right now whereas latest version was 22.0 and=
 some are even running lower versions. Different versions in future with de=
faults might be running RBF v1 and RBF v2.
>>
>> > But users who have a stake in the security of Lightning (or other Laye=
r 2 projects) will clearly want to run whatever policy rules are beneficial=
 to those protocols.
>>
>>
>> Agree and attackers will want to run the nodes with policy that helps th=
em exploit bitcoin projects. Miners can run nodes with policy that helps th=
em get more fees.=C2=A0
>>
>> > As you know the vast majority of the full nodes on the network current=
ly run Bitcoin Core. Whether that will change in future and whether this a =
good thing or not is a whole other discussion. But the reality is that with=
 such strong dominance there is the option to set defaults that are widely =
used.
>>
>>
>> Bitcoin Core with different versions are used at any point and not sure =
if this will ever change.
>>
>> https://luke.dashjr.org/programs/bitcoin/files/charts/security.html
>>
>> https://www.shodan.io/search/facet.png?query=3DUser-Agent%3A%2FSatoshi%2=
F+port%3A%228333%22&facet=3Dproduct
>>
>> > I think if certain defaults can bolster the security of Lightning (and=
 possibly other Layer 2 projects) at no cost to full node users with no int=
erest in those protocols we should discuss what those defaults should be.
>>
>>
>> This is the assumption which I don't agree with and hence asked some que=
stions in my email. A new RBF policy used by default in Core will not impro=
ve the security of projects that are vulnerable to multiple RBF policies or=
 rely on these policies in a way that affects their security.=C2=A0
>>
>> Maybe some experiments on signet might help in knowing more issues assoc=
iated with multiple RBF policies.
>>
>> --=20
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>>
>> Feb 13, 2022, 21:16 by michaelfolkson@protonmail.com:
>>
>>> Hi Prayank
>>>
>>> > 1.Is Lightning Network and a few other layer 2 projects vulnerable to=
 multiple RBF policies being used?
>>>
>>> Clearly the security of the Lightning Network and some other Layer 2 pr=
ojects are at least impacted or partly dependent on policy rules in a way t=
hat the base blockchain/network isn't. As I (and others) have said on many =
occasions ideally this wouldn't be the case but it is best we can do with c=
urrent designs. I (and others) take the view that this is not a reason to a=
bandon those designs in the absence of an alternative that offers a strictl=
y superior security model. Going back to a model where *all* activity is on=
chain (or even in less trust minimized protocols than Lightning) doesn't se=
em like the right approach to me.
>>>
>>> > 2.With recent discussion to change things in default RBF policy used =
by Core, will we have multiple versions using different policies? Are users=
 and especially miners incentivized to use different versions and policies?=
 Do they have freedom to use different RBF policy?
>>>
>>> Without making policy rules effective consensus rules users (including =
miners) are free to run different policy rules. I think it is too early to =
say what the final incentives will be to run the same or differing policies=
. Research into Lightning security is still nascent and we have no idea whe=
ther alternative Layer 2 projects will thrive and whether they will have th=
e same or conflicting security considerations to Lightning.=20
>>>
>>> As you know the vast majority of the full nodes on the network currentl=
y run Bitcoin Core. Whether that will change in future and whether this a g=
ood thing or not is a whole other discussion. But the reality is that with =
such strong dominance there is the option to set defaults that are widely u=
sed. I think if certain defaults can bolster the security of Lightning (and=
 possibly other Layer 2 projects) at no cost to full node users with no int=
erest in those protocols we should discuss what those defaults should be.
>>>
>>> > 3.Are the recent improvements suggested for RBF policy only focused o=
n Lightning Network and its security which will anyway remain same or becom=
e worse with multiple RBF policies?
>>>
>>> I think by nature of the Lightning Network being the most widely adopte=
d Layer 2 project most of the focus has been on Lightning security. But con=
tributors to other Layer 2 projects are free to flag and discuss security c=
onsiderations that aren't Lightning specific.
>>>
>>> > Note: Bitcoin Knots policy is fully configurable, even in the GUI - u=
sers can readily choose whatever policy *they* want.
>>>
>>> The maintainer(s) and contributors to Bitcoin Knots are free to determi=
ne what default policy rules they want to implement (and make it easier for=
 users to change those defaults) in the absence of those policy rules being=
 made effective consensus rules. I suspect there would be strong opposition=
 to making some policy rules effective consensus rules but we are now ventu=
ring again into future speculation and none of us have a crystal ball. Cert=
ainly if you take the view that these policy rules should never be made eff=
ective consensus rules then the fact there is at least one implementation t=
aking a contrasting approach to Core is a good thing.
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at >>> protonmail.com <http://protonmail.com/>>>>=
 Keybase: michaelfolkson
>>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>>
>>>
>>> ------- Original Message -------
>>> On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <l=
ightning-dev@lists.linuxfoundation.org> wrote:
>>>
>>>
>>>> Hello World,
>>>>
>>>> There was a discussion about improving fee estimation in Bitcoin Core =
last year in which 'instagibbs' mentioned that we cannot consider mempool a=
s an orderbook in which which everyone is bidding for block space because n=
odes can use different relay policies: https://bitcoin-irc.chaincode.com/bi=
tcoin-core-dev/2021-09-22#706294;
>>>>
>>>> Although I still don't consider fee rates used in last few blocks rele=
vant for fee estimation, it is possible that we have nodes with different r=
elay policies.
>>>>
>>>> Similarly if we have different RBF policies being used by nodes in fut=
ure, how would this affect the security of lightning network implementation=
s and other layer 2 projects?=20
>>>>
>>>> Based on the things shared by 'aj' in=20
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/=
019846.html it is possible for an attacker to use a different RBF policy wi=
th some nodes, 10% hash power and affect the security of different projects=
 that rely on default RBF policy in latest Bitcoin Core.
>>>>
>>>> There was even a CVE in which RBF policy not being documented accordin=
g to the implementation could affect the security of LN:=20
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/01889=
3.html
>>>>
>>>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to =
multiple RBF policies being used?=20
>>>>
>>>> 2.With recent discussion to change things in default RBF policy used b=
y Core, will we have multiple versions using different policies? Are users =
and especially miners incentivized to use different versions and policies? =
Do they have freedom to use different RBF policy?
>>>>
>>>> 3.Are the recent improvements suggested for RBF policy only focused on=
 Lightning Network and its security which will anyway remain same or become=
 worse with multiple RBF policies?
>>>>
>>>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - us=
ers can readily choose whatever policy *they* want.
>>>>
>>>> --=20
>>>> Prayank
>>>>
>>>> A3B1 E430 2298 178F
>>>>


------=_Part_259166_1108191932.1644861577583
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>&gt; That's not an argument not to do it though if you take a longer t=
erm perspective on building the strongest possible foundation for Lightning=
 or other Layer 2 projects. The security benefit would just be delayed unti=
l a significant majority of Bitcoin Core users upgraded to a version includ=
ing those new policy rules.<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">1.An attacker does not require significant majority for such atta=
cks. <br></div><div dir=3D"auto">2.We aren't fixing the things that are bro=
ken. We can change the policy in core several times and still not achieve t=
he goal and maybe create new issues.<br></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">&gt; A network where *all* full nodes are running the same=
 policy rules is clearly not an option available to us without making polic=
y rules effective consensus rules and forking/kicking those old versions of=
f the network.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">A net=
work with a policy already widely used exists right now. <br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">&gt; Definitely agree. It is a really=
 interesting research area and lots of opportunities for simulations and ex=
periments on the default or custom signet networks. Especially if we fill b=
locks with auto-generated transactions and/or reduce block sizes and create=
 an artificial fee market.<br></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">I don't think I can convince everyone to do this however it will be =
helpful. I will try a few things on regtest and share results if I find any=
thing interesting.<br></div><div dir=3D"auto"><br></div><div><br></div><div=
>-- <br></div><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E=
430 2298 178F<br></div><div><br></div><div><br></div><div><br></div><div>Fe=
b 14, 2022, 22:32 by michaelfolkson@protonmail.com:<br></div><blockquote cl=
ass=3D"tutanota_quote" style=3D"border-left: 1px solid #93A3B8; padding-lef=
t: 10px; margin-left: 5px;"><div style=3D"font-family: arial; font-size: 14=
px;"><div style=3D"font-family: arial; font-size: 14px;">&gt; This is the a=
ssumption which I don't agree with and hence asked some questions in my ema=
il. A new RBF policy used by default in Core will not improve the security =
of projects that are vulnerable to multiple RBF policies or rely on these p=
olicies in a way that affects their security.&nbsp;<br></div><div style=3D"=
font-family: arial; font-size: 14px;"><br></div><div style=3D"font-family: =
arial; font-size: 14px;">Right, not immediately. If and when new policy rul=
es are included in a Bitcoin Core release it would take a while before a si=
gnificant majority of the network were running those new policy rules (barr=
ing some kind of urgency, an attacker exploiting a systemic security flaw e=
tc). That's not an argument not to do it though if you take a longer term p=
erspective on building the strongest possible foundation for Lightning or o=
ther Layer 2 projects. The security benefit would just be delayed until a s=
ignificant majority of Bitcoin Core users upgraded to a version including t=
hose new policy rules.<br></div><div style=3D"font-family: arial; font-size=
: 14px;"><br></div><div style=3D"font-family: arial; font-size: 14px;">&gt;=
&nbsp;<span style=3D"color: rgb(0, 0, 0); font-style: normal; font-variant-=
ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spac=
ing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-st=
roke-width: 0px; text-decoration-thickness: initial; text-decoration-style:=
 initial; text-decoration-color: initial; float: none; display: inline !imp=
ortant;"><span class=3D"" style=3D""><span style=3D"font-family:-apple-syst=
em, &quot;system-ui&quot;, &quot;Segoe UI&quot;, Roboto, Oxygen-Sans, Ubunt=
u, Cantarell, &quot;Helvetica Neue&quot;, sans-serif" class=3D""><span clas=
s=3D"" style=3D""><span style=3D"font-size:14px" class=3D"">Bitcoin Core wi=
th different versions are used at any point and not sure if this will ever =
change.</span></span></span></span></span><br></div><div style=3D"font-fami=
ly: arial; font-size: 14px;"><br></div><div style=3D"font-family: arial; fo=
nt-size: 14px;">Sure there will always be some stray full nodes running ext=
remely old versions but the general direction of travel is more and more fu=
ll nodes upgrading to newer versions. A network where *all* full nodes are =
running the same policy rules is clearly not an option available to us with=
out making policy rules effective consensus rules and forking/kicking those=
 old versions off the network.<br></div><div style=3D"font-family: arial; f=
ont-size: 14px;"><br></div><div style=3D"font-family: arial; font-size: 14p=
x;">&gt;&nbsp;<span style=3D"color: rgb(0, 0, 0); font-style: normal; font-=
variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; let=
ter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoratio=
n-style: initial; text-decoration-color: initial; float: none; display: inl=
ine !important;"><span class=3D"" style=3D""><span style=3D"font-family:-ap=
ple-system, &quot;system-ui&quot;, &quot;Segoe UI&quot;, Roboto, Oxygen-San=
s, Ubuntu, Cantarell, &quot;Helvetica Neue&quot;, sans-serif" class=3D""><s=
pan class=3D"" style=3D""><span style=3D"font-size:14px" class=3D"">Maybe s=
ome experiments on signet might help in knowing more issues associated with=
 multiple RBF policies.</span></span></span></span></span><br></div><div st=
yle=3D"font-family: arial; font-size: 14px;"><br></div><div style=3D"font-f=
amily: arial; font-size: 14px;">Definitely agree. It is a really interestin=
g research area and lots of opportunities for simulations and experiments o=
n the default or custom signet networks. Especially if we fill blocks with =
auto-generated transactions and/or reduce block sizes and create an artific=
ial fee market.<br></div><div style=3D"font-family: arial; font-size: 14px;=
"><br></div><div style=3D"font-family: arial; font-size: 14px;" class=3D"">=
<div class=3D""><div style=3D"font-family:arial;font-size:14px;"><span styl=
e=3D"color:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:n=
ormal;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing=
:0px;background-color:rgb(255,255,255);float:none;display:inline;"><span cl=
ass=3D"" style=3D""><span style=3D"font-family:&quot;SFMono-Regular&quot;, =
Consolas, &quot;Liberation Mono&quot;, Menlo, monospace, monospace" class=
=3D""><span class=3D"" style=3D""><span style=3D"font-size:14px" class=3D""=
>--<br>Michael Folkson<br>Email: michaelfolkson at </span></span></span></s=
pan></span><a target=3D"_blank" rel=3D"noopener noreferrer" style=3D"line-h=
eight:normal;text-decoration:underline;font-family:'SFMono-Regular', Consol=
as, 'Liberation Mono', Menlo, monospace, monospace;font-size:14px;font-styl=
e:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transfo=
rm:none;white-space:pre-wrap;word-spacing:0px;" href=3D"http://protonmail.c=
om/">protonmail.com</a><span style=3D"color:rgb(38,42,51);font-style:normal=
;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;=
white-space:pre-wrap;word-spacing:0px;background-color:rgb(255,255,255);flo=
at:none;display:inline;"><span class=3D"" style=3D""><span style=3D"font-fa=
mily:&quot;SFMono-Regular&quot;, Consolas, &quot;Liberation Mono&quot;, Men=
lo, monospace, monospace" class=3D""><span class=3D"" style=3D""><span styl=
e=3D"font-size:14px" class=3D""></span></span></span></span></span></div><d=
iv style=3D"font-family:arial;font-size:14px;"><span style=3D"color:rgb(38,=
42,51);font-style:normal;font-weight:400;letter-spacing:normal;text-indent:=
0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;background-co=
lor:rgb(255,255,255);float:none;display:inline;"><span class=3D"" style=3D"=
"><span style=3D"font-family:&quot;SFMono-Regular&quot;, Consolas, &quot;Li=
beration Mono&quot;, Menlo, monospace, monospace" class=3D""><span class=3D=
"" style=3D""><span style=3D"font-size:14px" class=3D"">Keybase: michaelfol=
kson<br>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</span></span=
></span></span></span></div></div><div class=3D""><br></div></div><div styl=
e=3D"font-family: arial; font-size: 14px;"><br></div><div><br></div></div><=
div style=3D"font-family: arial; font-size: 14px;"><br></div><div class=3D"=
"><div>------- Original Message -------<br></div><div> On Monday, February =
14th, 2022 at 5:18 AM, Prayank &lt;prayank@tutanota.de&gt; wrote:<br></div>=
<div> <br></div><blockquote class=3D"" type=3D"cite"><div>&gt; I suspect as=
 with defaults generally most users will run whatever the defaults are as t=
hey won't care to change them (or even be capable of changing them if they =
are very non-technical).<br></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">30% nodes are using 0.21.1 right now where=
as latest version was 22.0 and some are even running lower versions. Differ=
ent versions in future with defaults might be running RBF v1 and RBF v2.<br=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; But users who hav=
e a stake in the security of Lightning (or other Layer 2 projects) will cle=
arly want to run whatever policy rules are beneficial to those protocols.<b=
r></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Agree and attackers will want to run the nodes with policy that help=
s them exploit bitcoin projects. Miners can run nodes with policy that help=
s them get more fees.&nbsp;<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">&gt; As you know the vast majority of the full nodes on the netwo=
rk currently run Bitcoin Core. Whether that will change in future and wheth=
er this a good thing or not is a whole other discussion. But the reality is=
 that with such strong dominance there is the option to set defaults that a=
re widely used.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Bitcoin Core with different versions are used at an=
y point and not sure if this will ever change.<br></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">https://luke.dashjr.org/programs/bitcoin/files/c=
harts/security.html<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
https://www.shodan.io/search/facet.png?query=3DUser-Agent%3A%2FSatoshi%2F+p=
ort%3A%228333%22&amp;facet=3Dproduct<br></div><div dir=3D"auto"><br></div><=
div>&gt; I think if certain defaults can bolster the security of Lightning =
(and possibly other Layer 2 projects) at no cost to full node users with no=
 interest in those protocols we should discuss what those defaults should b=
e.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">This is the assumption which I don't agree with and hence asked =
some questions in my email. A new RBF policy used by default in Core will n=
ot improve the security of projects that are vulnerable to multiple RBF pol=
icies or rely on these policies in a way that affects their security.&nbsp;=
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Maybe some experime=
nts on signet might help in knowing more issues associated with multiple RB=
F policies.<br></div><div dir=3D"auto"><br></div><div>-- <br></div><div>Pra=
yank<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div=
><div><br></div><div><br></div><div><br></div><div>Feb 13, 2022, 21:16 by m=
ichaelfolkson@protonmail.com:<br></div><blockquote style=3D"border-left: 1p=
x solid #93A3B8; padding-left: 10px; margin-left: 5px;" class=3D"tutanota_q=
uote"><div style=3D"font-family: arial; font-size: 14px;">Hi Prayank<br></d=
iv><div style=3D"font-family: arial; font-size: 14px;"><br></div><div style=
=3D"font-family: arial; font-size: 14px;">&gt; 1.Is Lightning Network and a=
 few other layer 2 projects vulnerable to multiple RBF policies being used?=
<br></div><div style=3D"font-family: arial; font-size: 14px;"><br></div><di=
v style=3D"font-family: arial; font-size: 14px;">Clearly the security of th=
e Lightning Network and some other Layer 2 projects are at least impacted o=
r partly dependent on policy rules in a way that the base blockchain/networ=
k isn't. As I (and others) have said on many occasions ideally this wouldn'=
t be the case but it is best we can do with current designs. I (and others)=
 take the view that this is not a reason to abandon those designs in the ab=
sence of an alternative that offers a strictly superior security model. Goi=
ng back to a model where *all* activity is onchain (or even in less trust m=
inimized protocols than Lightning) doesn't seem like the right approach to =
me.<br></div><div style=3D"line-height: normal;" dir=3D"auto"><br></div><di=
v style=3D"line-height: normal;" dir=3D"auto">&gt; 2.With recent discussion=
 to change things in default RBF policy used by Core, will we have multiple=
 versions using different policies? Are users and especially miners incenti=
vized to use different versions and policies? Do they have freedom to use d=
ifferent RBF policy?<br></div><div style=3D"font-family: arial; font-size: =
14px;" dir=3D"auto"><br></div><div style=3D"font-family: arial; font-size: =
14px;" dir=3D"auto">Without making policy rules effective consensus rules u=
sers (including miners) are free to run different policy rules. I think it =
is too early to say what the final incentives will be to run the same or di=
ffering policies. Research into Lightning security is still nascent and we =
have no idea whether alternative Layer 2 projects will thrive and whether t=
hey will have the same or conflicting security considerations to Lightning.=
 <br></div><div style=3D"font-family: arial; font-size: 14px;" dir=3D"auto"=
><br></div><div style=3D"font-family: arial; font-size: 14px;" dir=3D"auto"=
>As you know the vast majority of the full nodes on the network currently r=
un Bitcoin Core. Whether that will change in future and whether this a good=
 thing or not is a whole other discussion. But the reality is that with suc=
h strong dominance there is the option to set defaults that are widely used=
. I think if certain defaults can bolster the security of Lightning (and po=
ssibly other Layer 2 projects) at no cost to full node users with no intere=
st in those protocols we should discuss what those defaults should be.<br><=
/div><div style=3D"line-height: normal;" dir=3D"auto"><br></div><div style=
=3D"line-height: normal;" dir=3D"auto">&gt; 3.Are the recent improvements s=
uggested for RBF policy only focused on Lightning Network and its security =
which will anyway remain same or become worse with multiple RBF policies?<b=
r></div><div style=3D"font-family: arial; font-size: 14px;" dir=3D"auto"><b=
r></div><div style=3D"font-family: arial; font-size: 14px;" dir=3D"auto">I =
think by nature of the Lightning Network being the most widely adopted Laye=
r 2 project most of the focus has been on Lightning security. But contribut=
ors to other Layer 2 projects are free to flag and discuss security conside=
rations that aren't Lightning specific.<br></div><div style=3D"line-height:=
 normal;"><br></div><div style=3D"line-height: normal;" dir=3D"auto">&gt; N=
ote: Bitcoin Knots policy is fully configurable, even in the GUI - users ca=
n readily choose whatever policy *they* want.<br></div><div style=3D"font-f=
amily: arial; font-size: 14px;" dir=3D"auto"><br></div><div style=3D"font-f=
amily: arial; font-size: 14px;" dir=3D"auto">The maintainer(s) and contribu=
tors to Bitcoin Knots are free to determine what default policy rules they =
want to implement (and make it easier for users to change those defaults) i=
n the absence of those policy rules being made effective consensus rules. I=
 suspect there would be strong opposition to making some policy rules effec=
tive consensus rules but we are now venturing again into future speculation=
 and none of us have a crystal ball. Certainly if you take the view that th=
ese policy rules should never be made effective consensus rules then the fa=
ct there is at least one implementation taking a contrasting approach to Co=
re is a good thing.<br></div><div style=3D"font-family: arial; font-size: 1=
4px;" dir=3D"auto"><br></div><div style=3D"font-family: arial; font-size: 1=
4px;"><div style=3D"font-family: arial; font-size: 14px;" class=3D""><div c=
lass=3D""><div style=3D"font-family:arial;font-size:14px;"><span style=3D"c=
olor:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;=
text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;b=
ackground-color:rgb(255,255,255);float:none;display:inline;"><span class=3D=
"" style=3D""><span style=3D"" class=3D""><span style=3D"font-family:SFMono=
-Regular, Consolas, &quot;Liberation Mono&quot;, Menlo, monospace, monospac=
e" class=3D""><span class=3D"" style=3D""><span style=3D"" class=3D""><span=
 style=3D"font-size:14px" class=3D"">--<br>Michael Folkson<br>Email: michae=
lfolkson at </span></span></span></span></span></span></span><a target=3D"_=
blank" rel=3D"noopener noreferrer" style=3D"line-height:normal;text-decorat=
ion:underline;font-family:'SFMono-Regular', Consolas, 'Liberation Mono', Me=
nlo, monospace, monospace;font-size:14px;font-style:normal;font-weight:400;=
letter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-w=
rap;word-spacing:0px;" href=3D"http://protonmail.com/">protonmail.com</a><s=
pan style=3D"color:rgb(38,42,51);font-style:normal;font-weight:400;letter-s=
pacing:normal;text-indent:0px;text-transform:none;white-space:pre-wrap;word=
-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline;">=
<span class=3D"" style=3D""><span style=3D"" class=3D""><span style=3D"font=
-family:SFMono-Regular, Consolas, &quot;Liberation Mono&quot;, Menlo, monos=
pace, monospace" class=3D""><span class=3D"" style=3D""><span style=3D"" cl=
ass=3D""><span style=3D"font-size:14px" class=3D""></span></span></span></s=
pan></span></span></span></div><div style=3D"font-family:arial;font-size:14=
px;"><span style=3D"color:rgb(38,42,51);font-style:normal;font-weight:400;l=
etter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-wr=
ap;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:in=
line;"><span class=3D"" style=3D""><span style=3D"" class=3D""><span style=
=3D"font-family:SFMono-Regular, Consolas, &quot;Liberation Mono&quot;, Menl=
o, monospace, monospace" class=3D""><span class=3D"" style=3D""><span style=
=3D"" class=3D""><span style=3D"font-size:14px" class=3D"">Keybase: michael=
folkson<br>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</span></s=
pan></span></span></span></span></span></div></div><div class=3D""><br></di=
v></div><div style=3D"font-family: arial; font-size: 14px;"><br></div></div=
><div style=3D"font-family: arial; font-size: 14px;"><br></div><div class=
=3D""><div>------- Original Message -------<br></div><div>On Sunday, Februa=
ry 13th, 2022 at 6:09 AM, Prayank via Lightning-dev &lt;lightning-dev@lists=
.linuxfoundation.org&gt; wrote:<br></div><div><br></div><blockquote class=
=3D"" type=3D"cite"><div>Hello World,<br></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">There was a discussion about improving fee estimation in =
Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consi=
der mempool as an orderbook in which which everyone is bidding for block sp=
ace because nodes can use different relay policies: https://bitcoin-irc.cha=
incode.com/bitcoin-core-dev/2021-09-22#706294;<br></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Although I still don't consider fee rates used i=
n last few blocks relevant for fee estimation, it is possible that we have =
nodes with different relay policies.<br></div><div dir=3D"auto"><br></div><=
div dir=3D"auto"><div>Similarly if we have different RBF policies being use=
d by nodes in future, how would this affect the security of lightning netwo=
rk implementations and other layer 2 projects? <br></div><div><br></div><di=
v>Based on the things shared by 'aj' in <br></div><div>https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2022-February/019846.html it is possibl=
e for an attacker to use a different RBF policy with some nodes, 10% hash p=
ower and affect the security of different projects that rely on default RBF=
 policy in latest Bitcoin Core.<br></div><div><br></div><div>There was even=
 a CVE in which RBF policy not being documented according to the implementa=
tion could affect the security of LN: <br></div></div><div>https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html<br></div><div =
dir=3D"auto"><br></div><div dir=3D"auto">1.Is Lightning Network and a few o=
ther layer 2 projects vulnerable to multiple RBF policies being used? <br><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">2.With recent discussion=
 to change things in default RBF policy used by Core, will we have multiple=
 versions using different policies? Are users and especially miners incenti=
vized to use different versions and policies? Do they have freedom to use d=
ifferent RBF policy?<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>3.Are the recent improvements suggested for RBF policy only focused on Lig=
htning Network and its security which will anyway remain same or become wor=
se with multiple RBF policies?<br></div><div><br></div><div dir=3D"auto">No=
te: Bitcoin Knots policy is fully configurable, even in the GUI - users can=
 readily choose whatever policy *they* want.<br></div><div dir=3D"auto"><br=
></div><div>-- <br></div><div>Prayank<br></div><div><br></div><div dir=3D"a=
uto">A3B1 E430 2298 178F<br></div></blockquote></div></blockquote></blockqu=
ote></div></blockquote><div dir=3D"auto"><br></div>  </body>
</html>

------=_Part_259166_1108191932.1644861577583--