Bitcoin Coreは、CVE-2025-62861の公式開示を公開しました。これはノードソフトウェアのトランザクション中継ロジックにおける高深刻度の欠陥で、目に見える警告なしにマイニング運用が古いブロックテンプレートでハッシュ計算を続けさせる可能性があるものでした。この勧告は、問題を報告したセキュリティ研究者Niklas Goeggeをクレジットし、その原因を、黙っているべきタイミングであるチェーン再編成の際に作動した中継ルールに特定しています。

影響を受けるバージョンはBitcoin Core 28.0から28.2、および29.0から29.1です。修正は2025年10月に出荷されましたが、完全な技術詳細はプロジェクトの協調開示ポリシーに基づき2026年11月まで非公開とされました。勧告には障害や影響を受けた運営者は記載されておらず、エクスポージャーは過去のものです。この破損状態のノードに接続されていたマイニングハードウェアは、受け取った最後のテンプレートでハッシュ計算を続けていたため、誰かが気づくまで新しいトランザクションとその手数料は請求されないままでした。

再編成がどのようにトランザクションを孤立させ得るか

再編成は、ノードが現在のチェーンチップを、より重い競合ブランチに引き渡す際に発生します。切断されたブロック内のトランザクションは依然として有効であるため、Bitcoin Coreはそれらを未確認トランザクションの一時保管領域であるmempoolに戻します。これらのトランザクションは有効なブロックですでに承認されていたため、ノードはbypass_limitsというフラグを付けて再追加し、通常のアンチスパムおよびトポロジーチェックを無効にします。目的はプールを忠実に復元することであり、すでにコンセンサスを通過したトランザクションを再評価することではありません。

無効化されるべきチェックの一つに、バージョン3(TRUC)トランザクションに関するものがあります。BIP 431では、TRUCトランザクションは未確認の親を最大1つ、未確認の子を最大1つ持つことができます。これは中継ポリシーでありコンセンサスルールではありません。つまり、どのノードもその形状をネットワークからmempoolに受け入れませんが、ブロックは複数の子を持つTRUC親を正当に含むことができます。ポリシーとコンセンサスのこの境界こそが、不具合そのものの限界でもありました。CVE-2025-62861はノードのmempoolを破損させテンプレート出力を停止させ得ましたが、無効なブロックを作成したりチェーンのルールを変更することはできませんでした。

バージョン28.0以降、Bitcoin Coreは「兄弟追い出し」と呼ばれるメカニズムで1子制限を強制してきました。新しいトランザクションがTRUC親に2つ目の未確認の子を与える場合、ノードは既存の子を置換候補とみなし、新規トランザクションが十分な手数料を支払っていれば、replace-by-feeルールに基づいて追い出します。

不具合は、bypass_limitsが設定されていても兄弟追い出しが実行されていた点にありました。複数の子を持つTRUC親を復元する再編成(切断されたブロック内では完全に有効な形状)は、復元されたトランザクションの一つを追い出し、その出力を使用するトランザクションをプールに残したままにする可能性がありました。mempoolは、親がどこにも存在しない子を保持することになりました。チェーンにも、プールにも存在しないのです。

Greg Sandersの修正は、bypass_limitsに基づいてTRUCチェックをゲートし、再編成の復元中に追い出しが実行されないようにしました。関連するプルリクエストPR #33504は、元のコードに欠けていたテストシナリオ(ピアからではなく切断されたブロックから到着するトランザクション)も追加しました。

マイニング側から見た停止したテンプレートの姿

ノードは、getblocktemplateを通じてマイニングソフトウェアに作業を渡します。これは候補ブロックを組み立て、ノード自身の有効性チェックに通し、前のブロックハッシュ、選択されたトランザクション、次の高さを返します。親のないトランザクションがプールにあると、組み立てられた候補はこのチェックに失敗し、呼び出しは新しい作業を返すことができませんでした。

外部から見ると、ノードは正常に見えました:

• プロセス実行中
• ピア接続が開いている
• チェーンチップが進行中
• mempoolが新しいトランザクションを受け付けている

