Return-Path: 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 To: Michael Folkson Message-ID: In-Reply-To: References: 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 , Lightning Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 = 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 >>>= 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 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
> 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.

1.An attacker does not require significant majority for such atta= cks.
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.

<= div dir=3D"auto">> 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.

A net= work with a policy already widely used exists right now.

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

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.


--
Prayank

A3B1 E= 430 2298 178F



Fe= b 14, 2022, 22:32 by michaelfolkson@protonmail.com:
> 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. 

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.

>=  Bitcoin Core wi= th different versions are used at any point and not sure if this will ever = change.

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.

> Maybe s= ome experiments on signet might help in knowing more issues associated with= multiple RBF policies.

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.
=
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfol= kson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3



<= div style=3D"font-family: arial; font-size: 14px;">
------- Original Message -------
On Monday, February = 14th, 2022 at 5:18 AM, Prayank <prayank@tutanota.de> wrote:
=

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


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.

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


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. 

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


=
Bitcoin Core with different versions are used at an= y point and not sure if this will ever change.
<= br>
https://luke.dashjr.org/programs/bitcoin/files/c= harts/security.html

= https://www.shodan.io/search/facet.png?query=3DUser-Agent%3A%2FSatoshi%2F+p= ort%3A%228333%22&facet=3Dproduct

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


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

Maybe some experime= nts on signet might help in knowing more issues associated with multiple RB= F policies.

--
Pra= yank

A3B1 E430 2298 178F



Feb 13, 2022, 21:16 by m= ichaelfolkson@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 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.

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

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

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.
<= /div>

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

> N= ote: Bitcoin Knots policy is fully configurable, even in the GUI - users ca= n readily choose whatever policy *they* want.

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.

--
Michael Folkson
Email: michae= lfolkson at protonmail.com=
Keybase: michael= folkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3



------- Original Message -------
On Sunday, Februa= ry 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <lightning-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 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>
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.

<= div dir=3D"auto">
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?

Based on the things shared by 'aj' in
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.

There was even= a CVE in which RBF policy not being documented according to the implementa= tion could affect the security of LN:
https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html

1.Is Lightning Network and a few o= ther layer 2 projects vulnerable to multiple RBF policies being used?
<= /div>

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?

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?

No= te: Bitcoin Knots policy is fully configurable, even in the GUI - users can= readily choose whatever policy *they* want.
--
Prayank

A3B1 E430 2298 178F

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