0

There are two timelocks in Lightning that both channel counterparties must agree to if a channel is going to be opened between them. These are (from BOLT5) to_self_delay (a CSV relative timelock) which is relevant when a channel counterparty tries to cheat you and cltv_expiry (a CLTV absolute timelock) which is relevant when you don't receive the preimage of a HTLC you've agreed to route.

Firstly, are the different Lightning implementations all converging on similar defaults for these timelocks? What are they, how do they differ?

Secondly, what is the negotiation process for these timelocks? Say I'd ideally like x for the timelock, my channel counterparty would ideally like y but we're happy to agree to a halfway house. Or even it has to be x for me otherwise I don't want to open the channel? I'm assuming this kind of thing isn't possible and the "negotiation" is just "Here's the offer. Accept it or not. If you reject it I don't actually know the reason you rejected it. It may have been because you wanted a higher timelock which maybe I'd have been perfectly happy with but I never knew that's what you wanted."

Improve this question

1 Answer 1

Reset to default
2

For eclair, those values are set in your eclair.conf, and you can set the maximum values you expect from your peers: https://github.com/ACINQ/eclair/blob/5b1c69cc8483626564b03805c2d92b11d0930e93/eclair-core/src/main/resources/reference.conf#L127C8-L127C14

When a peer uses a value outside of the configured range, the error eclair returns clearly indicates why: https://github.com/ACINQ/eclair/blob/5b1c69cc8483626564b03805c2d92b11d0930e93/eclair-core/src/main/scala/fr/acinq/eclair/channel/ChannelExceptions.scala#L50

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.