lnd wants up to 2016 to_self_delay: should we allow > 3 days?

[rustyrussell]

From IRC:

user@machine:/lightning$ lncli fundchannel 02565b3920e81816040bf477c135cdbfc2c931a11fc41593bd3217b1eb5a399c6f 10000000
(20:22:37) p3tr: { "code" : -1, "message" : "sent ERROR to_self_delay 1201 larger than 432" }
(20:22:40) p3tr: user@machine:/lightning$ lncli fundchannel 02565b3920e81816040bf477c135cdbfc2c931a11fc41593bd3217b1eb5a399c6f 5000000
(20:22:43) p3tr: { "code" : -1, "message" : "sent ERROR to_self_delay 600 larger than 432" }
(20:22:46) p3tr: user@machine:/lightning$ lncli fundchannel 02565b3920e81816040bf477c135cdbfc2c931a11fc41593bd3217b1eb5a399c6f 7500000
(20:22:48) p3tr: { "code" : -1, "message" : "sent ERROR to_self_delay 901 larger than 432" }
(20:22:50) p3tr: { "tx" : "0200000000010125744673...", "txid" : "ac97847d5a070..." }

Looking at the lnd source, it ranges up to 2 weeks depending on the amount in the channel. We don't allow more than 3 days, should we change default?

[practicalswift]

I'm in favor of changing the c-lightning default to allow for lnd's to_self_delay defaults.

From BOLT-02:

The receiving node MUST fail the channel if:

• to_self_delay is unreasonably large.

Two weeks does not seem "unreasonably large" :-)

[cdecker]

I think 2 weeks is absolutely unreasonable, so that's a no from me.

[ZmnSCPxj]

Agree with @cdecker here. 3 days seems eminently reasonable, 4 or 5 days maybe reasonable, possibly a week, but two weeks? It seems unreasonable.

[practicalswift]

Seems like consensus NACK then :-)

Can we get lnd to change the defaults? Having lnd and c-lightning use incompatible defaults seems very unfortunate and is a recipe for a bad user-experience.

[aantonop]

I've submitted a PR to bring the LND max down to 3 days (the max accepted by c-lightning). I think there's probably a middle ground (4-5 days?) that could be met, but for now this is an interoperability problem that's affecting channel creation.

lightningnetwork/lnd#788

Perhaps the c-lightning max to_self_delay can be raised - if 4-5 days is considered "reasonable", even though 2 weeks isn't? I like the idea of having a bit more time than 3 days for a large capacity channel.

[cdecker]

Thanks @aantonop, I think 4-5 days might be fine, but we'll keep the default low since people easily annoyed having to wait a day to get back their funds. The timeout also seems to be surprising to most, so maybe additional education may alleviate that problem 😉

[ajtowns]

FWIW, I think it's probably reasonable to be able to setup channels such that you can safely have your node disconnected/non-functional/disabled for Easter break, which in Australia might last from Thursday night to Tuesday morning, which is about 112h or 672 blocks (5pm Thursday to 9am Tuesday). Letting the user set a maximum of up to a week/1008 blocks seems like a pretty reasonable "round" number there, maybe.

[ZmnSCPxj]

I am fine with 1 week = 1008 blocks; uncomfortably high, but still within the realm of (barely) reasonable.

[Ulmo]

We're presuming the issue is not checking our site for a crash and missing a theft, causing unnecessary loss of funds. This gets extended if the crash was caused by something that needs repair, and that can take up to two days in emergency mode (longer if other things are in the way, especially if it's a bug).

The issue for me is that I can sometimes maintain my nodes on a Friday or Saturday, have a week full of overtime, then come back Sunday, so that's 9 days right there, and if I happened to be efficient Friday but slow Sunday, it could be 10 days. Since I try to always put around 0.1BTC in every channel that I think is "important", to me, it makes sense I wouldn't want to risk that much to just working overtime. I know if you are trying to turn Lightning Network into a professional-only system, that isn't a good metric, but I'm talking about what one person can do on their own in a normal work week environment.

Another consideration is that some vacations last about 5 days, and there's two days packing and three days unpacking, so that's 10 days also.

I'm in favor of the limit being 11 days, which is a "week with personal delays", but under two weeks. Of course, the main issue with that is that you would have to plan to close big channels before the long weeks and reopen them with the correct longer delay; each person would have to consider their situaton. For instance, right now, I could probably get away with 9 days; a week + a weekend (Saturday through Sunday, which is 8 days, but like I said, I could have an efficient Saturday but a slow Sunday and that goes to the 9th day).

If I'm being pedantic, I should consider the case of a weekend ending on a Monday that is a holiday, and the delay could be 12 days. 12 is close enough to 14 that you can just say "it is less than two weeks on purpose; you're supposed to do it within a week."

[ZmnSCPxj]

How would you pay for anything on your vacation if your LN node is turned off? Everybody knows that nobody will accept anything other than Bitcoin, haha.

More seriously, you do bring up a good point. For myself, I conceptualize that, since LN requires 24/7 operation for optimal operation, we will at some point have high-availability high-uptime permanently-connected devices at home that will protect our funds and serve as an LN node; to spend, we will contact that home device with a mobile device. But perhaps that would be quite a long way away.

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

[Ulmo]

As AAntonop said on the LND side, please update "lightningd --help" where the text says:

    --max-locktime-blocks <arg>    Maximum blocks a peer can lock up our funds (default: 432)

to include the string "to_self_delay", so that users looking for the error string can find the solution.