path: root/cc/445138d67805e0b6845c7cd7287b026356efb6

Return-Path: <prayank@tutanota.de>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 03B9BC000B;
 Mon, 14 Feb 2022 05:18:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id E7A944029F;
 Mon, 14 Feb 2022 05:18:35 +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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=tutanota.de
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 Zn4OQx_I9qdU; Mon, 14 Feb 2022 05:18:33 +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 smtp4.osuosl.org (Postfix) with ESMTPS id 5D4ED4029B;
 Mon, 14 Feb 2022 05:18:33 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
 by w1.tutanota.de (Postfix) with ESMTP id 83C5CFBF827;
 Mon, 14 Feb 2022 05:18:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1644815910; 
 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=8FLsxHOA9g1rk8m9xlglVi1D9NGtDpx4Yb0ips9GGF8=;
 b=l2VUAvK/Pxjmkd3Co1HnGMvjpxGQ82l1uZMdDkjvmpRKfP1tagRC/fHIF4g9Q8IB
 /LnZeuBINU4JbfoukUygPSkXcHN/yZ5H2E6D3qPYpKCD7XfNq45FHMKMw67cTfkpB51
 fE4mc6ZgLDvd6sofORb2uaTl0Pd5iVQh/VCEx1qUGBlItHct07nh+o/HuEah6MlXvfl
 qNTfx8BZtgq9Bp+fgXaLo8eBTbc0VxDI5gz04rBqshwMuygeiSNq4x4PT+O1IEAAsDJ
 oN4OyIxEO40kUWwIJU4tLwIk0oQicnoQJaUgWY5CBWSv0/2UM9iXIfckO41CVKKOsyD
 fV4659b/OA==
Date: Mon, 14 Feb 2022 06:18:30 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <Mvqek99--B-2@tutanota.de>
In-Reply-To: <aTVwIe_-6PUKYZ4btOUF8axaX_CzpStUta2_mOzX_5nN1NomU_OinXIRFHsswr7-O-C-i60ViTfeAyLVxYH490YZo65m8hlUy9KnY5OPEwo=@protonmail.com>
References: <MvlgjLW--3-2@tutanota.de>
 <aTVwIe_-6PUKYZ4btOUF8axaX_CzpStUta2_mOzX_5nN1NomU_OinXIRFHsswr7-O-C-i60ViTfeAyLVxYH490YZo65m8hlUy9KnY5OPEwo=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_210526_906791025.1644815910521"
X-Mailman-Approved-At: Mon, 14 Feb 2022 08:44:26 +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 05:18:36 -0000

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

> I suspect as with defaults generally most users will run whatever the def=
aults are as they won't care to change them (or even be capable of changing=
 them if they are very non-technical).
=20

