Add advisory section for wumbo channels confirmations #746

araspitzu · 2020-02-18T12:29:22Z

This PR is a follow up on #596 adding an advisory section where we suggest implementors to provide the means to scale the number of confirmation along with the channel size. This is a security measure to protect against chain reorgs when opening large channels.

We advise the implementors to provide the means to increase the number confirmations needed to confirm large channels

t-bast

@TheBlueMatt @moneyball @Roasbeef can you please provide some input?

ariard

I would also advise wumbo channels operators to diversify their block headers sources instead of relying only on one full-node connected to broadband internet (like multi-homing or satellites). Likely out of scope here, but maybe we should have some spec annex with general security advices.

ariard · 2020-03-02T17:29:02Z

02-peer-protocol.md

@@ -192,6 +192,10 @@ know this node will accept `funding_satoshis` greater than or equal to 2^24.
 Since it's broadcast in the `node_announcement` message other nodes can use it to identify peers 
 willing to accept large channel even before exchanging the `init` message with them. 

+Implementers are advised to provide the means to scale the number of confirmations, tweaking 
+`accept_channel.minimum_depth`, with the size of the funding amount. A rule of thumb is to 
+wait enough blocks until the cumulative block reward exceeds the size of the channel.


Maybe we should also recommend to scale to_self_delay in consequence ? You may have watchtowers to alleviate the liveliness requirement but mempool congestion is still a concern.

Why does the issue apply to to_self_delay? I don't think it does, I think only funding is important as you don't want to start using the channel, relay payments and then see the channel's funding tx be double spent. But what could the attack be when closing?

Eclipsing your node and slowing block your block reception. That way I pin you with a delayed view of blockchain view, can broadcast a revoked commitment transaction and you won't react until it's too late. An adversary would also beneficiate from a congestioned mempool for your justice txn getting confirmed. This attack may be hard to setup but for a high-value channel they shouldn't be excluded, increasing to_self_delay means increasing period during which eclipsing must be sustained.

02-peer-protocol.md

araspitzu · 2020-03-03T08:38:39Z

I agree it would be nice to mention having different sources for block headers as a security principle, but it seems a bit out of scope in the advisory. In general the implementers should take the same precautions as when handling a large incoming bitcoin payment, perhaps we could express this more explicitly in the advisory but i couldn't find a better way to give some general advice while keeping it technical (especially mentioning accept_channel.minimum_depth which is important for implementers).

TheBlueMatt · 2020-03-16T19:40:55Z

02-peer-protocol.md

@@ -192,6 +192,10 @@ know this node will accept `funding_satoshis` greater than or equal to 2^24.
 Since it's broadcast in the `node_announcement` message other nodes can use it to identify peers 
 willing to accept large channel even before exchanging the `init` message with them. 

+Implementers are advised to provide the means to scale the number of confirmations, tweaking 
+`accept_channel.minimum_depth`, with the size of the funding amount. A rule of thumb is to 


We should just drop the sentence starting with "A rule of thumb". I don't think its sufficiently conservative for many users, and its probably too conservative for others.

