en | ja | es | cs | hi | zh | de | fr | pt

Bitcoin Optech Newsletter #411

Jun 26, 2026

今週のニュースレターでは、旧バージョンのLNDに影響するサービス拒否(DoS)脆弱性の責任ある開示について掲載しています。また、Bitcoin Stack Exchangeから選んだ質問とその回答、新しいリリースおよびリリース候補のお知らせ、人気のBitcoin基盤ソフトウェアにおける注目すべき更新を紹介する恒例のセクションも掲載しています。

ニュース

● LNDのゼロタイムスタンプのゴシップDoSの開示: Nishant Bansalは、 LNDのゴシップ処理に対するステートマシンファジングを通じて発見したサービス拒否(DoS)脆弱性を Delving Bitcoinに投稿し、開示しました。 v0.20.1-betaより前のバージョンのLNDは、タイムスタンプがゼロのchannel_updateまたは node_announcementゴシップメッセージによってクラッシュする可能性がありました。 BOLT7はchannel_updateのタイムスタンプがゼロより大きいことを要求していますが、そのルールに違反するメッセージをノードがどう扱うべきかは規定しておらず、 LNDによるその値に対する処理がクラッシュを引き起こしていました。

脆弱なノードがこれらのゼロタイムスタンプメッセージのいずれかを処理しようとすると、内部のブックキーピングエラーによってデータ構造が無効な状態のまま残され、ランタイムパニックが発生してノードが終了していました。攻撃者は、実在の公開チャネル、または攻撃者が管理する2-of-2アウトプットに資金を入れて作成した合成チャネルのいずれかについてアナウンスをブロードキャストすることで、このバグを引き起こせました。後者はライトニングノードを動かさずに安価に繰り返せるものです。

この脆弱性は責任を持って開示され、Matt Morehouseによって独自に確認され、パース時にタイムスタンプがゼロのゴシップメッセージを脆弱なコードに到達する前に拒否することで LND 0.20.1-betaで修正されました。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

