Hashed Timelock Contract はハッシュ条件と時間制限を組み合わせます。Lightning は各 HTLC に payment_hash、金額、cltv_expiry を使用します。一致する payment_preimage によって経路を逆向きに履行でき、timeout は別の決済経路を提供します。安全性は確定したチャネル状態、署名、適時の対応にも依存します。
受取人は SHA-256 が payment_hash と一致する32バイトの payment_preimage を提供します。BOLT 11 はハッシュを請求書の p フィールドに格納します。ハッシュだけでは秘密は明らかになりません。同じ preimage が連続する HTLC の条件を結び付けます。s フィールドの payment_secret は別の値で、preimage の代わりにはなりません。 [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry]
Lightning の cltv_expiry は絶対ブロック高であり、Unix timestamp や秒単位の BOLT 11 請求書有効期間ではありません。時間条件を満たすと timeout による使用が可能になる場合があります。有効な preimage が自動的に無効になることはなく、同じ出力の競合する使用が同一の有効なチェーンで両方承認されることもありません。返金は自動ではありません。 [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry] [BIP 65 — CHECKLOCKTIMEVERIFY]
update_add_htlc は追加を提案し、update_fulfill_htlc または update_fail_htlc は履行や失敗を処理します。メッセージ単体では状態移行は完了しません。commitment_signed と revoke_and_ack により双方で新状態への署名と旧状態の失効を確保します。通常の支払いに新しいブロック記録は不要ですが、チャネルへの入金と閉鎖には bitcoin トランザクションを使用します。 [BOLT 2 — Channel state and HTLC handling]
update_add_htlc の基本フィールドは channel_id、id、amount_msat、payment_hash、cltv_expiry、onion_routing_packet です。amount_msat の単位は millisatoshi です。ノードはチャネルの上限、利用可能な流動性、転送条件を検証し、送信側 HTLC には固有のパラメーターがあります。BOLT 2 に従い、受信側の追加が取り消し不能に確定するまで、対応する送信側 HTLC を提示してはなりません。 [BOLT 2 — Channel state and HTLC handling]
ノードは自身の onion 層を復号し、完全性を検証します。通常の非ブラインド経路では amt_to_forward と outgoing_cltv_value を受信金額、手数料、必要な期限差と照合します。パケットは経路全体を開示しません。ただし通信の相関分析や他の方法による身元の推定は排除されず、onion routing は完全な匿名性を保証しません。 [BOLT 4 — Onion routing and payload validation]
受信側 HTLC の期限は、対応する送信側 HTLC より後でなければなりません。cltv_expiry_delta の差は、仲介者が preimage を取得し、相手方が応答しない場合に対応し、オンチェーンで承認を得るための余裕です。遅延や再編成のリスクを考慮します。ブロック数は一定の分数を保証しません。余裕が小さすぎると資金が危険にさらされます。 [BOLT 2 — Channel state and HTLC handling]
BOLT 3 は offered と received の出力、および HTLC-success と HTLC-timeout の経路を区別します。単にハッシュを知っているだけでは不十分で、対応する署名、preimage、時間条件が適用されます。ローカルの第2段階出力には to_self_delay の CSV 遅延があり、正しい失効鍵を持つ相手方はその遅延なしでペナルティ分岐を使用できます。正確な Script はチャネルの種類に依存します。 [BOLT 3 — HTLC transaction scripts and trimming] [BIP 112 — CHECKSEQUENCEVERIFY]
該当する第2段階手数料を差し引いた金額が dust_limit_satoshis 未満なら、コミットメントトランザクションは HTLC 出力を作成しません。ルールは合意した種類によって異なります。option_anchors と zero_fee_commitments にはその第2段階手数料がなく、zero_fee_commitments は除外した金額を shared_anchor に割り当てる場合があります。存在しない出力を独立にオンチェーン請求することはできません。こうした HTLC の合計が dust exposure です。 [BOLT 3 — HTLC transaction scripts and trimming] [BOLT 2 — Channel state and HTLC handling]
同じ秘密が経路上の条件を結び付けますが、提示の受諾だけで支払い完了は保証されません。流動性、利用可能な HTLC 枠数、手数料、期限、ルーティング規則によって支払いが止まることがあります。安全な履行や失敗処理には、正しい更新順序と適時の解決が必要です。preimage の開示は bitcoin トランザクションの承認とは異なります。 [BOLT 2 — Channel state and HTLC handling] [BOLT 4 — Onion routing and payload validation]
受信側と送信側の amount_msat、payment_hash、cltv_expiry を比較し、SHA-256 で preimage を検証します。単一の fulfill/fail メッセージだけでなく、commitment_signed、revoke_and_ack、最終状態も追跡します。オンチェーンで強制する際は実際のコミットメントトランザクションをデコードし、出力の存在、使用する分岐、HTLC-success/HTLC-timeout を確認します。署名、時間条件、承認を確認してください。デコードだけでは有効性を証明できません。 [BOLT 2 — Channel state and HTLC handling] [BOLT 3 — HTLC transaction scripts and trimming]
理解を深めるには、この項目とあわせて次もお読みください Lightning Network, Payment Channel, Timelock, 暗号学的ハッシュ, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY. 次の項目からも参照されています Timelock, Payment Channel, Lightningの流動性, Lightning Routing.