つい先月、Lndが利用するbtcd由来のライブラリのバグによってブロックチェーンを参照できなくなるというトラブルが発生し、Lndユーザーは急いでアップデート作業に追われました。ところが今週もほとんど同じようなバグによるトラブルが発生し、前回と同じユーザーによるトランザクションであったり、今回はLndユーザーを茶化すメッセージがあったことなどからライトニングユーザーや開発者の間でバグ報告のあり方や対応について意見が分かれる場面がありました。

トランザクションの内容

今回のトランザクションは署名を含めたサイズが500KBを超えており、これが前回のようにbtcd由来のライブラリによる検証に引っかかったことが問題の原因となりました。また、この大きなサイズのほかに、OP_RETURNで"you'll run cln. and you'll be happy."とのメッセージが書き込まれていることから、Lndに障害を発生させる意図をもって発行されたトランザクションであることが悪意と捉えられました。

また、前回同様にLndノードの運用者は対応に追われましたが、BitMEXが運営するサイトFork Monitorによるとライトニングチャネルの不正決済を罰するJustice Transactionは観測されておらず、悪用が試行された兆候はありません。

Fork Monitor

バグは報告されていた

今回のバグ、内容としては前回のものとほとんど同じで、しかも前回修正されたコードとほぼ同じ位置にあるものだったため、修正された部分の周辺のコードを読んだユーザーには比較的容易に見つかるようなものでした。少なくとも実際にAnthony Towns氏はおよそ2週間前に直接Lightning LabsのOlaoluwa Osuntokun氏 (roasbeef)にバグの内容を指摘していたそうです。

バグ修正は公開することで悪用する方法も広く知れ渡ってしまうこともあり、再びノード運用者に急遽のアップデートを要求するかどうかの判断が問われます。今回は悪用に必要なトランザクションがビットコインノードの既定のポリシーでは他のノードに伝播されない「ブロックサイズの10%を超える大きなトランザクション」だったことから対応が後回しになったそうです。

今回のトランザクションは直接F2Poolというマイニングプールにメールで提出されたものだという報告があります。

１回目の不具合の際に急を要することから問題が発生した箇所のみの改修がされたため、同時に発見・修正される機会が失われたという指摘は多くありませんが、その当時もトランザクションを発行したBurak氏が事前にLightning Labsに指摘していれば２回目の原因となるコードも発覚し、一度の対応で済んだ可能性は低くないでしょう。その点においても、今回の意見対立の要である「責任あるバグ報告のあり方」というのは振り返ると一度目の事件において厳しく追及されるべきだったことになります。

ちなみに私が知る限り、Lightning Labsにはバグバウンティ制度はありません。そのような制度があったら、リリースするソフトウェアにバグがないことを慎重に確認するインセンティブにもなるため、ぜひ導入されるといいなと思います。(独自トークンでの支払いだとこのインセンティブが弱いのでBTCでお願いします)

不適切という意見、むしろ良かったという意見

Burak氏は１回目も事前にTestnetで問題となるトランザクションを配信してからそのままMainnetでも配信するなど、結果を予想して実行している点において無責任だという批判を浴びています。まずバグの発見を報告し、アップデートによって穏便に対処されることが最善の段取りだという意見です。

その一方で、彼自身がこのバグを発生させることでチャネルの不正決済などによる経済的利益を得ようとした形跡はなく、その点においては悪意があったとは言い難いところがあります。もし１回目のトラブルを受けて悪意のある主体が今回の原因コードを発見していれば、対策がされる前に悪用された可能性は実際にあります。

とは言っても、既定設定を使用しているノードだと24時間以内のアップデート対応ができなさそうなものを狙って悪用する必要がありますが。

以前のバージョンのrust-bitcoinライブラリ、BDK、Liquid Networkの入出金処理など他の実装でも同様のバグが発生していたため、まとめて同時に対応されたというメリットや、Lightning Labsがソフトウェアの安全性をないがしろにしていることに対して警鐘を鳴らす効果があったことなどを指して、今回のやり方はその迷惑以上の価値があったという見方も出ています。

自分はどちらかというと順当に、穏便に済ませてほしかったところですが、Lndのソフトウェアへの信頼は確かに傷ついているのでLightning Labsにはトークン発行プロトコル実装を優先している場合ではないと優先順位をしっかり考えるきっかけにしてほしいとも思います。

こぼれ話：Bitcoin Coreだけ使え！vs 理想論だろ！

余談ですが、裏テーマとして「Bitcoin Core以外のビットコインノード実装の存在が悪」という主張と、複数実装を肯定する主張の対立もあります。確かに圧倒的多数のノードはBitcoin Coreであり、Bitcoin Core自体が「実行できるBitcoinプロトコル仕様」のような性質を持っているため、Bitcoin Coreを使用するのが一番安心なのは間違いありません。(仕様の自然言語化は難しいです)

ほとんどユーザーの存在しないbtcdに加えてBDKもビットコインノード実装でありながら仕様を完璧に再現できていなかったので、Bitcoin Core実装マキシマリスト的意見にとって有効な根拠となりました。

ただ、今回問題となったのはbtcd「由来の」トランザクション読み込み関数で、Lndがbtcdと密結合になっておりトランザクションのパースに使用したコードに問題があったことが理由でした。LndはGoで書かれているので、Bitcoin Core以外のビットコインノード実装が存在しなくとも何らかのGoライブラリを使ってトランザクションをパースし、バグが発生していた可能性があったでしょう。

自身のビットコインノードから取得したトランザクションをなぜ再度検証するのかという部分はさておき、信用できないソースから取得したトランザクションを検証するためのライブラリの需要は高いため、Bitcoin Coreだけで十分という意見は理想論かなと個人的には感じます。