I'm curious on why it wouldn't be sufficiently conservative for many users (we're also adding largely exceeds), but if this is too generic and can't cover most cases then I agree we should remove it.

I think it's mainly that it's too opinionated. Looking at the cumulative block reward to evaluate cost is one way among several ways of evaluating your scaling scenario. Having this in the spec may be influencing too much the implementers.

IIUC what was suggested during the meeting, this advisory should only say something like:

Implementers are advised to provide the means to scale the number of confirmations, tweaking `accept_channel.minimum_depth` and `accept_channel.to_self_delay`, with the size of the funding amount.

And let implementers completely free of choosing what scaling strategies they offer to their users.

Sounds good to me 👍

t-bast

ACK 6cc31bb

ariard · 2020-03-19T17:47:38Z

ACK 6cc31bb

cdecker · 2020-03-30T18:19:46Z

Personally I don't find these advisories useful, they tend to bloat the spec and not add much value. Don't write every little detail into the Constitution, that's what associated works are for.

t-bast · 2020-03-30T18:38:50Z

Personally I don't find these advisories useful, they tend to bloat the spec and not add much value.

I'd generally agree, but here we're keeping this to two lines and I think it's really, really important future implementers don't miss that so worth quickly mentioning...

rustyrussell · 2020-03-30T19:51:34Z

Minimum depth makes sense, ofc. But tweaking the to-self delay never did (from an economic PoV): in theory the danger of complete funds loss scales just like the danger of loss of access to funds.

So while a 1BTC channel is worth protecting, it's also a PITA to have the funds inaccessable for a month.

[ ariard on IRC pointed out that a large enough channel may incentivize attackers to perform an eclipse attack on your node, so having more time for out-of-band penalty broadcast makes sense. This is a valid point ]

t-bast · 2020-03-30T19:57:14Z

We should probably update the wording to something like:

"Implementers should consider scaling the number of confirmations (accept_channel.minimum_depth) and/or accept_channel.to_self_delay with the size of the funding amount."

WDYT?

araspitzu · 2020-03-31T07:51:06Z

On a second thought: do we really need to mention the to-self delay and the eclipsing attack here? It seems to me that this kind of attack can be already performed on any node with enough funds at stake, an attacker that can pin you to a delayed view of the blockchain can take advantage of this to broadcast an old state of all the channels it has with you, so this kind of attack is not strictly related to large channels. WDYT @ariard?

araspitzu · 2020-06-03T14:37:35Z

Closing for lack of traction and since it's overlapping with #772

ariard · 2020-06-05T02:05:42Z

@araspitzu seeing this only now. My SECURITY.md is about direct security vulnerabilities disclosure. In this PR, it's more LN node OPSEC.md, I would put down such write-up soon.

Add advisory section for wumbo channels:

1bcd157

We advise the implementors to provide the means to increase the number confirmations needed to confirm large channels

t-bast reviewed Feb 18, 2020

View reviewed changes

Replace Implementors with Implementers to please the spellchecker

c79b82a

cdecker mentioned this pull request Feb 28, 2020

Lightning Specification Meeting 2020/03/02 #744

Closed

15 tasks

ariard reviewed Mar 2, 2020

View reviewed changes

t-bast reviewed Mar 2, 2020

View reviewed changes

02-peer-protocol.md Outdated Show resolved Hide resolved

Advise for the block reward to largely exceed the funding amount

2cfe2c6

t-bast mentioned this pull request Mar 16, 2020

Lightning Specification Meeting 2020/03/16 #756

Closed

18 tasks

TheBlueMatt reviewed Mar 16, 2020

View reviewed changes

Address PR feedback

6cc31bb

t-bast approved these changes Mar 18, 2020

View reviewed changes

t-bast mentioned this pull request Mar 27, 2020

Lightning Specification Meeting 2020/03/30 #757

Closed

18 tasks

t-bast mentioned this pull request Apr 13, 2020

Lightning Specification Meeting 2020/04/13 #766

Closed

15 tasks

araspitzu closed this Jun 3, 2020

araspitzu deleted the wumbo_advisory_section branch June 3, 2020 14:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add advisory section for wumbo channels confirmations #746

Add advisory section for wumbo channels confirmations #746

araspitzu commented Feb 18, 2020

t-bast left a comment

ariard left a comment

ariard Mar 2, 2020

t-bast Mar 2, 2020

ariard Mar 5, 2020

araspitzu commented Mar 3, 2020

TheBlueMatt Mar 16, 2020

araspitzu Mar 18, 2020

t-bast Mar 18, 2020

araspitzu Mar 18, 2020

t-bast left a comment

ariard commented Mar 19, 2020

cdecker commented Mar 30, 2020

t-bast commented Mar 30, 2020

rustyrussell commented Mar 30, 2020 •

edited

Loading

t-bast commented Mar 30, 2020 •

edited

Loading

araspitzu commented Mar 31, 2020

araspitzu commented Jun 3, 2020

ariard commented Jun 5, 2020

Add advisory section for wumbo channels confirmations #746

Add advisory section for wumbo channels confirmations #746

Conversation

araspitzu commented Feb 18, 2020

t-bast left a comment

Choose a reason for hiding this comment

ariard left a comment

Choose a reason for hiding this comment

ariard Mar 2, 2020

Choose a reason for hiding this comment

t-bast Mar 2, 2020

Choose a reason for hiding this comment

ariard Mar 5, 2020

Choose a reason for hiding this comment

araspitzu commented Mar 3, 2020

TheBlueMatt Mar 16, 2020

Choose a reason for hiding this comment

araspitzu Mar 18, 2020

Choose a reason for hiding this comment

t-bast Mar 18, 2020

Choose a reason for hiding this comment

araspitzu Mar 18, 2020

Choose a reason for hiding this comment

t-bast left a comment

Choose a reason for hiding this comment

ariard commented Mar 19, 2020

cdecker commented Mar 30, 2020

t-bast commented Mar 30, 2020

rustyrussell commented Mar 30, 2020 • edited Loading

t-bast commented Mar 30, 2020 • edited Loading

araspitzu commented Mar 31, 2020

araspitzu commented Jun 3, 2020

ariard commented Jun 5, 2020

rustyrussell commented Mar 30, 2020 •

edited

Loading

t-bast commented Mar 30, 2020 •

edited

Loading