30% nodes are using 0.21.1 right now whereas latest version was 22.0 and so=
me are even running lower versions. Different versions in future with defau=
lts might be running RBF v1 and RBF v2.
> But users who have a stake in the security of Lightning (or other Layer 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 them =
exploit bitcoin projects. Miners can run nodes with policy that helps them =
get more fees.=C2=A0

> As you know the vast majority of the full nodes on the network currently =
run Bitcoin Core. Whether that will change in future and whether this a goo=
d thing or not is a whole other discussion. But the reality is that with su=
ch strong dominance there is the option to set defaults that are widely use=
d.

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%2F+p=
ort%3A%228333%22&facet=3Dproduct
> 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.


This is the assumption which I don't agree with and hence asked some questi=
ons in my email. A new RBF policy used by default in Core will not improve =
the security of projects that are vulnerable to multiple RBF policies or re=
ly on these policies in a way that affects their security.=C2=A0

Maybe some experiments on signet might help in knowing more issues associat=
ed 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 m=
ultiple RBF policies being used?
>
> Clearly the security of the Lightning Network and some other Layer 2 proj=
ects are at least impacted or partly dependent on policy rules in a way tha=
t the base blockchain/network isn't. As I (and others) have said on many oc=
casions ideally this wouldn't be the case but it is best we can do with cur=
rent designs. I (and others) take the view that this is not a reason to aba=
ndon those designs in the absence of an alternative that offers a strictly =
superior security model. Going back to a model where *all* activity is onch=
ain (or even in less trust minimized protocols than Lightning) doesn't seem=
 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 a=
nd especially miners incentivized to use different versions and policies? D=
o they have freedom to use different RBF policy?
>
> Without making policy rules effective consensus rules users (including mi=
ners) are free to run different policy rules. I think it is too early to sa=
y 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 wheth=
er alternative Layer 2 projects will thrive and whether they will have the =
same or conflicting security considerations to Lightning.=20
>
> As you know the vast majority of the full nodes on the network currently =
run Bitcoin Core. Whether that will change in future and whether this a goo=
d thing or not is a whole other discussion. But the reality is that with su=
ch strong dominance there is the option to set defaults that are widely use=
d. I think if certain defaults can bolster the security of Lightning (and p=
ossibly other Layer 2 projects) at no cost to full node users with no inter=
est in those protocols we should discuss what those defaults should be.
>
> > 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?
>
> I think by nature of the Lightning Network being the most widely adopted =
Layer 2 project most of the focus has been on Lightning security. But contr=
ibutors to other Layer 2 projects are free to flag and discuss security con=
siderations that aren't Lightning specific.
>
> > Note: Bitcoin Knots policy is fully configurable, even in the GUI - use=
rs can readily choose whatever policy *they* want.
>
> The maintainer(s) and contributors to Bitcoin Knots are free to determine=
 what default policy rules they want to implement (and make it easier for u=
sers to change those defaults) in the absence of those policy rules being m=
ade effective consensus rules. I suspect there would be strong opposition t=
o making some policy rules effective consensus rules but we are now venturi=
ng again into future speculation and none of us have a crystal ball. Certai=
nly if you take the view that these policy rules should never be made effec=
tive consensus rules then the fact there is at least one implementation tak=
ing a contrasting approach to Core is a good thing.
>
> --
> 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 Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <li=
ghtning-dev@lists.linuxfoundation.org> wrote:
> =20
>
>> Hello World,
>>
>> There was a discussion about improving fee estimation in Bitcoin Core la=
st year in which 'instagibbs' mentioned that we cannot consider mempool as =
an orderbook in which which everyone is bidding for block space because nod=
es can use different relay policies: https://bitcoin-irc.chaincode.com/bitc=
oin-core-dev/2021-09-22#706294;
>>
>> Although I still don't consider fee rates used in last few blocks releva=
nt for fee estimation, it is possible that we have nodes with different rel=
ay policies.
>>
>> Similarly if we have different RBF policies being used by nodes in futur=
e, how would this affect the security of lightning network implementations =
and other layer 2 projects?=20
>>
>> Based on the things shared by 'aj' in=20
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/01=
9846.html it is possible for an attacker to use a different RBF policy with=
 some nodes, 10% hash power and affect the security of different projects t=
hat rely on default RBF policy in latest Bitcoin Core.
>>
>> There was even a CVE in which RBF policy not being documented according =
to the implementation could affect the security of LN:=20
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.=
html
>>
>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to mu=
ltiple RBF policies being used?=20
>>
>> 2.With recent discussion to change things in default RBF policy used by =
Core, will we have multiple versions using different policies? Are users an=
d 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 L=
ightning Network and its security which will anyway remain same or become w=
orse with multiple RBF policies?
>>
>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - user=
s can readily choose whatever policy *they* want.
>>
>> --=20
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
------=_Part_210526_906791025.1644815910521
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; 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 =
changing them if they are very non-technical).<br></div><div dir=3D"auto"> =
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">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 defaults might be runnin=
g RBF v1 and RBF v2.</div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt=
; But users who have a stake in the security of Lightning (or other Layer 2=
 projects) will clearly want to run whatever policy rules are beneficial to=
 those protocols.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Agree and attackers will want to run the nodes wi=
th policy that helps them exploit bitcoin projects. Miners can run nodes wi=
th policy that helps 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 n=
odes on the network currently run Bitcoin Core. Whether that will change in=
 future and whether this a good thing or not is a whole other discussion. B=
