<p>The timelock value can be up to 14*144 = 2016 or the expected amounts of blocks to be mined with 14 days.</p>

<p>Generally the <code>cltv delta</code> is a trade of:</p>

<p>The higher you choose this value the longer your node can be offline without you rising to lose funds. However other nodes might select not to route payments through you as the routing process if hiring the chain can technically last as long as the cltv delta. </p>

<p>The reason why you will see various values in the gossip <code>update_channel</code> messages (which 1ml depicts) is probably implementations use different default values and have also changed the defaults with various versions. I think it was 144 for one of the implementations and it came down to 6 or 9. Eclair mobile wallet which mainly creates private channels that you don't see on 1ml users 2016 because mobile phones might have longer downtimes</p>

CC BY-SA 4.0
2019-08-10T07:39:10.953Z
2019-08-10T07:39:10.953Z
Rene Pickhardt
<blockquote>
  <p>How does TimeLockDelta affect a node?</p>
</blockquote>

<p>TimeLockDelta (or <code>cltv_expiry_delta</code>) is the minimum number of blocks a node requires to be added to the expiry of HTLCs. In other words, this value represents the required gap between the timelocks of the incoming and outgoing HTLC to this node. Once an HTLC times out, it can either be fulfilled or timed-out which means the node must take care to be around this transition and fulfill both the offered and received HTLCs. If the node does not fulfill this in due period of time, the peer will be able to get its funds back by spending the time-out transaction. </p>

<p>To illustrate this with an example, say your peer that you forwarded the HTLC to (outgoing HTLC) sends you the pre-image of the HTLC that was added sometime back. You make a payment to your peer for providing the pre-image successfully. Now it is up to you to redeem this payment from the peer through which you received the HTLC (incoming HTLC). If you wait long enough such that the expiry times out, then you are at risk of losing your funds because the peer who sent you the HTLC will use the time-out transaction to get its funds. So you are in a scenario where you have paid the outgoing HTLC, but you cannot claim the funds from the incoming HTLC.</p>

<p>So the value of the TimeLockDelta should be chosen in such a way that it is not too large such that other nodes do not send payments through you, but also not too small that you might risk losing your funds because you did not have enough time to satisfy the incoming HTLC. The below calculation shows the various cases that can crop up when fulfilling HTLCs and the optimum value that needs to be chosen for it.</p>

<blockquote>
  <p>what is considered to be a decent value for it?</p>
</blockquote>

<p>Below is the text from <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection" rel="nofollow noreferrer">BOLT #2</a> which has the calculations and various cases needed for determining what the <code>cltv_expiry_delta</code> a node should set for itself.</p>

<p>The worst-case number of blocks between outgoing and incoming HTLC resolution can be derived, given a few assumptions:</p>

<ul>
<li>a worst-case reorganization depth <code>R</code> blocks</li>
<li>a grace-period <code>G</code> blocks after HTLC timeout before giving up on an unresponsive peer and dropping to chain</li>
<li>a number of blocks <code>S</code> between transaction broadcast and the transaction being included in a block</li>
</ul>

<p>The worst case is for a forwarding node (B) that takes the longest possible time to spot the outgoing HTLC fulfillment and also takes the longest possible time to redeem it on-chain:</p>

<ol>
<li>The B->C HTLC times out at block <code>N</code>, and B waits <code>G</code> blocks until it gives up waiting for C. B or C commits to the blockchain, and B spends HTLC, which takes <code>S</code> blocks to be included.</li>
<li>Bad case: C wins the race (just) and fulfills the HTLC, B only sees that transaction when it sees block <code>N+G+S+1</code>.</li>
<li>Worst case: There's reorganization <code>R</code> deep in which C wins and fulfills. B only sees transaction at <code>N+G+S+R</code>.</li>
<li>B now needs to fulfill the incoming A->B HTLC, but A is unresponsive: B waits <code>G</code> more blocks before giving up waiting for A. A or B commits to the blockchain.</li>
<li>Bad case: B sees A's commitment transaction in block <code>N+G+S+R+G+1</code> and has to spend the HTLC output, which takes <code>S</code> blocks to be mined.</li>
<li>Worst case: there's another reorganization <code>R</code> deep which A uses to spend the commitment transaction, so B sees A's commitment transaction in block <code>N+G+S+R+G+R</code> and has to spend the HTLC output, which takes <code>S</code> blocks to be mined.</li>
<li>B's HTLC spend needs to be at least <code>R</code> deep before it times out, otherwise another reorganization could allow A to timeout the transaction.</li>
</ol>

