From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 To: Michael Folkson Message-ID: In-Reply-To: References: 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 , 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 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 > 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 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
> 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).
=

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.

>= ; 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 wi= th policy that helps them exploit bitcoin projects. Miners can run nodes wi= th policy that helps them get more fees. 
<= br>
> 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.


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

https://luke.dashjr.org/programs/b= itcoin/files/charts/security.html

https://www.shodan.io/search/facet.png?query=3DUser-Agent%3A%= 2FSatoshi%2F+port%3A%228333%22&facet=3Dproduct
<= br>
> 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.


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. 

Maybe som= e experiments on signet might help in knowing more issues associated with m= ultiple RBF policies.

--
Prayank

A3B1 E430 2298 178= F



Feb 13, 2022, = 21:16 by michaelfolkson@protonmail.com:
Hi Pray= ank

=
> 1.Is Lightning Net= work and a few other layer 2 projects vulnerable to multiple RBF policies b= eing used?
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.
> 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?

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.

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.

<= div dir=3D"auto" style=3D"line-height: normal;">> 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?

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.

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

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.

<= span style=3D"" class=3D"">--=
Michael Folkson
Email: michaelfolkson at protonmail.com
<= span class=3D"size" style=3D"font-size:14px">Keybase: michaelfolkson
PGP= : 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3



------- Original Me= ssage -------
On Sunday, February 13th, 2022 at 6:09 AM, Pra= yank via Lightning-dev <lightning-dev@lists.linuxfoundation.org> wrot= e:

Hello= World,

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;

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.

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?

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

There was even a CVE in which RBF policy not= being documented according to the implementation could affect the security= of LN:
https://lists.linuxfoundation.org/pipermail/bi= tcoin-dev/2021-May/018893.html

1.Is Lightning Network and a few other layer 2 projects vulnerab= le to multiple RBF policies being used?

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

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

Note: Bitcoin Knots policy is fu= lly configurable, even in the GUI - users can readily choose whatever polic= y *they* want.

--
= Prayank

A3B1 E430 2298 178F
------=_Part_210526_906791025.1644815910521--