今週のニュースレターでは、十分なProof-of-Workを持つ攻撃者がBitcoin Coreノードをクラッシュさせる可能性のある 脆弱性の責任ある開示と、UTXOセットをP2Pネットワーク経由で共有するためのドラフトBIP提案を掲載しています。 また、新しいリリース候補の発表や、人気のあるBitcoinインフラソフトウェアにおける注目すべき更新など 恒例のセクションも含まれています。

ニュース

• ● Bitcoin Coreスクリプトインタプリタのリモートクラッシュに関する開示: Niklas Göggeは、 Bitcoin Coreのバージョン0.14.0以降29.0未満に影響を及ぼす脆弱性CVE-2024-52911の開示を Bitcoin-Devメーリングリストに投稿しました。 バージョン0.14.0(2017年3月リリース)以降、特別に細工されたブロックを検証すると、 ノードが解放済みのメモリにアクセスする可能性がありました。検証中、 トランザクションのインプットをチェックするために必要なデータがキャッシュされます。このバグは、 並列スクリプト検証中のオブジェクトのライフタイムの順序に起因し、キャッシュされた事前計算済みのトランザクションデータが、 バックグラウンドのスクリプトチェックスレッドが完了する前に解放される可能性がありました。 特別に細工された無効ブロックに対して、このデータがバックグラウンドスレッドからまだアクセスされている間に破棄される可能性がありました。

  十分なProof-of-Workを持つ攻撃者は、特別に細工された無効なブロックを使用することで、被害者のノードをクラッシュさせる可能性があります。 use-after-freeバグの性質上、被害者のノード上でリモートコード実行を行うことも可能ですが、 それを実現するブロックを細工することは困難なため、実際にこの攻撃が実行される可能性は低いとされています。

  この脆弱性はCory Fieldsによって発見され、責任ある開示が行われ、 概念実証(PoC)と緩和策の提案も提供されました。この問題はBitcoin Core 29.0で修正されました。

