今週のニュースレターでは、Bitcoin Coreフルノードの旧バージョンに影響する3つの脆弱性の発表と、 btcdフルノードの旧バージョンに影響する別の脆弱性の発表、 Bitcoin Core 28.0で追加された複数の新しいP2Pネットワーク機能の使用方法を説明する 寄稿されたOptechガイドへのリンクを掲載しています。また、Bitcoin Core PR Review Clubミーティングの概要や、 新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、 恒例のセクションも含まれています。

ニュース

  • ● Bitcoin Cor 25.0より前のバージョンに影響する脆弱性の開示: Niklas Göggeは、2024年4月以降のサポートが終了したBitcoin Coreのバージョンに影響する 3つの脆弱性の発表へのリンクをBitcoin-Devメーリングリストに投稿しました。

    • ● CVE-2024-35202リモートクラッシュの脆弱性: 攻撃者は、ブロックの再構築に失敗するように意図的に設計されたコンパクトブロック メッセージを送信できます。プロトコルを正常に使用しても再構築が失敗することはあります。 その場合、受信ノードは完全なブロックを要求します。

      しかし、攻撃者は完全なブロックを返信する代わりに、同じブロックヘッダーに対して 2つめのコンパクトブロックメッセージを送信することができます。 Bitcoin Core 25.0より前のバージョンでは、 同じコンパクトブロックセッションでコンパクトブロックの再構築コードが複数回実行されないように設計されていたため、 これによりノードがクラッシュしました。

      この簡単に悪用可能な脆弱性は、任意のBitcoin Coreノードをクラッシュさせるために使用される可能性があり、 ユーザーから資金を盗むための他の攻撃の一部として使用される可能性がありました。 たとえば、クラッシュしたBitcoin Coreノードは、チャネルの取引相手が資金を盗もうとしていることを 接続されたLNノードに警告することができません。

      この脆弱性は、Niklas Göggeによって発見され、責任を持って開示され、修正され、Bitcoin Core 25.0で修正がリリースされました。

    • ● 大規模なinventoryセットによるDoS: Bitcoin Coreノードは、ピア毎に、そのピアに送信するトランザクションのリストを保持します。 リスト内のトランザクションは、手数料率と相互の関係に基づいてソートされ、 最適なトランザクションが高速にリレーされ、リレーネットワークのトポロジーの調査が困難になるようにします。

      しかし、2023年5月にネットワーク活動が急増した際に、 複数のユーザーが自分のノードがCPUを過剰に使用していることに気付き始めました。 開発者の0xB10Cは、CPUがソート機能によって消費されていることを突き止めました。 開発者のAnthony Townsは、さらに調査を進め、 需要が高い期間に増加する可変レートでトランザクションがキューから出るようにすることで問題を修正しました。 この修正は、Bitcoin Core 25.0でリリースされました。

    • ● 低速ブロック伝播攻撃: Bitcoin Core 25.0より前のバージョンでは、 攻撃者からの無効なブロックにより、Bitcoin Coreが正直なピアからの同じヘッダーを持つ有効なブロックの処理を 継続できなくなる可能性がありました。これは、追加のトランザクションを要求する必要がある際の コンパクトブロックの再構築に影響しました。ノードは、別のピアから無効なブロックを受信すると、 トランザクションの待機を停止します。後で、トランザクションを受信しても、ノードはそれを無視します。

      Bitcoin Coreが無効なブロックを拒否した後（そしておそらくそれを送信したピアを切断した後）、 他のピアにブロックの要求を再開します。複数の攻撃ピアがこのサイクルを長時間続ける可能性があります。 攻撃者として設計されていない可能性のある欠陥のあるピアは、偶然同じ動作を引き起こす可能性があります。

      この問題は、William Casarinやghost43を含む複数の開発者が自分のノードに問題があることを報告したことで発覚しました。 他の何人かの開発者が調査し、Suhas Daftuarがこの脆弱性を分離しました。 Daftuarはまた、ブロックが検証をパスしディスクに保存された場合を除いて、 どのピアも他のピアのダウンロード状態に影響を与えないようにすることでこれを修正しました。 この修正は、Bitcoin Core 25.0に含まれています。

  • ● CVE-2024-38365 btcdのコンセンサス障害: 先週のニュースレターで発表したように、Antoine PoinsotとNiklas Göggeは、 btcdフルノードに影響するコンセンサス障害の脆弱性を公開しました。 レガシーなBitcoinトランザクションでは、署名は署名スクリプトフィールドに保存されます。 ただし、署名は署名スクリプトフィールドにもコミットします。 署名は署名自体にコミットすることはできないため、署名者は署名スクリプトフィールドの署名以外のすべてのデータにコミットします。 検証者は、署名コミットメントの正確性をチェックする前に、署名を削除しなければなりません。

    Bitcoin Coreの署名を削除する関数FindAndDeleteは、署名スクリプトから完全に一致する署名のみを削除します。 btcdで実装された関数removeOpcodeByDataは、署名を含む署名スクリプト内のあらゆるデータを削除しました。 これを使用すると、Bitcoin Coreがコミットメントを検証する前に削除するよりも多くのデータを btcdが署名スクリプトから削除することができ、一方のプログラムはコミットメントを有効とみなし、 もう一方のプログラムは無効とみなすことになります。 無効なコミットメントを含むトランザクションはすべて無効であり、 無効なトランザクションを含むブロックはすべて無効であるため、 Bitcoin Coreとbtcd間でコンセンサスが破られる可能性があります。 コンセンサスから外れたノードは、無効なトランザクションを受け入れるように騙され、 ネットワークの残りの部分が承認済みとみなす最新のトランザクションを確認できない可能性があります。 いずれの場合も、多額の金銭的な損失につながる可能性があります。

    PoinsotとGöggeの責任のある開示により、btcdのメンテナーはこの脆弱性を密かに修正し、 約3ヶ月前に修正を加えたバージョン0.24.2をリリースすることができました。

  • ● Bitcoin Core 28.0を採用するウォレット向けのガイド: 先週のニュースレターで言及したように、 新しくリリースされたBitcoin Coreのバージョン28.0には、 1P1C（One Parent One Child）パッケージリレー、 TRUC（Topologically Restricted Until Confirmation）トランザクションリレー、 パッケージRBF、兄弟の排除、 標準P2A（Pay-to-Anchor）アウトプットスクリプトタイプなど P2Pネットワークのためのいくつかの新機能が含まれています。 これらの新機能により、いくつかの一般的なユースケースのセキュリティと信頼性が大幅に向上します。

    Gregory Sandersは、Bitcoin Coreを使用してトランザクションを作成、ブロードキャストするウォレットや その他のソフトウェアの開発者を対象に、Optech向けのガイドを作成しました。 このガイドでは、いくつかの機能の使用方法を説明し、シンプルな支払いや、RBFによる手数料の引き上げ、 LNのコミットメントとHTLC、ArkおよびLNのスプライシングなど 複数のプロトコルでこれらの機能がどのように役立つかを説明しています。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Add getorphantxsは、tdb3によるPRで、 getorphantxsという新しい実験的なRPCメソッドを追加します。 このメソッドは主に開発者向けであるため、非表示になっています。 この新しいメソッドは、呼び出し元に現在のすべてのオーファントランザクションのリストを提供します。 これはオーファンの動作/シナリオを確認する場合（例：p2p_orphan_handling.pyのような機能テスト）や、 統計/視覚化用の追加データを提供する場合に役立ちます。

  • オーファントランザクションとは何ですか？どの時点でorphanageに入るのですか？

    オーファントランザクションは、インプットが不明または見つからない親トランザクションを参照するトランザクションのことです。 ピアからトランザクションを受け取り、ProcessMessageでTX_MISSING_INPUTSにより検証が失敗すると、 トランザクションはorphanageに入ります。 ➚

  • どのコマンドを使用すれば有効なRPCのリストを取得できますか？

    bitcoin-cli helpが利用可能なRPCのリストを提供します。注意: getorphantxsは開発者専用のRPCとして非表示とマークされているため、 このリストには表示されません。 ➚

  • RPCに文字列以外の引数がある場合、その引数を処理するために何か特別な操作が必要ですか？

    RPCに文字列以外の引数がある場合、適切な型変換を確実に行うためにsrc/rpc/client.cppの vRPCConvertParamsリストに追加する必要があります。 ➚

  • このRPCの結果の最大サイズはどれくらいですか？保持されるオーファントランザクションの数に制限はありますか？ オーファンがorphanageに留まる期間に制限はありますか？

    オーファンの最大数は100（DEFAULT_MAX_ORPHAN_TRANSACTIONS）です。 verbosity=0の場合、各txidは、32 byteのバイナリ値ですが、JSON-RPCの結果用に 16進数にエンコードされると64文字の文字列になります（各byteは2つの16進文字で表現されるため）。 つまり、結果の最大サイズは、6.4 kB（100 txid * 64 byte）です。

    verbosity=2の場合、16進数にエンコードされたトランザクションが、結果の中で圧倒的に大きなフィールドであるため、 ここでは計算を簡単にするため、他のフィールドは無視します。トランザクションの最大シリアライズサイズは、 最大400 kB（witnessデータのみで構成される極端で不可能なケース）、 または16進数でエンコードされた場合には800 kBです。したがって、結果の最大サイズは、 約80 MB（100トランザクション * 800 kB）です。

    オーファンには時間制限があり、ORPHAN_TX_EXPIRE_TIMEで定義されているように20分後に削除されます。 ➚

  • いつからorphanageの最大サイズが設定されたのですか？

    MAX_ORPHAN_TRANSACTIONS変数は、2012年にコミット142e604で既に導入されています。 ➚

  • getorphantxs RPCを使用すると、トランザクションがorphanageにどのくらいの期間保存されるかを知ることができますか？ できる場合、どのように行えますか？

    はい。verbosity=1を使用すると、各オーファーントランザクションの有効期限のタイムスタンプを取得できます。 ORPHAN_TX_EXPIRE_TIME（つまり20分）を減算すると、挿入時間が得られます。 ➚

  • getorphantxs RPCを使用すると、オーファントランザクションのインプットが何か知ることができますか？ できる場合、どのように行えますか？

    はい。verbosity=2を使用すると、RPCは16進数エンコードされたトランザクションを返します。 これを decoderawtransactionを使用してデコードすると、インプットが明らかになります。 ➚