<p>Thus, the worst case is <code>3R+2G+2S</code>, assuming <code>R</code> is at least 1. Note that the chances of three reorganizations in which the other node wins all of them is low for <code>R</code> of 2 or more. Since high fees are used (and HTLC spends can use almost arbitrary fees), <code>S</code> should be small; although, given that block times are irregular and empty blocks still occur, <code>S=2</code> should be considered a minimum. Similarly, the grace period <code>G</code> can be low (1 or 2), as nodes are required to timeout or fulfill as soon as possible; but if <code>G</code> is too low it increases the risk of unnecessary channel closure due to networking delays.</p>

<p>There are four values that need be derived:</p>

<ol>
<li>The <code>cltv_expiry_delta</code> for channels, <code>3R+2G+2S</code>: if in doubt, a <code>cltv_expiry_delta</code> of 12 is reasonable (R=2, G=1, S=2).</li>
<li>The deadline for offered HTLCs: the deadline after which the channel has to be failed and timed out on-chain. This is <code>G</code> blocks after the HTLC's <code>cltv_expiry</code>: 1 block is reasonable.</li>
<li>The deadline for received HTLCs this node has fulfilled: the deadline after which the channel has to be failed and the HTLC fulfilled on-chain before its <code>cltv_expiry</code>. See steps 4-7 above, which imply a deadline of <code>2R+G+S</code> blocks before <code>cltv_expiry</code>: 7 blocks is reasonable.</li>
<li>The minimum <code>cltv_expiry</code> accepted for terminal payments: the worst case for the terminal node C is <code>2R+G+S</code> blocks (as, again, steps 1-3 above don't apply).</li>
</ol>

<p>The default value for <code>cltv_expiry_delta</code> in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md" rel="nofollow noreferrer">BOLT #11</a> is 9, which is slightly more conservative than the 7 that the above calculation suggests.</p>

CC BY-SA 4.0
2024-06-17T15:21:11.820Z
In LND, the default value for `bitcoin.timelockdelta` is `80`:
https://docs.lightning.engineering/lightning-network-tools/lnd/optimal-configuration-of-a-routing-node#channel-defaults

and in clightning `cltv-delta` the default is `34`:
`lightning-cli listconfigs | jq '.configs."cltv-delta"'`
northben
CC BY-SA 4.0
2024-06-27T16:04:35.753Z
@northben please suggest an update. That's a good point since this answer is 5 years old
Ugam Kamat
CC BY-SA 4.0
2019-08-10T07:51:03.220Z
2019-08-10T14:18:12.463Z
2019-08-10T14:18:12.463Z
Ugam Kamat
<p>Looking at the settings of some nodes on 1ml.com, I noticed the <code>Time Lock Delta</code> variable could vary a lot. How does it affect a node, and what is considered to be a decent value for it?</p>

<lightning-network>
What is a decent value for Time Lock Delta on a lightning network node?
alec_djinn
# What is a decent value for Time Lock Delta on a lightning network node?

(Asked by: username_0 on 2019-08-09)

Looking at the settings of some nodes on 1ml.com, I noticed the `Time Lock Delta` variable could vary a lot. How does it affect a node, and what is considered to be a decent value for it?

**Tags:** lightning-network


---

## 2 answers

### Answer by username_2 on 2019-08-10. Score: 4 | Accepted answer

> How does TimeLockDelta affect a node?

TimeLockDelta (or `cltv_expiry_delta`) is the minimum number of blocks a node requires to be added to the expiry of HTLCs. In other words, this value represents the required gap between the timelocks of the incoming and outgoing HTLC to this node. Once an HTLC times out, it can either be fulfilled or timed-out which means the node must take care to be around this transition and fulfill both the offered and received HTLCs. If the node does not fulfill this in due period of time, the peer will be able to get its funds back by spending the time-out transaction.

To illustrate this with an example, say your peer that you forwarded the HTLC to (outgoing HTLC) sends you the pre-image of the HTLC that was added sometime back. You make a payment to your peer for providing the pre-image successfully. Now it is up to you to redeem this payment from the peer through which you received the HTLC (incoming HTLC). If you wait long enough such that the expiry times out, then you are at risk of losing your funds because the peer who sent you the HTLC will use the time-out transaction to get its funds. So you are in a scenario where you have paid the outgoing HTLC, but you cannot claim the funds from the incoming HTLC.

So the value of the TimeLockDelta should be chosen in such a way that it is not too large such that other nodes do not send payments through you, but also not too small that you might risk losing your funds because you did not have enough time to satisfy the incoming HTLC. The below calculation shows the various cases that can crop up when fulfilling HTLCs and the optimum value that needs to be chosen for it.

> what is considered to be a decent value for it?

Below is the text from [BOLT #2](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection) which has the calculations and various cases needed for determining what the `cltv_expiry_delta` a node should set for itself.

The worst-case number of blocks between outgoing and incoming HTLC resolution can be derived, given a few assumptions:

* a worst-case reorganization depth `R` blocks
* a grace-period `G` blocks after HTLC timeout before giving up on an unresponsive peer and dropping to chain
* a number of blocks `S` between transaction broadcast and the transaction being included in a block

The worst case is for a forwarding node (B) that takes the longest possible time to spot the outgoing HTLC fulfillment and also takes the longest possible time to redeem it on-chain:

1. The B->C HTLC times out at block `N`, and B waits `G` blocks until it gives up waiting for C. B or C commits to the blockchain, and B spends HTLC, which takes `S` blocks to be included.
2. Bad case: C wins the race (just) and fulfills the HTLC, B only sees that transaction when it sees block `N+G+S+1`.
3. Worst case: There's reorganization `R` deep in which C wins and fulfills. B only sees transaction at `N+G+S+R`.
4. B now needs to fulfill the incoming A->B HTLC, but A is unresponsive: B waits `G` more blocks before giving up waiting for A. A or B commits to the blockchain.
5. Bad case: B sees A's commitment transaction in block `N+G+S+R+G+1` and has to spend the HTLC output, which takes `S` blocks to be mined.
6. Worst case: there's another reorganization `R` deep which A uses to spend the commitment transaction, so B sees A's commitment transaction in block `N+G+S+R+G+R` and has to spend the HTLC output, which takes `S` blocks to be mined.
7. B's HTLC spend needs to be at least `R` deep before it times out, otherwise another reorganization could allow A to timeout the transaction.

Thus, the worst case is `3R+2G+2S`, assuming `R` is at least 1. Note that the chances of three reorganizations in which the other node wins all of them is low for `R` of 2 or more. Since high fees are used (and HTLC spends can use almost arbitrary fees), `S` should be small; although, given that block times are irregular and empty blocks still occur, `S=2` should be considered a minimum. Similarly, the grace period `G` can be low (1 or 2), as nodes are required to timeout or fulfill as soon as possible; but if `G` is too low it increases the risk of unnecessary channel closure due to networking delays.

There are four values that need be derived:

1. The `cltv_expiry_delta` for channels, `3R+2G+2S`: if in doubt, a `cltv_expiry_delta` of 12 is reasonable (R=2, G=1, S=2).
2. The deadline for offered HTLCs: the deadline after which the channel has to be failed and timed out on-chain. This is `G` blocks after the HTLC's `cltv_expiry`: 1 block is reasonable.
3. The deadline for received HTLCs this node has fulfilled: the deadline after which the channel has to be failed and the HTLC fulfilled on-chain before its `cltv_expiry`. See steps 4-7 above, which imply a deadline of `2R+G+S` blocks before `cltv_expiry`: 7 blocks is reasonable.
4. The minimum `cltv_expiry` accepted for terminal payments: the worst case for the terminal node C is `2R+G+S` blocks (as, again, steps 1-3 above don't apply).

The default value for `cltv_expiry_delta` in [BOLT #11](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md) is 9, which is slightly more conservative than the 7 that the above calculation suggests.

> **Comments:**
> **username_3**: In LND, the default value for `bitcoin.timelockdelta` is `80`: https://docs.lightning.engineering/lightning-network-tools/lnd/optimal-configuration-of-a-routing-node#channel-defaults  and in clightning `cltv-delta` the default is `34`: `lightning-cli listconfigs | jq '.configs."cltv-delta"'`  
> **username_2**: @username_3 please suggest an update. That's a good point since this answer is 5 years old  

---

### Answer by username_1 on 2019-08-10. Score: 6

The timelock value can be up to 14\*144 = 2016 or the expected amounts of blocks to be mined with 14 days.

Generally the `cltv delta` is a trade of:

The higher you choose this value the longer your node can be offline without you rising to lose funds. However other nodes might select not to route payments through you as the routing process if hiring the chain can technically last as long as the cltv delta.

The reason why you will see various values in the gossip `update_channel` messages (which 1ml depicts) is probably implementations use different default values and have also changed the defaults with various versions. I think it was 144 for one of the implementations and it came down to 6 or 9. Eclair mobile wallet which mainly creates private channels that you don't see on 1ml users 2016 because mobile phones might have longer downtimes


---

