<p>For eclair, those values are set in your <code>eclair.conf</code>, and you can set the maximum values you expect from your peers: <a href="https://github.com/ACINQ/eclair/blob/5b1c69cc8483626564b03805c2d92b11d0930e93/eclair-core/src/main/resources/reference.conf#L127C8-L127C14" rel="nofollow noreferrer">https://github.com/ACINQ/eclair/blob/5b1c69cc8483626564b03805c2d92b11d0930e93/eclair-core/src/main/resources/reference.conf#L127C8-L127C14</a></p>
<p>When a peer uses a value outside of the configured range, the error eclair returns clearly indicates why: <a href="https://github.com/ACINQ/eclair/blob/5b1c69cc8483626564b03805c2d92b11d0930e93/eclair-core/src/main/scala/fr/acinq/eclair/channel/ChannelExceptions.scala#L50" rel="nofollow noreferrer">https://github.com/ACINQ/eclair/blob/5b1c69cc8483626564b03805c2d92b11d0930e93/eclair-core/src/main/scala/fr/acinq/eclair/channel/ChannelExceptions.scala#L50</a></p>

CC BY-SA 4.0
2024-02-07T14:49:35.060Z
2024-02-07T14:49:35.060Z
t-bast
<p>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 <a href="https://github.com/lightning/bolts/blob/master/05-onchain.md" rel="nofollow noreferrer">BOLT5</a>) <code>to_self_delay</code> (a CSV relative timelock) which is relevant when a channel counterparty tries to cheat you and <code>cltv_expiry</code> (a CLTV absolute timelock) which is relevant when you don't receive the preimage of a HTLC you've agreed to route.</p>
<p>Firstly, are the different Lightning implementations all converging on similar defaults for these timelocks? What are they, how do they differ?</p>
<p>Secondly, what is the negotiation process for these timelocks? Say I'd ideally like <code>x</code> for the timelock, my channel counterparty would ideally like <code>y</code> but we're happy to agree to a halfway house. Or even it has to be <code>x</code> for me otherwise I don't want to open the channel? I'm assuming this kind of thing isn't possible and the &quot;negotiation&quot; is just &quot;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.&quot;</p>

<lightning-network><hash-time-locked-contract><ln-opening-channels><checklocktimeverify><checksequenceverify>
What are the default timelocks in Lightning implementations today? How are they negotiated on channel opening?
Michael Folkson
# What are the default timelocks in Lightning implementations today? How are they negotiated on channel opening?

(Asked by: username_0 on 2024-01-30)

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](https://github.com/lightning/bolts/blob/master/05-onchain.md)) `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."

**Tags:** lightning-network, hash-time-locked-contract, ln-opening-channels, checklocktimeverify, checksequenceverify


---

## 1 answers

### Answer by username_1 on 2024-02-07. Score: 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>


---