• ● P2Pネットワーク経由でUTXOセットを共有するためのBIP提案: Fabian Jahrは、 UTXOセットをP2P レイヤー経由で共有するためのドラフトBIPについて Bitcoin-Devメーリングリストに投稿しました。この提案の目的は、 新しいノードが外部ソースからではなく、ピアから直接UTXOセットを受信する方法を提供することで、 assumeUTXO機能を改善することです。具体的には、 この提案はP2Pプロトコルへの拡張を定義し、新しいサービスビット、4つの新しいP2Pメッセージおよび 提供されたUTXOセットの正当性を検証するために要求側ノードが知っているUTXOセットのマークルルートを導入します。

  この提案にはフィードバックが寄せられました。Antoine Riardは、現在のドラフトを ピア機能ネゴシエーションを定義したBIP434(ニュースレター #386 参照)上に構築することを提案し、 悪意のあるピアが不正なUTXOセットを転送することについての懸念を示しました。 Eric Voskuilは、このようなBIPがUTXOの状態へのマイナーコミットメントの新たな提案につながる可能性があるという 長期的なリスクについて著者に警告しました。Voskuilによれば、これはBitcoinのセキュリティモデルを弱め、 新しいノードがチェーン全体をジェネシスブロックから検証するのではなく、マイナーを信頼することになるとのことです。

リリースとリリース候補

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

• ● Core Lightning 26.06rc1は、この人気のあるLNノードの次期メジャーバージョンのリリース候補です。 新しいgraceful、sendamount、xkeysendRPCが含まれ、payの非推奨化サイクルを開始してxpayを優先するほか、 BOLT12 payer-proof RPCのサポートを追加しています。

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

最近の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 #35209は、CVE-2024-52911の根本原因に対処するため、 CCheckQueueControlオブジェクトより前にtxsdataベクトルを構築するようになりました(上記のニュースセクション参照)。 C++ はローカルオブジェクトを構築順序の逆順で破棄するため、これによりキューに入れられた CScriptCheckオブジェクトから参照される事前計算済みトランザクションデータが破棄される前に、 スクリプトチェックキューが完了することが保証されます。これにより、 早期リターンの検証パスがバックグラウンドのスクリプトチェックスレッドに解放済みメモリへアクセスさせることを防ぎます。 この脆弱性は以前、早期リターン動作の秘密裏の修正を通じてBitcoin Core 29.0で修正されていました(ニュースレター #333 参照)。

• ● BIPs #2116はBIP323を公開しています。これはマイナー向けにnVersionのnonce空間で利用可能なビット数を 16から24に拡張することを提案するもので、BIP320を置き換えるものです。 1秒に1回より頻繁にnTimeをローリングすることなく、ヘッダーのみのマイニング用にビット5から28を予約します。 以前の議論についてはニュースレター #395を参照してください。

• ● BIPs #2141とBIPs #2155は、2018年に汎用署名メッセージ形式を提案した BIP322を改訂・拡張しています。今回の更新では長年の未解決の質問やフィードバックに対処し、 提案されたProof of Fundsの構造を詳細化し、PSBTベースの署名フローを追加しています。 今回の改訂は、署名に人間が読みやすい新しいプレフィックスを追加したり、Proof of Fundsの署名形式を変更するなど、 以前の仕様に対して破壊的な変更が行われています。BIPがCompleteに進められ、 エコシステムでの採用に向けて正式に提案されるにあたり、btcdベースのより包括的なリファレンス実装と追加のテストベクトルが追加されました。

• ● Core Lightning #9116は、BOLT12payer proofの実験的サポートを追加し、 BOLTs #1295の最新のドラフト提案を実装しています。payer proofは、 支払人がインボイスの支払いを証明できるBOLT12レシートフォーマットであり、 支払いのプリイメージ、請求ノードの署名およびinvreq_payer_idからの支払者の署名を使用し、 プライバシー保護のために特定のインボイスフィールドを省略できます。このPRでは、 payer proofの作成と検証のための共通ルーチンが追加され、bolt12-cliが更新され、 実験的なcreateproofRPCが追加されました。フォーマットは実験的なものであり、変更される可能性があります。

• ● Core Lightning #9110はpay、paystatus、keysend、getroute、renepayおよび renepaystatus の各RPCを非推奨にしました。非推奨化はバージョン26.06から始まり、 削除はバージョン27.03で予定されています。xpayRPC(ニュースレター #330 参照)が 現在ほとんどの支払いを処理しており、keysend機能を維持するために xkeysendRPCが追加されました。このPRはまた、xpayをlabelおよび localinvreqid パラメーター、 CLTVシャドウルーティング、繰り返し支払いの処理改善およびchannel_updateエラーの処理で拡張しています。 さらに、getroutesをホップごとの金額、ノード、CLTV フィールドをより明確に返すように更新し、 sendpayをそれらのフィールドを使ったルートを受け入れるように更新しています。

• ● LDK #4598は、OutputSweeper を更新し、進行中のスイープ試行が完了前にキャンセルされた場合でも pending_sweepフラグがクリアされるようにしました。このフラグは並行スイープ試行を防止しますが、 キャンセルされたスイープの後にもセットされたままだと、後続の試行が誤ってスキップされ、 時間に敏感なHTLCアウトプットがノードが再起動されるまで請求できない可能性がありました。 このPRでは、通常のリターン、エラー、またはキャンセル時に実行されるガードオブジェクトを使用してフラグをクリアするようになりました。

• ● LDK #4528は、BOLT11のpayment_metadata(ニュースレター #182 参照)を インバウンド支払いHMACにコミットしました。メタデータがインボイスに含まれている場合、 LDKは最終的なオニオンペイロードが同じメタデータを返すことを要求するようになり、 送信側での変更や省略を防ぎます。さらに、インボイスビルダーはデフォルトでpayment metadataを要求するようになりましたが、 ユーザーはそれをサポートしない送信者との互換性のためにoptional_payment_metadata()を使ってオプトアウトすることができます。

• ● LND #10612は、以前の転送サポート(ニュースレター #396参照)を基盤として、 オニオンメッセージのためのグラフベースの経路探索機能を追加しました。 LNDは機能ビット38/39でオニオンメッセージのサポートを通知するノードを経由して宛先までのルートを見つけられるようになりました。 オニオンメッセージは支払いではないため、検索では流動性や手数料を考慮しません。

• ● BTCPay Server #7354は、BTCPay Server #7329で粒度の細かいウォレット権限を追加した後に発生した、 ホットウォレットの秘密鍵漏洩の問題を修正しました。ウォレット署名権限は持っているものの、 ウォレットのシードを表示する権限やストア設定を変更する権限を持たないユーザーは、 PSBT署名中に、派生したホットウォレットの秘密鍵が漏洩する可能性がありました。 このPRは、ホットウォレットへのアクセスを一元化するためのHotwalletSafeヘルパーを導入し、 署名権限とシード情報を表示する権限を分離し、署名フローを更新してHTTPフォームフィールドを介して 秘密署名鍵を返すことなくサーバー側でホットウォレットを使用するようにしています。

• ● BDK #2195は、トランザクションの最初のアウトプットがインデックスされていない場合(例えばOP_RETURN アウトプットなど)のElectrumサーバーからの同期を修正します。これまでは、 BdkElectrumClient::populate_with_txidsが最初のアウトプットのスクリプトを使用して承認履歴をクエリしており、 空の履歴が返される可能性がありました。BDKは現在、最初にインデックスされたアウトプットスクリプトを使用するか、 いずれのアウトプットもインデックスされていない場合はインプットの以前のアウトプットスクリプトにフォールバックします。

• ● Bitcoin Inquisition #100は、signet上で提案されたコンセンサスの変更をテストするために、 BIP446のOP_TEMPLATEHASHopcodeを実装します。OP_TEMPLATEHASHは、 支払いトランザクションのハッシュをスタックにプッシュするTapscriptのopcodeです(ニュースレター #397参照)。このPRには包括的なテストフレームワークも追加されています。

• ● BINANAs #20は、BIP443のOP_CHECKCONTRACTVERIFY(OP_CCV)opcodeの 将来のBitcoin Inquisition実装にBIN-2026-0002を割り当てています。 この提案されたコベナンツに関する以前の議論については、 ニュースレター#348および#356をご覧ください。

もっと知りたいですか？

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