cltv_expiry_delta
minimum expiry delta it requires to relay HTLCs through this channel
MUST set cltv_expiry_delta to the number of blocks it will subtract from an incoming HTLC's cltv_expiry.
incoming HTLC の cltv_expiry の値から cltv_expiry_delta を引いた値が、outgoing HTLC の cltv_expiry に設定される
A -> B -> C -> D とルーティングされる場合、B が B - C channel の cltv_expiry_delta を 40 にしている場合
A - B の HTLC の cltv_expiry と B - C の HTLC の cltv_expiry の差が 40 以上でなければならない、ということ
B - C と C -D の cltv_expiry の差ではないことに注意
1つの channel でも方向によってい設定はことなる。B は B - C channel が B --> C と流れる場合の設定ができる。 C --> B と流れる場合の制御は C の責任範囲である。
cltv_expiry_delta
単に timelock delta と呼ばれることもある
CLTV は HTLC-timeout tx にかかる timelock
delta は、offerd が timeout したにも関わらず、received を fullfil しないといけない状況になった場合に、十分な時間を与える必要がある？
Received HTLC と Offerd HTLC の CLTV の差が小さいと、Offerd HTCL が success して自分は送金できたのに、Receive HTLC が timeout して自分は受け取れなかった、ということが生じる可能性が高まる
Offered の timeout は received の timeout よりも短くないといけない
Offered HTLC からのが取り戻しが完了するまでは、Received HTLC の取り戻しは開始されないでほしい？
なぜなら、offerd から取りっぱぐれたのに、receive も相手にとられる、とういことがありえる
Note that a node is at risk if it accepts an HTLC in one channel and offers an HTLC in another channel with too small of a difference between the CLTV timeouts. For this reason, the cltv_expiry_delta for the outgoing channel is used as the delta across a node.
delta は channel の方向ごとに設定される
channel が open してから、update message で設定する
ルーティングする場合は最初の channel の delta がすべてに適用される？
mastering lightning 読むと、そうは書いていない。delta は channel ごとの値で、それらを足していくように思える
やはりそういう意味ではないと思う。cltv_expiry_delta の値が、その node がルーティングに使われる際の delta として使われる、という当たり前の説明をしているのだと思う。
min_final_cltv_expiry_delta という値もある
これは channel が最後の hop の場合に、その時点での height - cltv_expire >= min_final_cltv_expiry_delta であればよい、ということかな？
ルーティングの時にどのような確認が行われるのか？
A -> B -> C というルートの場合
A -> B の update_add_htlc には cltv_expiry がある。これは A -> B channel が timeout する block height
onion packet も含まれている。これには