c-lightning rejects to_self_delay > 432 as unreasonably long

[aantonop]

While attempting to open a channel to a c-lightning node, I got error:

"to_self_delay 600 greater than 432"

This had been submitted (by others) as an issue to c-lightning. The discussion resulted in a NAK as the developers consider more than 3 days as "unreasonable" and therefore in violation of BOLT-02:

See: ElementsProject/lightning#1110

This creates an interoperability issue for large channels between LND and c-lightning. I don't think this is user-configurable on LND, so I changed it in the source code.

[practicalswift]

Concept ACK

[Roasbeef]

I don't think this is user-configurable on LND, so I changed it in the source code.

We have a --defaultremotedelay parameter for this purpose.

When channels are to the points of tens of millions of satoshis (few thousand dollars), I wouldn't say that a csv delay of 3 days is "unreasonable". At this point, how can we even say what's "unreasonable" and what isn't? There aren't yet widespread production deployments of Lightning yet, so it it seems a bit early to declare what an "reasonable" level of risk is.

[Roasbeef]

We have a private outsourcer implementation that's ~70% done, but have focused on getting 0.4 out of the door (mostly just review is a bottle neck) before we finish it up and integrate it into lnd (so prob 0.4.1). Before widespread private outsourcer deployment, how can one assert what a "sufficient" CSV delay is, especially when tutorials to run on mainnet are being marketed widely to those relatively unfamiliar with Lightning node operation, nor the high-level picture of Lightning as a whole?

[practicalswift]

Is there any middle ground where we achieve short-term c-lightning/lnd compatibility w.r.t. to_self_delay while we figure out the appropriate long-term recommendation for to_self_delay based on actual usage?

I'm afraid there won't be that much actual usage to base that recommendation on unless we achieve short-term compatibility :-)

[Roasbeef]

Users can manually set what their target delay value is, if they're running nodes at this point, they should be savvy enough to pick a particular value for their risk profile.

[Roasbeef]

We'll likely modify our scaling before 0.4 as well.

[halseth]

I would definitely have a delay of >3 days on my channels, weird that c-lightning considers anything above that unreasonable. As mentioned --defaultremotedelay can be used to manually set this, but maybe we should consider adding a flag to openchannel to manually specify as well/instead?

[aantonop]

I was not aware of the --defaultremotedelay flag.I was working with an older implementation of lnd and had missed it. Maybe I should be adding documentation instead of changing this parameter, perhaps including the string "to_self_delay" in the description of the parameter, so that users who face this error are aware of the flag to fix it. Feel free to close this PR, I can offer a better alternative...

[Roasbeef]

One thing we could also do is allow users to specify when opening a channel. Atm, the way the value works, you set it at start up, and then it override our current scaling for all channels created.

[cfromknecht]

Thank you for bringing this up @aantonop! I would be in favor of having this configurable on a per-channel basis, so that it is still possible to have interoperability between lnd and c-lightning for larger channels from the command line.

However, if the developers of lnd and c-lightning do not agree about the relative risks and/or desired security level for a channel, I'd argue that rejecting its creation is the correct behavior. If users want to manually override the recommendations provided by developers, well, this is bitcoin and they're free to do so!

We should warn people, that in general running software outside of a particular developer's interpretation of unreasonable is more likely to invite nasty edge cases, which may have been overlooked or whose full solution may not have been prioritized.

Personally, I cannot responsibly endorse a default delay of 3 days for an initial deployment with real money. I wouldn't feel confident that we could detect, debug, patch, deploy, and recover funds (what if the mempool is backlogged?) in 3 days in 100% of cases. If we only care about fixing trivial bugs or tolerating minor outages, then this is probably fine. However, I don't consider that an acceptable default security model for all channels, especially those with larger capacity being operated by beta software.

[halseth]

Issue #792.

[agustinf]

Let's not just say "leave it to the user to decide", that's always the easy way out for developers, but usability is all about proposing good default. Otherwise we are leaving this "un-interoperable by default".

[halseth]

I think lnd currently has a good default value, keeping in mind that third party "channel watchers" are not built out. In this case we propose to not let the user connect to a node with a delay we deem unsafe, which is a good default?

Of course we want users that know the implications of manually specifying a lower delay to be able to do set it.

[agustinf]

I agree the default on lnd is good. The point is this is an interoperability issue, perhaps there's no code to change here! we should ask c-lightning developers to accept a larger value. They seemed shocked by the "two weeks", but there's space for discussing about accepting 10-12 days. I think that's a better outcome than just asking the user to set their own value when connecting to c-lightning nodes.