実際に壊れていた点:

• テンプレートリクエストがエラーを返す
• ハッシャーが古い作業で計算を続ける
• 現在のチップではブロックが見つからない
• ノードが再起動されるまで状態が続く

汎用の監視ダッシュボードが監視するものはすべて緑のままでした。ネットワーク側からの信号もありませんでした。チェーンチップは進行し続け、ブロックは見つかり続けていましたが、この運用によってではありません。そのためコストは停止したマイナーだけに集中し、現在のチップではブロックを生み出せないハッシュ計算と、本来請求できたはずの手数料として現れました。マイナーがノードに求める唯一のもの、現在のテンプレートこそが、生産されなくなった唯一のものだったのです。

再起動、パッチ、サポート終了

ノードを再起動すると、mempoolが一貫した状態でディスクから再読み込みされ、症状は解消されます。しかし原因には何の対処もありません。同じトランザクション形状を伴う次の再編成で、ノードは再び停止し得ます。

根本的な欠陥は3つのリリースで除去されました。バージョン30.0が2025年10月10日に修正付きで出荷され、バックポートの29.2と28.3が続きました。非公開の報告から最後のリリースまで3週間を要しました:

両方のバックポートブランチはその後サポートを終了しました。Bitcoin Coreのメンテナンスポリシーは直近3つのメジャーバージョン、現在は30.x、31.x、32.xを対象とし、29.xは2026年10月27日にサポート終了を迎えました。当初の障害に再起動だけで対応した運営者は、現在サポート対象外のコードを実行しており、どのトランザクション形状がトリガーになるかの公開された説明とともにあります。

勧告が396日待った理由

最初の修正リリースから詳細な勧告まで396日を要し、開示は29.xがサポート終了となったちょうど2週間後に届きました。どちらの数字も偶然ではありません。Bitcoin Coreの開示ポリシーは、中・高深刻度の詳細を、最後の影響リリースがサポート対象外となってから2週間後まで保持し、その2週間前に予告を行い、新しいメジャーリリースのタイミングに合わせます。

エンバーゴの対象はコードではなく説明でした。プルリクエストは2025年9月29日以来公開されており、28.3と29.2のリリースノートには当時mempool修正が記載されていました。1年間非公開だったのは、パッチを再現可能なマイニング停止と結びつける解説文でした。

このポリシーにはより速い経路も用意されています。「容易に発見可能」に分類される不具合、プロジェクトの定義では最小限の労力で発見できるもの、はエンバーゴなしの即時のポイントリリースと勧告を受けます。今回は標準のスケジュールを経たため、メンテナーは発見が容易とは考えていなかったことになります。これは同日、ブロック処理の停止とTorの権限エラーを扱う他の2つの中・高深刻度の勧告とともに公開され、3つすべてが同じ2025年10月のリリースサイクルで修正されました。したがって、mempoolパッチを含む十分に新しいビルドは、他の2つの修正も含んでいます。

より遅い経路には独自の前提が組み込まれています。運営者が1年の期間内にアップグレードする、つまりトリガーが公に説明される頃には、脆弱なままのリスナーは誰もいなくなっている、というものです。

稼働時間の代わりに監視すべきもの

マイニング運用にとって有用なチェックは、ノードが生きているかではなく、最後の成功したテンプレートがどれほど古いかです。実行中、接続済み、同期済みのプロセスでも作業の提供を停止していることがあり、この不具合はそれが静かに起こる一つの方法でした。ビルドバージョンも同じチェックに含めるべきです。今日テンプレートが最新のノードでも、明日にはサポート対象外のノードになり得るからです。

バックアップのテンプレートソースにも同じ問いが必要です。同じリリースと同じmempoolポリシーを使用するフェイルオーバーノードは、同じ再編成と同じ停止に見舞われていたでしょう。2つの実行プロセスは2つの独立した作業源ではありません。異なるパッチ適用済みビルド上のノードだけが運用のマイニングを維持し、シミュレートされた再編成の下でそれをテストした運営者だけが事前にそれを知っていたでしょう。