ut the reality is that with such strong dominance there is the option to se=
t defaults that are widely used.</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 any 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/b=
itcoin/files/charts/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+port%3A%228333%22&amp;facet=3Dproduct</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 use=
rs with no interest in those protocols we should discuss what those default=
s should be.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">This is the assumption which I don't agree with and he=
nce asked some questions in my email. A new RBF policy used by default in C=
ore will not improve the security of projects that are vulnerable to multip=
le RBF policies or rely on these policies in a way that affects their secur=
ity.&nbsp;<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Maybe som=
e experiments on signet might help in knowing more issues associated with m=
ultiple RBF policies.<br></div><div dir=3D"auto"><br></div><div>-- <br></di=
v><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178=
F<br></div><div><br></div><div><br></div><div><br></div><div>Feb 13, 2022, =
21:16 by michaelfolkson@protonmail.com:<br></div><blockquote class=3D"tutan=
ota_quote" style=3D"border-left: 1px solid #93A3B8; padding-left: 10px; mar=
gin-left: 5px;"><div style=3D"font-family: arial; font-size: 14px;">Hi Pray=
ank<br></div><div style=3D"font-family: arial; font-size: 14px;"><br></div>=
<div style=3D"font-family: arial; font-size: 14px;">&gt; 1.Is Lightning Net=
work and a few other layer 2 projects vulnerable to multiple RBF policies b=
eing used?<br></div><div style=3D"font-family: arial; font-size: 14px;"><br=
></div><div style=3D"font-family: arial; font-size: 14px;">Clearly the secu=
rity of the Lightning Network and some other Layer 2 projects are at least =
impacted or partly dependent on policy rules in a way that the base blockch=
ain/network isn't. As I (and others) have said on many occasions ideally th=
is wouldn't be the case but it is best we can do with current designs. I (a=
nd others) take the view that this is not a reason to abandon those designs=
 in the absence of an alternative that offers a strictly superior security =
model. Going back to a model where *all* activity is onchain (or even in le=
ss trust minimized protocols than Lightning) doesn't seem like the right ap=
proach to me.<br></div><div dir=3D"auto" style=3D"line-height: normal;"><br=
></div><div dir=3D"auto" style=3D"line-height: normal;">&gt; 2.With recent =
discussion to change things in default RBF policy used by Core, will we hav=
e multiple versions using different policies? Are users and especially mine=
rs incentivized to use different versions and policies? Do they have freedo=
m to use different RBF policy?<br></div><div dir=3D"auto" style=3D"font-fam=
ily: arial; font-size: 14px;"><br></div><div dir=3D"auto" style=3D"font-fam=
ily: arial; font-size: 14px;">Without making policy rules effective consens=
us 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 nasce=
nt and we have no idea whether alternative Layer 2 projects will thrive and=
 whether they will have the same or conflicting security considerations to =
