Lightning Watchtower

ペナルティ方式のチャネルでは、相手が故意または誤って失効済み commitment を公開する場合があります。たとえば、以前の自分に有利な残高の状態です。現在有効な commitment による一方的な閉鎖は、それ自体では違反ではありません。重要なのは、その特定の状態が失効しているかどうかです。タワーは単なるトランザクションの古さではなく、準備されたデータに基づいて対応します。 [BOLT 3 — Revocation and delayed outputs] [Lightning Labs — Watchtower operation]

LND v0.21.3-beta の BreachHint は、バイナリ txid の SHA-256 の先頭 16 バイトです。BreachKey は、同じバイナリ txid を二つ連結して SHA-256 を計算します。表示された txid の先頭 16 文字でも、単純な前半でもありません。クライアントは JusticeKit を暗号化し、対応するトランザクションが分かれば鍵を導出してデータを復号できます。 [LND v0.21.3-beta — Breach hint and key derivation] [LND v0.21.3-beta — Watchtower backup task]

JusticeKit には、特定の救済トランザクション用の署名などの材料が含まれます。タワーは seed も、クライアントの他のコインを自由に使用する権限も受け取りません。無報酬モデルでは、保護資金からオンチェーン手数料を引いてクライアントに返します。報酬モデルでは合意したタワー用出力を追加できますが、コードにその型があるだけでは有料サービスの利用可能性は証明されません。 [LND v0.21.3-beta — Watchtower backup task] [LND v0.21.3-beta — Watchtower blob types] [LND v0.21.3-beta — Watchtower configuration]

クライアントは保護する失効済み状態に対応する更新を作成し、届ける必要があります。タワーのアドレス追加やタスクのキュー登録だけでは、保存の確認にはなりません。接続断、session の枠の使い切り、バックアップの拒否は保護の穴を生みます。タワーは正しいチェーンを監視し、救済トランザクションの伝播と承認を間に合わせる必要もあります。 [LND v0.21.3-beta — Watchtower client RPC] [Lightning Labs — Watchtower operation]

サービスは、紛失した seed、破損したバックアップ、侵害された署名装置を修復できません。LND Static Channel Backup (SCB) はチャネル閉鎖を通じた資金復旧のためのもので、watchtower blob と同じ記録でも、各 commitment を継続的に複製するものでもありません。古い channel.db の復元で失効済み状態が公開されることがあります。ウォレットとチャネルのバックアップは別々に管理する必要があります。 [LND v0.21.3-beta — Recovery and static backups]

検証した LND v0.21.3-beta の backupTask は、失効済み commitment に存在する dust ではない to_local と to_remote 出力を準備します。すべての HTLC 出力の一般的な保護は含まず、対応文書では将来の拡張とされています。したがって、Bitcoin Script がある出力にペナルティを適用できることと、特定のタワーがその出力の保護を実際に保存したことは区別が必要です。 [LND v0.21.3-beta — Watchtower backup task] [LND v0.21.3-beta — Watchtower configuration]

LND はサーバー用の watchtower.active とクライアント用の wtclient.active を分けています。サーバーを有効にするだけでは、自分のチャネルを別のタワーにバックアップする設定にはなりません。lncli tower info はサーバーの pubkey、listeners、uris を表示し、lncli wtclient add はクライアントにタワーを登録します。タワーの公開鍵は Lightning ノードの鍵と異なります。ネットワーク、アドレスへの到達性、使用ビルドの RPC 対応を確認してください。 [LND v0.21.3-beta — Watchtower configuration]

BOLT 3 の to_local 出力では、commitment の所有者は to_self_delay ブロック待つ必要がありますが、正しい失効鍵を持つ相手はその遅延なしでペナルティ分岐を使用できます。CSV は該当する出力の承認からの相対的な経過を測ります。遅延後も失効分岐は消えませんが、所有者も同じ資金の使用を競えるようになります。期限前に送信しただけでは、先に承認される保証はありません。 [BOLT 3 — Revocation and delayed outputs] [BIP 112 — CHECKSEQUENCEVERIFY]

LND v0.21.3-beta の policy と session の sweep_sat_per_vbyte フィールドは、sat/vB 単位の手数料率を示します。手数料は返還額を減らします。backupTask は金額不足や不適切な session パラメーターの状態を拒否することがあり、準備済みタスクすべてが適格なバックアップとは限りません。後の設定変更は、署名済みトランザクションが変更された証拠にはならず、低すぎる料率は対応を遅らせる可能性があります。 [LND v0.21.3-beta — Watchtower backup task] [LND v0.21.3-beta — Watchtower client RPC]

複数の独立したタワーと自己監視は、一つの障害の影響を減らせます。ただし各タワーが実際に受け取った更新を確認してください。複数アドレスの登録だけでは全状態の複製は証明できません。別々の機器、ネットワーク、設置場所は共通障害を減らします。暗号化 blob と認証済み接続は残高の可視性を制限しますが、メタデータ、更新頻度の露出、相関分析のリスクをなくすものではありません。 [LND v0.21.3-beta — Watchtower configuration] [Lightning Labs — Watchtower operation]

lncli wtclient towers、lncli wtclient tower、lncli wtclient stats、lncli wtclient policy を使います。LND v0.21.3-beta では num_backups と num_pending_backups を区別し、後者はタワーからの確認を待つバックアップ数です。stats 応答の num_failed_backups は、確認されなかった失敗バックアップを数えます。統計はクライアント起動以降のものです。active_session_candidate は sessions の候補を示すだけで、完全な保護の証明ではありません。 [LND v0.21.3-beta — Watchtower client RPC]

クライアントとタワーの具体的なリリース、対応チャネルと session の型、データの新しさ、手数料、チェーン同期を確認してください。対応機能の試験は隔離したテスト環境で行います。通常の force close は失効済み状態への対応の証明にはなりません。対応する breach、再構成された justice transaction、その承認済み出力が結果の証拠です。成功例があっても将来の可用性や Lightning の全リスクの解消は保証されません。 [BOLT 3 — Revocation and delayed outputs] [LND v0.21.3-beta — Watchtower backup task] [LND v0.21.3-beta — Watchtower client RPC]