Re: [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

[Prayank via Lightning-dev]

> That's not an argument 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.

1.An attacker does not require significant majority for such attacks. 
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 issues.

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

A network 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 experiments on the default or custom signet 
> networks. Especially if we fill blocks 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 anything 
interesting.


-- 
Prayank

A3B1 E430 2298 178F



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

> > 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 not 
> > improve the security of projects that are vulnerable to multiple RBF 
> > policies or rely on these policies in a way that affects their security. 
>
> Right, not immediately. If and when new policy rules are included in a 
> Bitcoin Core release it would take a while before a significant majority of 
> the network were running those new policy rules (barring some kind of 
> urgency, an attacker exploiting a systemic security flaw etc). That's not an 
> argument 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.
>
> > > Bitcoin Core with 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 extremely old 
> versions but the general direction of travel is more and more full 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 without making 
> policy rules effective consensus rules and forking/kicking those old versions 
> off the network.
>
> > > Maybe some experiments on signet might help in knowing more issues 
> >associated with multiple RBF policies.
>
> Definitely agree. It is a really interesting research area and lots of 
> opportunities for simulations and experiments on the default or custom signet 
> networks. Especially if we fill blocks with auto-generated transactions 
> and/or reduce block sizes and create an artificial fee market.
>
> --
> Michael Folkson
> Email: michaelfolkson at > protonmail.com > Keybase: 
> 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:
>  
>
>> > 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 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. 
>>
>> > 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 
>> > 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=User-Agent%3A%2FSatoshi%2F+port%3A%228333%22=product
>>
>> > I think if certain defaults 

Re: [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

[Michael Folkson via Lightning-dev]

> 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 not 
> improve the security of projects that are vulnerable to multiple RBF policies 
> or rely on these policies in a way that affects their security.

Right, not immediately. If and when new policy rules are included in a Bitcoin 
Core release it would take a while before a significant majority of the network 
were running those new policy rules (barring some kind of urgency, an attacker 
exploiting a systemic security flaw etc). That's not an argument 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.

> Bitcoin Core with 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 extremely old versions 
but the general direction of travel is more and more full 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 without making policy rules 
effective consensus rules and forking/kicking those old versions off the 
network.

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

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

--
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 Monday, February 14th, 2022 at 5:18 AM, Prayank  wrote:

>> 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 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.
>
>> 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 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=User-Agent%3A%2FSatoshi%2F+port%3A%228333%22=product
>
>> 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 be.
>
> 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 not 
> improve the security of projects that are vulnerable to multiple RBF policies 
> or rely on these policies in a way that affects their security.
>
> Maybe some experiments on signet might help in knowing more issues associated 
> with multiple RBF policies.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
> Feb 13, 2022, 21:16 by michaelfolk...@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 
>> projects are at least impacted or partly dependent on policy rules in a way 
>> that 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 
>> current designs. I (and 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 less trust minimized protocols than Lightning) 
>> doesn't seem like the right approach to me.
>>
>>> 2.With recent discussion to change things