Lightning. <br></div><div dir=3D"auto" style=3D"font-family: arial; font-si=
ze: 14px;"><br></div><div dir=3D"auto" style=3D"font-family: arial; font-si=
ze: 14px;">As you know the vast majority of the full nodes on the network c=
urrently run Bitcoin Core. Whether that will change in future and whether t=
his a good thing or not is a whole other discussion. But the reality is tha=
t with such strong dominance there is the option to set defaults that are w=
idely used. I think if certain defaults can bolster the security of Lightni=
ng (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 shoul=
d be.<br></div><div dir=3D"auto" style=3D"line-height: normal;"><br></div><=
div dir=3D"auto" style=3D"line-height: normal;">&gt; 3.Are the recent impro=
vements suggested for RBF policy only focused on Lightning Network and its =
security which will anyway remain same or become worse with multiple RBF po=
licies?<br></div><div dir=3D"auto" style=3D"font-family: arial; font-size: =
14px;"><br></div><div dir=3D"auto" style=3D"font-family: arial; font-size: =
14px;">I think by nature of the Lightning Network being the most widely ado=
pted Layer 2 project most of the focus has been on Lightning security. But =
contributors to other Layer 2 projects are free to flag and discuss securit=
y considerations that aren't Lightning specific.<br></div><div style=3D"lin=
e-height: normal;"><br></div><div dir=3D"auto" style=3D"line-height: normal=
;">&gt; Note: Bitcoin Knots policy is fully configurable, even in the GUI -=
 users can readily choose whatever policy *they* want.<br></div><div dir=3D=
"auto" style=3D"font-family: arial; font-size: 14px;"><br></div><div dir=3D=
"auto" style=3D"font-family: arial; font-size: 14px;">The maintainer(s) and=
 contributors to Bitcoin Knots are free to determine what default policy ru=
les they want to implement (and make it easier for users to change those de=
faults) in the absence of those policy rules being made effective consensus=
 rules. I suspect there would be strong opposition to making some policy ru=
les effective consensus rules but we are now venturing again into future sp=
eculation and none of us have a crystal ball. Certainly if you take the vie=
w that these policy rules should never be made effective consensus rules th=
en the fact there is at least one implementation taking a contrasting appro=
ach to Core is a good thing.<br></div><div dir=3D"auto" style=3D"font-famil=
y: arial; font-size: 14px;"><br></div><div style=3D"font-family: arial; fon=
t-size: 14px;"><div class=3D"" style=3D"font-family: arial; font-size: 14px=
;"><div class=3D""><div style=3D"font-family:arial;font-size:14px;"><span s=
tyle=3D"color:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacin=
g:normal;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spac=
ing:0px;background-color:rgb(255,255,255);float:none;display:inline;"><span=
 style=3D"" class=3D""><span class=3D"font" style=3D"font-family:SFMono-Reg=
ular, Consolas, &quot;Liberation Mono&quot;, Menlo, monospace, monospace"><=
span style=3D"" class=3D""><span class=3D"size" style=3D"font-size:14px">--=
<br>Michael Folkson<br>Email: michaelfolkson at </span></span></span></span=
></span><a href=3D"http://protonmail.com/" style=3D"line-height:normal;text=
-decoration:underline;font-family:'SFMono-Regular', Consolas, 'Liberation M=
ono', Menlo, monospace, monospace;font-size:14px;font-style:normal;font-wei=
ght:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-spa=
ce:pre-wrap;word-spacing:0px;" rel=3D"noopener noreferrer" target=3D"_blank=
">protonmail.com</a><span style=3D"color:rgb(38,42,51);font-style:normal;fo=
nt-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;whi=
te-space:pre-wrap;word-spacing:0px;background-color:rgb(255,255,255);float:=
none;display:inline;"><span style=3D"" class=3D""><span class=3D"font" styl=
e=3D"font-family:SFMono-Regular, Consolas, &quot;Liberation Mono&quot;, Men=
lo, monospace, monospace"><span style=3D"" class=3D""><span class=3D"size" =
style=3D"font-size:14px"></span></span></span></span></span></div><div styl=
e=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;tex=
t-transform:none;white-space:pre-wrap;word-spacing:0px;background-color:rgb=
(255,255,255);float:none;display:inline;"><span style=3D"" class=3D""><span=
 class=3D"font" style=3D"font-family:SFMono-Regular, Consolas, &quot;Libera=
tion Mono&quot;, Menlo, monospace, monospace"><span style=3D"" class=3D""><=
span class=3D"size" style=3D"font-size:14px">Keybase: michaelfolkson<br>PGP=
: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</span></span></span></s=
pan></span></div></div><div class=3D""><br></div></div><div style=3D"font-f=
amily: arial; font-size: 14px;"><br></div></div><div style=3D"font-family: =
arial; font-size: 14px;"><br></div><div class=3D""><div>------- Original Me=
ssage -------<br></div><div> On Sunday, February 13th, 2022 at 6:09 AM, Pra=
yank via Lightning-dev &lt;lightning-dev@lists.linuxfoundation.org&gt; wrot=
e:<br></div><div> <br></div><blockquote type=3D"cite" class=3D""><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 whic=
h 'instagibbs' mentioned that we cannot consider mempool as an orderbook in=
 which which everyone is bidding for block space because nodes can use diff=
erent relay policies: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/20=
21-09-22#706294;<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Alt=
hough I still don't consider fee rates used in last few blocks relevant for=
 fee estimation, it is possible that we have nodes with different relay pol=
icies.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div>Similarl=
y if we have different RBF policies being used by nodes in future, how woul=
d this affect the security of lightning network implementations and other l=
ayer 2 projects? <br></div><div><br></div><div>Based on the things shared b=
y 'aj' in <br></div><div>https://lists.linuxfoundation.org/pipermail/bitcoi=
n-dev/2022-February/019846.html it is possible for an attacker to use a dif=
ferent RBF policy with some nodes, 10% hash power and affect the security o=
f 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 implementation could affect the security=
 of LN: <br></div></div><div>https://lists.linuxfoundation.org/pipermail/bi=
tcoin-dev/2021-May/018893.html<br></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">1.Is Lightning Network and a few other layer 2 projects vulnerab=
le to multiple RBF policies being used? <br></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">2.With recent discussion to change things in default R=
BF policy used by Core, will we have multiple versions using different poli=
cies? Are users and especially miners incentivized to use different version=
s and policies? Do they have freedom to use different 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 Lightning Network and its securit=
y which will anyway remain same or become worse with multiple RBF policies?=
<br></div><div><br></div><div dir=3D"auto">Note: Bitcoin Knots policy is fu=
lly configurable, even in the GUI - users can readily choose whatever polic=
y *they* want.<br></div><div dir=3D"auto"><br></div><div>-- <br></div><div>=
Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></=
div></blockquote></div></blockquote>  </body>
</html>

------=_Part_210526_906791025.1644815910521--