Add advisory section for wumbo channels confirmations

[araspitzu]

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.

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

[t-bast]

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?

[araspitzu]

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]

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.

[araspitzu]

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.

[t-bast]

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.

[araspitzu]

Sounds good to me 👍

[t-bast]

ACK 6cc31bb

[cdecker]

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]

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]

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]

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]

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]

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