<p>No it does not have to be the same value.</p>
<p>The timelock somewhat reflects the openness to risk. The lower the value the quicker a node has to engage into force close if there is an unsettled htlc and the partner does not respond to communication.</p>
<p>Thus the higher your partner's cltv delta the longer you can be offline before your partner might force close channels. AFAIK there is currently no real recommendation for the cltv delta. Though nodes seem to lower the default value over time. Remember that high values can lead to longer locked funds. This it is a tradeoff anyway</p>

CC BY-SA 4.0
2020-09-09T08:32:33.877Z
2020-09-09T08:32:33.877Z
Rene Pickhardt
<p>An HTLC passing from node 1 (here Caffeine) to node 2 (here HODLcat.com) will be added a 144 blocks time-lock.</p>
<p>An HTLC passing from node 2 (here HODLcat.com) to node 1 (here Caffeine) will be added a 10 blocks time-lock.</p>
<p>The channel operation does not depend of the <a href="https://en.bitcoin.it/wiki/Timelock#CheckLockTimeVerify" rel="nofollow noreferrer">CLTV</a> deltas, it really is a pure personal setting as it defines the time a forwarding node has to redeem an HTLC on-chain in case it gets timed out down the route and your peer becomes unresponsive.</p>
<p>However, wallets take it into account when computing routes as they sum up along the route and determine how many blocks funds of the end-payer may be stuck in a worst-case scenario.</p>
<p>You can find more details <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection" rel="nofollow noreferrer">in the specification</a> (it's called <code>cltv_expiry_delta</code>), which gives a really detailed explanation and some recommendations which have been updated lately with the discovery of the recent attacks.</p>

CC BY-SA 4.0
2020-09-09T08:42:22.180Z
2020-09-09T08:42:22.180Z
Antoine Poinsot
<p>Consider this channel <a href="https://1ml.com/channel/612829298476056576" rel="nofollow noreferrer">https://1ml.com/channel/612829298476056576</a> :</p>
<pre><code>Node 1: Caffeine
        Time Lock Delta: 10

Node 2: HODLcat.com
        Time Lock Delta: 144
</code></pre>
<p>How is an HTLC passing through this channel affected ?
Would the channel work more reliably if the time-lock deltas were the same?</p>

<lightning-network><lightning-routing><locktime>
Should the nodes of a channel have the same Time Lock Delta?
alec_djinn
# Should the nodes of a channel have the same Time Lock Delta?

(Asked by: username_0 on 2020-09-09)

Consider this channel https://1ml.com/channel/612829298476056576 :
Node 1: Caffeine
        Time Lock Delta: 10

Node 2: HODLcat.com
        Time Lock Delta: 144

How is an HTLC passing through this channel affected ?
Would the channel work more reliably if the time-lock deltas were the same?

**Tags:** lightning-network, lightning-routing, locktime


---

## 2 answers

### Answer by username_1 on 2020-09-09. Score: 2

No it does not have to be the same value.

The timelock somewhat reflects the openness to risk. The lower the value the quicker a node has to engage into force close if there is an unsettled htlc and the partner does not respond to communication.

Thus the higher your partner's cltv delta the longer you can be offline before your partner might force close channels. AFAIK there is currently no real recommendation for the cltv delta. Though nodes seem to lower the default value over time. Remember that high values can lead to longer locked funds. This it is a tradeoff anyway


---

### Answer by username_2 on 2020-09-09. Score: 1

An HTLC passing from node 1 (here Caffeine) to node 2 (here HODLcat.com) will be added a 144 blocks time-lock.

An HTLC passing from node 2 (here HODLcat.com) to node 1 (here Caffeine) will be added a 10 blocks time-lock.

The channel operation does not depend of the [CLTV](https://en.bitcoin.it/wiki/Timelock#CheckLockTimeVerify) deltas, it really is a pure personal setting as it defines the time a forwarding node has to redeem an HTLC on-chain in case it gets timed out down the route and your peer becomes unresponsive.

However, wallets take it into account when computing routes as they sum up along the route and determine how many blocks funds of the end-payer may be stuck in a worst-case scenario.

You can find more details [in the specification](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection) (it's called `cltv_expiry_delta`), which gives a really detailed explanation and some recommendations which have been updated lately with the discovery of the recent attacks.


---