リリースとリリース候補

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

  • ● Bitcoin Inquisition 28.0は、提案中のソフトフォークや他の主要なプロトコルの変更を実験するために設計された このsignetフルノードの最新リリースです。更新バージョンは、 最近リリースされたBitcoin Core 28.0に基づいています。

  • ● BDK 1.0.0-beta.5は、ウォレットやその他のBitcoin対応アプリケーションを構築するための このライブラリのリリース候補（RC）です。この最新のRCは、「RBFをデフォルトで有効にし、 レート制限により失敗したサーバー要求を再試行するようにbdk_esploraクライアントを更新します。 bdk_electrumクレートでは、use-openssl機能も提供されるようになりました。」

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

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

  • ● Core Lightning #7494では、channel_hintsに2時間の有効期限が導入され、 不要な試行をスキップするために、支払いから学習した経路探索情報を将来の試行で再利用できるようになりました。 利用不可能と判断されたチャネルは徐々に復元され、2時間後に完全に利用可能になります。 これは、古くなった情報が原因で、その後復元した可能性のある経路がスキップされないようにするためです。

  • ● Core Lightning #7539では、emergency.recoverファイルからデータを取得して返すための getemergencyrecoverdata RPCコマンドが追加されました。これにより、 APIを使用する開発者は、アプリケーションにウォレットバックアップ機能を追加できるようになります。

  • ● LDK #3179では、BLIP32を実装するためのコア機能として、 新しいDNSSECQueryおよびDNSSECProofOnionメッセージと、 これらのメッセージを処理するためのDNSResolverMessageHandlerを導入しました。 このPRはまた、DNSSECプルーフを検証してオファーに変換するOMNameResolverも追加しています。 ニュースレター#306をご覧ください。

  • ● LND #8960は、新しい実験的なチャネルタイプとしてTaprootオーバーレイを追加することで、 カスタムチャネル機能を実装しました。これはSimple Taproot Channelと同じですが、 チャネルスクリプトのTapscriptのリーフに追加のメタデータをコミットします。 メインのチャネルステートマシンとデータベースは、カスタムTapscriptリーフを処理および保存するように更新されます。 Taprootオーバーレイチャネルのサポートを有効にするためには、 TaprootOverlayChans設定オプションを設定する必要があります。 カスタムチャネル構想は、LNDのTaproot Assetsサポートを強化します。 ニュースレター#322をご覧ください。

  • ● Libsecp256k1 #1479は、BIP327で定義されたBIP340互換のマルチシグスキーム用の MuSig2モジュールを追加しました。このモジュールは、 secp256k1-zkpで実装されたものとほぼ同じですが、 実験的なものでないようにするためにアダプター署名のサポートを削除するなど、 若干の変更が加えられています。

  • ● Rust Bitcoin #2945は、TestNetVersion列挙型を追加し、コードをリファクタリングし、 testnet4に必要なパラメーターとブロックチェーンの定数を含めることで、 testnet4のサポートを導入しました。

  • ● BIPs #1674は、ニュースレター #323に掲載された BIP85の仕様変更を元に戻しました。この変更は、展開されたプロトコルのバージョンとの互換性を壊しました。 PRでの議論では、主要な変更のために新しいBIPの作成が支持されました。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、 （ニュースレターが公開された翌日の）木曜日の14:30 UTCからTwitter Spacesで毎週開催されているBitcoin Optech Recapにご参加ください。 この議論は録画もされ、ポッドキャストページからご覧いただけます。