path: root/ac/c432bfd907c7f5eef68ee20737cee4275133f0

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