今週月曜日、突然Lndがビットコイン・ブロックチェーンの最先端を参照できなくなる事案が発生しました。今回は事件の概要、ライトニングノードへの影響、そして今後のライトニングノード運用方法への影響について見ていきます。

当問題はlnd v0.15.2へのアップデートで解決します。

事件の概要

とあるビットコインユーザーが、テストネットおよびメインネットにおいてTaprootの仕様例として998-of-999マルチシグトランザクションを配信しました。

あまりに近頃の手数料が安すぎて、25kvBあるトランザクションも数百円なんですね

TaprootのUTXOには使用時に所謂「通常の送金」と区別できないkeySpendという使用方法と、複数のスクリプトを埋め込むことができて使用したもののみ公開するscriptSpendという使用方法があります。今回はtaptreeに998-of-999マルチシグで使用できるスクリプトが含まれており、これを利用したscriptSpendトランザクションが発行されました。ちなみにTaprootにおけるscriptでは従来のBitcoin scriptにある10,000バイトまでというスクリプトサイズの上限は撤廃されています。

ところが、Lndが使用していたbtcd由来のライブラリの1つがこのスクリプトサイズ上限のTaproot対応を怠っていたため、上記のトランザクションを受信するとそのブロックを不正と判定してしまい、Lndから見たビットコイン・ブロックチェーンが進まない状態となりました。

もちろん、Lndのみのバグだったため、大半のビットコインユーザーは影響を受けていませんが、ライトニングノードのシェアで9割を超えるLndの不具合にライトニングネットワークには多少なり影響が出ました。

具体的な影響

ライトニングノードから見たチェーンが停止すると、次のような影響があります:

・新しいチャネルの開設が(確認)できない
・チャネルの閉鎖が(確認)できない

これらの行動には、ブロックチェーンが進んでトランザクションが取り込まれたことを確認する必要があるためです。(ちなみに最近話題になったZero-confチャネルだと開設すること自体はできるはずですが、トラストレスではありません)

一方で、既存のチャネル上でライトニング送金を行うことは通常通り可能でした。ただ、

・相手が不正なチャネル閉鎖を行っていないか確認できない

という問題があります。ライトニングではチャネルを共有する相手が「過去の相手有利な残高分布」を元に不正にオンチェーン決済をしていないか見張る必要があります。なぜなら、その対策が「オンチェーンでの閉鎖後一定期間内に不正を証明すればその全額を没収できる」というものだからです。この期限はTime Lock Deltaと呼ばれ、チャネルごとに異なる値を設定できますが最頻値は144ブロック(約24時間)です。

ペナルティトランザクションの仕組みは以下の記事がわかりやすいです。英語が読める方はぜひ。

Lightning Network (Part 3) - Where Is The Justice? | BitMEX Blog
Abstract: In our third look at the lightning network, we examine lightning channel closure scenarios and the incentives to punish dishonest parties and prevent them from stealing funds. This punishment mechanism is called a “Justice Transaction”. We explain how to arbitrarily construct a “Justice” s…

すなわち、今回の騒動で24時間以内にLNノードをアップデートできなかった場合は相手に過去のチャネルステートを用いたチャネル閉鎖をされてしまい、かつ取り返せる期限が過ぎてしまう恐れがあったということです。ただし、下記のツールによるとペナルティトランザクションの増加が見られなかったため、実際には火事場泥棒は行われていない確率が高そうです。

Fork Monitor

このほかに、運用者の判断などでとりあえずオフラインになったノードも多くあったため、ライトニングの送金自体にもある程度の障害が発生していたかもしれません。(当時ライトニング送金を試す発想がなかったので、はっきりとは断言できませんが…)

Watchtowerの必要性が再評価されている

今回の事案を受けて、ライトニングノードの代わりにブロックチェーンの監視を行ってくれるWatchtowerの価値を再評価する流れが生まれています。

実はWatchtowerの利用率はライトニングノードの安定性が低かった黎明期をピークに、ノードが落ちにくくなった現在はかなり下がっている印象を受けます。

近頃のWatchtowerの出番といえばモバイル端末でフルノードを動かす際です。省電力化のためにバックグラウンドアプリの接続が切れるためです。

Lndにトラブルが発生したことに対して、WatchtowerはLndベースのものではなく別実装ベースのものを利用したいなどといった声が出てきているなど再び関心が集まっていることから、ある程度の資金をLNで扱うノードは今後はWatchtowerを使って特定の実装を使用することによるリスクを削減するようになっていくかもしれません。

ちなみにWatchtowerはライトニング全体にとっても抑止力として機能しているもので、相手のノードが落ちていても「Watchtowerを利用している可能性がある」こと自体が前述の攻撃を防止している側面があります。したがって、Watchtowerの利用率がある程度高いことはネットワーク全体にとってもセキュリティ面のメリットをもたらします。

逆に、この性質がコモンズの悲劇のような状況につながるかもしれませんが…。

また、最新のステートで残高が非常に大きく攻撃対象ノードに偏っている場合、攻撃のリスクリワード比が攻撃者に好ましくなってしまうなどペナルティの仕組み自体にも問題があります。これを改善するにははEltooなどペナルティに依存せずにトラストレスにライトニングチャネルを更新できる仕組みの導入が期待されますが、まだ先は長いでしょう。

おまけですが、LN関連の脆弱性攻撃ツールLNsploitを使うと、今回の問題のみならず既知の脆弱性や過去のCVEなどを利用してライトニングノードをお手軽に攻撃することができます。割とニッチですが、様々なテストに利用できそうです。

まとめ

・btcdとlndが共有するライブラリの実装漏れに起因するバグで、Lndノードから見たブロックチェーンが停止してしまった。(v0.15.2のパッチで解決)

・ノードがチェーンを監視できず、チャネルの相手から火事場泥棒に遭う危険性が意識され、Watchtowerへの関心が増加

・長期的にはEltooなどペナルティ方式とは異なるライトニングのあり方に期待したい