為什麼閃電網路路由中最後一個通道的到期時間不同？

在閃電技術基礎 ( BOLT ) 文件和 lnd 規範中，對路由中的最後一個通道有不同的處理。在BOLT#2中，它指的是一個變數min_final_cltv_expiry：

min_final_cltv_expiry是終端情況 (C) 的 HTLC CLTV 超時和目前塊高度之間的最小差異。

此值為 9，而不是 144 cltv_expiry_delta。

這很可能與查詢 lnd 時路由的輸出有關，例如，假設路由 Alice -> Bob -> Carol -> Dave，從 Alice 路由：輸出為：

$> lncli-alice queryroutes --dest=<Carol_pubkey> --amt=5 --num_max_routes=1
total_time_lock: 1443640
total_fees: 1
total_amt: 6
hops {
 chan_id: <id_chan_alice_bob>
 chan_capacity: <cap>
 amt_to_forward: 6
 expiry: 1443610
 amt_to_forward_msat: 6000
 fee_msat: 1
}
hops {
 chan_id: <id_chan_bob_carol>
 chan_capacity: <cap>
 amt_to_forward: 5
 fee: 1
 expiry: 1443466
 amt_to_forward_msat: 5000
 fee_msat: 1000
}
hops {
 chan_id: <id_chan_carol_dave>
 chan_capacity: <cap>
 amt_to_forward: 5
 expiry: 1443466
 amt_to_forward_msat: 5000
}
total_fees_msat: 1001
total_amt_msat: 6001

請注意最後兩個躍點具有相同的expiry值。為什麼最後一跳的到期時間不同？

在搜尋了BOLT文件並與 lnd slack社區交談後，我找到了答案：

B->C。如果 B 直接向 C 發送 4,999,999 毫秒，它既不會向自己收取費用，也不會添加自己的 cltv_expiry_delta，因此它將使用 C 請求的 min_final_cltv_expiry 為 9。大概它還會添加一條影子路由，以提供額外的 CLTV 42。此外，它可以在其他躍點添加額外的 CLTV 增量，因為這些值表示最小值，但為了簡單起見，這裡選擇不這樣做：

此外，雖然cltv_expiry_delta在 BOLT 中預設為 9 lnd，但他們使用 144，但不檢查最後一跳。也就是說，他們不添加，final_cltv_expiry因為他們已經有一個很大的cltv_expiry（我想）。Olaoluwa 在 slack 中表示，他們計劃降低 BOLT 的值cltv_expiry_delta以接近 BOLT 中列出的預設值。但是，如果他們這樣做，我希望他們注意添加額外的cltv_expiry_delta，因為在這種情況下添加很重要。有關我的意思的範例，請查看上面連結的 BOLT #007 連結

引用自：https://bitcoin.stackexchange.com/questions/81010