CLTV Expiry Delta 時間鎖設定

CLTV Delta in Routing:

Multi-hop Payment Example (Alice -> Bob -> Carol -> Dave):

Current block height: 800,000
Final expiry (Dave): 800,100 (+100 blocks)

Bob's delta: 40    Carol's delta: 40    Dave's delta: 18

Alice ------> Bob ------> Carol ------> Dave
  |            |            |             |
  | HTLC       | HTLC       | HTLC        |
  | expiry:    | expiry:    | expiry:     |
  | 800,180    | 800,140    | 800,100     |

Calculation:
  Dave: 800,100 (min_final_cltv_expiry from invoice)
  Carol -> Dave: 800,100 (no delta needed, final node)
  Bob -> Carol: 800,100 + 40 = 800,140
  Alice -> Bob: 800,140 + 40 = 800,180

Safety Time Window Provided by Delta:

Scenario: Carol receives preimage but needs to settle with Bob

Timeline (block height):

800,100     800,140
   |           |
   v           v
---+===========+------------------------------------>
   |           |
   |           +-- Bob->Carol HTLC expires
   |
   +-- Carol->Dave HTLC expires

Carol's 40-block window:
  • Block 800,100: Dave HTLC expires, Carol's last chance to get preimage
  • Blocks 800,100-800,140: Carol has time to submit preimage to Bob
  • Block 800,140: Bob HTLC expires, Carol's last chance to settle

If delta is too small (e.g., 3 blocks):
  • May not broadcast in time during chain congestion
  • Miners may delay packaging
  • Carol could lose funds!

Recommended CLTV Delta Settings:

Defaults (different implementations):

LND:
  • time_lock_delta: 40 (default)
  • Config: lnd.conf or updatechanpolicy

Core Lightning:
  • cltv_delta: 34 (default)
  • Config: setchannel or config

Eclair:
  • cltv-expiry-delta: 48 (default)
  • Config: eclair.conf

Delta Selection Considerations:

Larger Delta (e.g., 144 = ~1 day):
  [+] Safer, ample time to handle
  [+] Suitable for nodes not always online
  [-] Longer fund lock time
  [-] May be skipped by routing algorithms

Smaller Delta (e.g., 18):
  [+] Shorter fund lock time
  [+] More attractive to payers
  [-] May be unsafe during chain congestion
  [-] Requires highly available node

Balanced Recommendations:
  • Routing nodes: 40-80 (requires reliable monitoring)
  • Personal nodes: 80-144 (more conservative)
  • High-value channels: 144+ (maximum safety)

Final Expiry Settings in Invoices:

BOLT 11 Invoice Field:

min_final_cltv_expiry_delta (c):
  • Type: varint
  • Default: 18 (if not specified)
  • Meaning: Minimum expiry delta required by final node

Example:
  lnbc1u1p...c18... (number after 'c')

If current block height is 800,000:
  Payer must set final HTLC expiry >= 800,018

Receiving Node Validation:

When HTLC received:

if htlc.cltv_expiry < current_height + min_final_cltv:
    reject(INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS)

This ensures receiver has enough time to:
  • Validate payment
  • Decide whether to accept
  • Settle on-chain if necessary

CLTV-Related Errors and Issues:

Error Types:

INCORRECT_CLTV_EXPIRY:
  • Cause: Expiry value doesn't match expected
  • Sender set expiry too small
  • Solution: Retry with larger delta

EXPIRY_TOO_SOON:
  • Cause: HTLC about to expire
  • Route too long causing excessive delta accumulation
  • Solution: Choose shorter route

EXPIRY_TOO_FAR:
  • Cause: Expiry time too far (exceeds max_htlc_cltv)
  • Node has maximum expiry limit set
  • Solution: Choose route with smaller delta

max_htlc_cltv Limit:

Many nodes limit maximum CLTV:

LND default: max_cltv = 2016 (~2 weeks)

Reasons:
  • Avoid funds being locked for too long
  • Reduce wumbo attack vectors
  • Limit channel occupation time

Long Route Problem:
  If route has 20 hops, each with delta=40:
  Total CLTV = 20 x 40 = 800 blocks ~ 5.5 days
  Plus min_final = 18, may approach limit