Lightning Watchtowerは、決済チャネルの利用者に代わってBitcoinのチェーンを監視するサービスです。相手が取り消された状態を公開した場合、事前に準備した資金回収トランザクションを送信できます。ノード停止中の保護に役立ちますが、正しいデータ、接続、そして間に合う確認が必要です。ノードはチャネルを管理し、Lightning決済を処理するプログラムです。接続が切れている間は、他の参加者と通信できません。
AnnaとPavelは決済チャネルを持っています。資金はBitcoin上で共同でロックされ、Lightningの支払いによってその配分が変わります。PavelがAnnaに支払い、二人は新しい残高に合意して古い状態を取り消します。その後、Annaのネット接続が切れました。もしPavelが古い状態を公開すれば、すでに支払ったお金を取り戻そうとできます。Annaはこのような事態に備えてLightning Watchtowerを利用できます。彼女のノードは、取り消された状態を保護するための暗号化データを事前に送ります。サービスがチェーン上で該当トランザクションを見つけると、Annaが接続していなくても回収トランザクションを送信できます。Annaの代わりに支払うわけでも、ノードの接続を直すわけでもありません。 [1] [8]
合意した資金配分ごとに、commitment transactionがあります。これはBitcoinのチェーン上でチャネルを閉じられる、署名済みのトランザクションです。状態を更新する際、参加者は、直前の取り消された状態が公開されたときにペナルティを適用できる情報を交換します。この記事では、このペナルティ方式のチャネルを説明します。Pavelが現在の有効な状態を使うなら、Annaがオフラインでも一方的に閉じることは認められています。Watchtowerはその閉鎖を妨げるためのものではありません。対象は特定の取り消された状態であり、Pavelが意図的に公開した場合も、古いバックアップから誤って公開した場合も同じです。重要なのは状態の取り消しで、トランザクションの古さではありません。 [1] [8]
Seed Phraseは単語の形で記録するバックアップで、決済への署名に必要な秘密鍵を復元するために使います。LNDはLightningノードを動かすソフトウェアの一つです。AnnaはSeed Phraseやウォレット全体の秘密鍵を渡しません。特定の対応に必要な限られた資料と署名を渡します。LNDではこの一式をJusticeKitと呼びます。justice transactionと呼ばれる回収トランザクションは、事前に用意した条件に従って保護対象の資金を戻します。これによってWatchtowerがAnnaのほかのコインを自由に使えるわけではありません。サービスへの報酬がない方式では、保護対象額からBitcoinトランザクションの手数料が差し引かれます。コードには監視塔への報酬を含む型もありますが、それだけで特定の運営者が有料サービスを提供しているとは言えません。 [3] [4] [5]
Watchtowerが役立つには、必要なデータを実際に受け取っている必要があります。設定にアドレスを入れたり、送信待ちの作業が表示されたりするだけでは十分ではありません。クライアント、つまり監視塔と通信するAnnaのノードの部分は、更新が受信されたという応答を受け取る必要があります。接続が切れることも、sessionと呼ぶ保存の取り決めが容量を使い切ることも、バックアップが拒否されることもあります。そのためAnnaは未達の更新やエラーも確認します。受理済みでも成功が保証されるわけではありません。監視塔は正しいチェーンを追い続け、対応トランザクションを時間内にブロックで確認させる必要があります。 [6] [8]
Annaが端末を失くしても、Watchtowerから端末を復元するわけではありません。このサービスは取り消された状態の悪用を監視するもので、ウォレットを復元したり、鍵の盗難を解決したりはしません。LNDはチャネル復旧にStatic Channel Backup（SCB）を使います。ウォレットのseedと組み合わせ、チャネルを閉じて資金を取り戻すためのもので、停止直前の状態からそのまま運転を再開するものではありません。SCBはすべての更新のコピーでも、監視塔向けの暗号化パッケージでもありません。正しい復旧手順なしに古いchannel.dbを起動すると、自分の取り消された状態を公開しかねず、特に危険です。利用するウォレットとバージョンの手順に従ってバックアップを準備してください。 [7]
トランザクションの出力には、金額と、そのお金を使うための条件が記されています。この保護は、自分のチャネル状態を公開した側が、遅延付きの自分の出力をすぐには使えないことに基づきます。BOLT 3ではその出力をto_local、待ち時間をto_self_delayと呼びます。CSVは、出力の確認からその遅延をブロック数で測る規則です。相手側は適切な取消鍵があれば、待たずにペナルティ経路を使えます。Watchtowerには先に対応する時間が生まれるわけです。遅延が終わってもペナルティ経路は消えませんが、相手も同じ資金を使えるようになります。競合する支出のどちらが有効に確認されるかで結果が決まります。回収トランザクションを送るだけでは足りず、ブロック数は正確な時間数でもありません。 [1] [9]
サービスを選ぶ前に、何が実際に保護されるか確かめます。HTLCはチャネル内で未完了のまま残ることもある条件付き決済です。残高を監視していても、その決済まで保護されるとは限りません。Dustはここでは、そのトランザクションに含めるには小さすぎる出力を指します。 検証した LND v0.21.3-beta の backupTask は、失効済み commitment に存在する dust ではない to_local と to_remote 出力を準備します。すべての HTLC 出力の一般的な保護は含まず、対応文書では将来の拡張とされています。Bitcoin Scriptは出力を使うための条件を記述する言語です。ペナルティの経路で出力を使えるからといって、特定のタワーが必要なデータを受け取り、その保護を実行できるとは限りません。 [3] [5]
暗号化パッケージを使うため、監視塔がAnnaの全残高を常時読む必要はありません。短い識別子で一致を探し、見つけたトランザクションの情報で復号します。以下は特定のLND版の技術資料です。txidはトランザクション識別子、blobはデータのまとまりを意味します。 LND v0.21.3-beta の BreachHint は、バイナリ txid の SHA-256 の先頭 16 バイトです。BreachKey は、同じバイナリ txid を二つ連結して SHA-256 を計算します。表示された txid の先頭 16 文字でも、単純な前半でもありません。クライアントは JusticeKit を暗号化し、対応するトランザクションが分かれば鍵を導出してデータを復号できます。 [2] [3]
他人向けに監視塔を動かすことと、自分のチャネルを監視してもらうことは別です。以下の設定はLND運営者向けです。RPCはプログラムが命令を受け取るインターフェースです。 LND はサーバー用の watchtower.active とクライアント用の wtclient.active を分けています。サーバーを有効にするだけでは、自分のチャネルを別のタワーにバックアップする設定にはなりません。lncli tower info はサーバーの pubkey、listeners、uris を表示し、lncli wtclient add はクライアントにタワーを登録します。タワーの公開鍵は Lightning ノードの鍵と異なります。ネットワーク、アドレスへの到達性、使用ビルドの RPC 対応を確認してください。 [5]
対応にはBitcoinのブロック領域の手数料が必要です。satoshiはビットコインの最小単位です。仮想バイトは、トランザクションの各部分に割り当てられた異なる重みを考慮してサイズを測る単位です。料率はトランザクションの仮想バイト当たりのsatoshiであり、保護する資金に対する割合ではありません。 LND v0.21.3-beta の policy と session の sweep_sat_per_vbyte フィールドは、sat/vB 単位の手数料率を示します。手数料は返還額を減らします。backupTask は金額不足や不適切な session パラメーターの状態を拒否することがあり、準備済みタスクすべてが適格なバックアップとは限りません。後の設定変更は、署名済みトランザクションが変更された証拠にはならず、低すぎる料率は対応を遅らせる可能性があります。 [3] [6]
一つ目の監視塔が停止したとき、二つ目が役立つのは、そちらも必要なデータを受け取っている場合です。独立性には名前だけでなく、接続や運営者の違いも含まれます。 複数の独立したタワーと自己監視は、一つの障害の影響を減らせます。ただし各タワーが実際に受け取った更新を確認してください。複数アドレスの登録だけでは全状態の複製は証明できません。別々の機器、ネットワーク、設置場所は共通障害を減らします。暗号化 blob と認証済み接続は残高の可視性を制限しますが、メタデータ、更新頻度の露出、相関分析のリスクをなくすものではありません。 [5] [8]
点検では特に、送った更新と実際に受け取られた更新を区別します。以下のコマンドと項目名はLND管理者向けの詳しい資料です。監視塔によるバックアップの受信応答は、ブロック内でのトランザクション確認とは別です。 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 の候補を示すだけで、完全な保護の証明ではありません。 [6]
正しい設定は出発点です。テストでは取り消された状態の検知から保護資金の回収まで、一連の動作を確かめます。自分の実際のお金で試さないでください。 クライアントとタワーの具体的なリリース、対応チャネルと session の型、データの新しさ、手数料、チェーン同期を確認してください。対応機能の試験は隔離したテスト環境で行います。通常の一方的なクローズ（force close） は失効済み状態への対応の証明にはなりません。失効した状態の公開（breach）、再構成された justice transaction、その確認済み出力が結果の証拠です。成功例があっても将来の可用性や Lightning の全リスクの解消は保証されません。 [1] [3] [6]
理解を深めるには、この項目とあわせて次もお読みください Lightning Network, Payment Channel, セルフカストディ. 次の項目からも参照されています Payment Channel.