● TapscriptのオペコードにOP_IFが含まれているのはバグですか? Antoine Poinsotは、あらゆる支払いポリシーは1つのパスにつき1つのTaprootリーフとして表現できるものの、それが常に最も効率的なエンコードであるとは限らないと説明しています。パスの数と各パスがどれくらいの頻度で使われるかによっては、単一のTapscriptリーフ内のOP_IFの方が、パスを複数のリーフに分割したり、 P2WSHに切り替えたりするよりも支払い時のデータサイズを小さくできる場合があります。
● TapscriptでOP_IFを禁止すると、どのような問題が生じるのでしょうか? Murchは、Taprootアウトプットはリーフスクリプトをハッシュとしてコミットしているため、 miniscriptベースの劣化型マルチシグウォレットのように、どの既存UTXOがOP_IFに依存しているかを知ることは不可能だと指摘します。そのような構成を持つユーザーは、もしその支払いパスが有効でなくなれば、アクティベーション後に受け取った資金を意図せずロックしてしまう恐れがあります。
● ソフトフォークは常に成功しますか? Murchは、強制的なシグナリングを用いるソフトフォークがハッシュレートの少数派にしか支持されていないシナリオを順を追って説明しています。この場合、シグナリングを行うチェーンがProof of Workの蓄積で遅れをとり、ネットワークの残りに新ルールの採用を強制するのではなく、チェーンの進行が停滞してしまうことになります。
● 2026年8月のBIP110アクティベーション後に有効なブロックをマイニングするために、Bitcoin Coreをどう設定すればよいですか? Antoine Poinsotは、Bitcoin CoreはBIP110のルールを強制しておらず、 BIP110が無効とみなすトランザクションを除外したブロックテンプレートを構築する機能も持たないと指摘します。 BIP110準拠のブロックをマイニングしたいノード運用者は、外部のブロックテンプレート構築ソフトウェアを使ってトランザクションを選択するか、空ブロックをマイニングする必要があります。
● BIP110ブロックを含む難易度の低いブランチは有効とみなされますか? Pieter Wuilleは、チェーンが有効であることと、アクティブであることを区別しています。各ブランチの難易度調整はそのブランチ自身のブロックのみに依存するため、潜在的により遅いBIP110ブランチも現行ルールに従うノードにとっては有効ですが、メインチェーンよりも多くの累積Proof of Workを蓄積しない限り、それがアクティブなチェーンになることはありません。
● Bitcoinのテストネットワークにはどのような経緯があるのでしょうか? MurchとAntoine Poinsotが、testnet1から提案中のtestnet5までのtestnetの歴史を振り返ります。これには各ネットワークが収益化されるたびに繰り返されたリセットや、 testnet3で繰り返し発生したブロックストームの原因となった20分間の難易度例外(ニュースレター #311参照)も含まれます。
● -datacarriersizeはなぜ2022年に再定義され、2023年のそれを拡張する提案はなぜマージされなかったのですか? 昨年回答された質問を改めて取り上げ、Murchは補足説明を行いました。datacarrierおよび datacarriersizeオプションは、Bitcoin Core 0.10.0で導入されて以来OP_RETURNアウトプットのみを指すものであったことを、元のコードとリリースノートを引用して明らかにしています。
● 26個の未承認トランザクションのチェーンはBitcoin Core 31.0のウォレットで禁止されていますか? Pol Espinasaは、mempool自体は新しいクラスターmempoolの上限のもとでより長いチェーンを許可するものの、Bitcoin Coreのウォレットはコイン選択時に依然として25トランザクションの制限を強制するため、より長いチェーンはウォレット機能を使わずに構築する必要があると明確にしています。
● Bitcoin Core 29.0にメモリ使用量に影響する変更はありますか? Antoine Poinsotは、見かけ上の増加はプロセスのメモリ使用量が増えたのではなく、レポート上の現象であると明確にしています。Bitcoin Core 29.0は空きメモリがある場合に chainstateデータベースのキャッシュにより多くのデータを保持できるようになっており、そのキャッシュは他のプロセスがメモリを必要とするときに解放される仕組みになっています。
● Bitcoin Coreのリリーススケジュールはどうなっていますか? Murchは、Bitcoin Coreが4月と10月の固定スケジュールでメジャーバージョンをリリースする方針について説明しています。これは、以前の「前回のリリースから6か月後」を目標とする方式（スケジュールが遅延する可能性があった）から変更されたものです。マイナーリリースは引き続き必要に応じてバグ修正を提供します。

リリースとリリース候補

人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。

● LDK v0.1.10は、LN対応ウォレットおよびアプリケーションを構築するためのこのライブラリのメンテナンスリリースです。複数のサービス拒否(DoS)脆弱性とサニタイズの問題に加え、非同期チャネルモニターの永続化、 Electrumとの同期、BOLT12オファーの検証、オニオンメッセージの処理、 MPPのkeysend HTLC、およびルートベースの支払い送信に関連するバグも修正しています。
● LDK v0.2.3は、LN対応ウォレットおよびアプリケーションを構築するためのこのライブラリのメンテナンスリリースです。サービス拒否(DoS)脆弱性、アンカーチャネルのリザーブ計算の誤り、サニタイズの問題を含む複数のセキュリティ問題に加え、非同期チャネルモニターの永続化、LSPSの処理、ゼロ手数料コミットメントチャネル、 BOLT12オファー、オニオンメッセージング、Rapid Gossip Syncのメモリ使用に関連するバグも修正しています。
● BTCPay Server 2.4.0は、このセルフホスト型ペイメントプロセッサのリリースです。グローバル検索、パスキー認証、ガイド付きマルチシグウォレットセットアップ、より細かいウォレット権限設定、サブスクリプションおよびPOSの改善、ウォレットトランザクションの検索とフィルタリング、プラグインエコシステムの改善、更新されたライトニングサポートを追加する一方で、いくつかの非推奨となったライトニングバックエンドを削除しています。

注目すべきコードとドキュメントの更新

最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、Lightning BLIPs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

● Bitcoin Core #35070は、m_blocks_unlinkedへの重複エントリーの追加を防止する変更を行いました。これは、先行するブロックデータが不足しているためまだ接続できないダウンロード済みブロックを追跡するための検証用内部構造です。これまでは、大規模な再編成に直面したプルーニングノードがこの構造に誤って重複エントリーを追加してしまうことがありました。その結果、不足データを受信した後にReceivedBlockTransactions()関数が同じブロックを複数回再検討し、そのnSequenceIdを変更したうえでsetBlockIndexCandidatesに再追加してしまう事態が生じていました。これにより、候補となるチェーン先端のインメモリ順序が破損し、未定義動作につながるおそれがありました。このPRは、エントリーを重複排除する新しいAddUnlinkedBlock()ヘルパー経由で挿入処理を行うようにし、重複が存在しないことを保証するためにCheckBlockIndex()を強化しています。
● Bitcoin Core #35182、#34411は、 RPCおよびRESTで使われているlibeventベースのHTTPサーバーを、Bitcoin Core内でメンテナンスされる新しいHTTPおよびソケット処理の実装に置き換えます。新しいサーバーは独自のI/Oスレッドで動作し、ソケットを直接扱い、受け付けたリクエストを既存のHTTPワーカープールにディスパッチします。後続のPRは、残っていたlibeventのビルド、 CI、依存関係、CMakeの構成要素を削除しています。これらの変更は、外部依存を減らし、ソースからBitcoin Coreをビルドすることを簡素化するプロジェクトの取り組みの一環です。
● BIPs #2198は、P2MR提案であるBIP360(ニュースレター #393 参照)を更新し、深さゼロのスクリプトツリー内の単一のリーフを知り、それを公開した者が、そのスクリプトを実行せずにアウトプットを使えるようにします。これにより、単一パスのP2MRアウトプットは意図的に安全でないものとなります。ユーザーが支払いを試みてリーフを公開すると、マイナーがその公開されたリーフを使って、そのアウトプットを代わりに自分宛に使ってしまえるからです。この変更は、ウォレットがウィットネスのバイト数を節約するためだけにポスト量子またはその他のフォールバックリーフを省略することを抑止することを意図しています。
● LDK #4713は、Rapid Gossip Sync (RGS)(ニュースレター #308 参照)に対するサービス拒否(DoS)耐性を強化します。 RGSはライトニングネットワークのゴシップデータを素早くインポートするためのLDKのフォーマットです。ドキュメントには、RGSソースは半トラストとみなすべきであるとの警告が加わりました。 RGSのデータソースはデータを省略することで経路探索を妨害したり、クライアントのネットワークグラフを肥大化させようとする可能性があるためです。 LDKは、ノードやチャネルの更新数が不自然なスナップショットは拒否するようになりました。また、グラフ内のチャネル数が予想される数の10倍を超えた場合、新しいチャネルアナウンスメントの追加をスキップします。
● LDK #4684は、再接続後に重複したrevoke_and_ackが送信される原因となり得る、非同期署名者(async signer)とチャネルモニターの処理順序に関する稀なバグを修正します。これまでは、モニターの更新が保留中であるにもかかわらず、署名者のブロックが解除されたパスが未送信のrevoke_and_ack を再生成して送信すると、その後、モニター復旧後のパスも同じメッセージを再生成してしまうことがありました。これにより、ピアが重複したシークレットを拒否して強制閉鎖に至る恐れがありました。今回の修正により、署名者保留パスがrevoke_and_ackを返した時点で、モニター保留のrevoke_and_ackフラグもクリアするようになりました。そのメッセージがモニター保留状態での再送要件も同時に満たすためです。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、 16:30 UTCに Riverside.fmで毎週配信されているBitcoin Optech Recapにご参加ください。この議論は録画もされ、ポッドキャストページからご覧いただけます。