Timelocks 時間鎖

Timelock Type Comparison

CLTV (OP_CHECKLOCKTIMEVERIFY)
-----------------------------
Type: Absolute timelock
Meaning: Cannot spend before block N
Usage: HTLC timeout, payment routing

Example:
• cltv_expiry = 700000
• HTLC cannot timeout before block height 700000

Script:
<expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP

CSV (OP_CHECKSEQUENCEVERIFY)
----------------------------
Type: Relative timelock
Meaning: Can only spend N blocks after parent tx confirms
Usage: to_local delay, penalty mechanism

Example:
• to_self_delay = 144 (~1 day)
• After channel close, local funds must wait 144 blocks

Script:
<delay> OP_CHECKSEQUENCEVERIFY OP_DROP

HTLC Uses CLTV to Protect Payments

Multi-hop payment CLTV decrement:

Alice --(CLTV: 700100)--> Carol --(CLTV: 700050)--> Bob

Alice -> Carol:
  cltv_expiry = 700100
  "If Carol doesn't claim before block 700100, Alice can reclaim"

Carol -> Bob:
  cltv_expiry = 700050
  "If Bob doesn't claim before block 700050, Carol can reclaim"

Difference = 50 blocks (cltv_expiry_delta)
  Carol has 50 blocks to process

Why Decrement is Needed:

Assume Bob reveals preimage at block 700049:
1. Bob claims Carol's HTLC (before 700050) [checkmark]
2. Carol obtains preimage
3. Carol needs time to claim Alice's HTLC
4. Carol has 50 blocks (700100 - 700050) buffer time

Without decrement:
Carol might lose funds due to block confirmation delays

CSV Timelocks in Commitment Transactions

to_local Output (local balance):
OP_IF
    <revocation_pubkey>
OP_ELSE
    <to_self_delay>
    OP_CSV
    OP_DROP
    <local_delayed_pubkey>
OP_ENDIF
OP_CHECKSIG

Meaning:
• Counterparty can spend immediately with revocation_key (if I cheat)
• I must wait to_self_delay blocks before spending

to_self_delay Purpose:
1. Gives counterparty time to detect and punish cheating
2. Prevents quick fund transfer after publishing old commitment tx
3. Watchtower has sufficient time to respond

Typical values:
• 144 blocks (~1 day): Balance of security and convenience
• 1008 blocks (~1 week): High security needs
• 2016 blocks (~2 weeks): Maximum delay

cltv_expiry_delta Parameter

Definition: CLTV decrement per hop
Source: Announced in channel_update message

Impact Factors:

Too small delta:
• Routing fees may be lower (more competitive)
• But may not have enough time to respond
• Risk: Funds may be lost

Too large delta:
• Safer, sufficient time to respond
• But payment needs longer total timeout
• Sender may choose other paths

Typical values:
• 40 blocks (~7 hours): Aggressive setting
• 80 blocks (~13 hours): Common setting
• 144 blocks (~1 day): Conservative setting
• Minimum: 18 blocks (BOLT spec recommendation)

Total Timeout Calculation:
total_cltv = min_final_cltv_expiry + sum(each hop's cltv_expiry_delta)

Example (3-hop payment):
• min_final_cltv_expiry: 18 blocks
• hop1 delta: 80 blocks
• hop2 delta: 80 blocks
• hop3 delta: 80 blocks
• Total timeout: 18 + 80 + 80 + 80 = 258 blocks (~43 hours)

配置時間鎖參數：

LND（lnd.conf）：
[Bitcoin]
# CLTV delta for forwarding
bitcoin.timelockdelta=80

# 通道開設時的 to_self_delay
[Application Options]
# 發送的 to_self_delay（對方的延遲）
default-remote-max-htlcs=483

CLN（config）：
# CLTV delta
cltv-delta=80

# 最小 final CLTV
cltv-final=18

查看通道的時間鎖設置：
# LND
lncli getchaninfo <channel_id>
# 輸出包含 time_lock_delta

# CLN
lightning-cli listchannels <short_channel_id>
# 輸出包含 delay