今週のニュースレターでは、最近発見された理論上のコンセンサス障害の脆弱性と、 BIP32ウォレットパスの再利用を回避するための提案のリンクを掲載しています。 また、Bitcoin Core PR Review Clubミーティングの概要や、新しいリリースおよびリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点など恒例のセクションも含まれています。

ニュース

  • ● BIP30コンセンサス障害の脆弱性: Ruben Somsenは、 Bitcoin Coreからチェックポイントが削除された（ニュースレター #346参照）ことで 発生する可能性がある理論上のコンセンサス障害についてBitcoin-Devメーリングリストに投稿しました。 簡単に言うと、ブロック91722と91812のコインベーストランザクションが、 ブロック91880と91842で重複している点です。BIP30では、これらの2つのブロックは、 2010年のBitcoin Coreの旧バージョンで処理された方法、 つまりUTXOセット内で前のコインベースエントリーを重複する後続のエントリーで上書きする方法で処理するよう規定しています。 しかし、Somsenは、後続ブロックのいずれか、または両方が再編成されると、 重複エントリーがUTXOセットから削除され、上書きにより以前のエントリーも失われてしまうと指摘しています。 しかし、重複トランザクションを一度も確認したことのない新規ノードは、 以前のトランザクションを保持した状態で異なるUTXOセットを作成し、 いずれかのトランザクションが使用された場合にコンセンサス障害につながる可能性があります。

    Bitcoin Coreにチェックポイントがあった頃は、上記の4つのブロックがすべてベストブロックチェーンの一部である必要があったため、 これは問題になりませんでした。現在は、BitcoinのProof of Workのセキュリティメカニズムが理論上破綻しない限り、 実際には問題にはなりません。これらの2つの例外に対して、追加の特殊ケースロジックをハードコードするなど、 いくつかの解決策が議論されています。

  • ● BIP32パスの再利用の回避: Kevin Loaecは、 同じBIP32ウォレットパスが異なるウォレットで使われるのを防ぐ方法について Delving Bitcoinに投稿しました。 これは、アウトプットのリンクによるプライバシーの損失や、 （量子コンピューターなどによる）理論的なセキュリティの損失につながる可能性があります。 彼は、ランダムパスの使用、ウォレットの誕生日に基づくパスの使用、 インクリメントカウンターに基づくパスの使用という3つのアプローチを提案し、 誕生日ベースのアプローチを推奨しました。

    また、ディスクリプターウォレット、特にマルチシグや複雑なスクリプトの普及に伴い、 BIP48のパス要素のほとんどを不要として削除することを推奨しました。 しかし、Salvatore Ingalaは、一部のハードウェア署名デバイスによって強制されているように、 異なる暗号通貨で使用される鍵が分離された状態を保つのに役立つため、 BIP48のパスの coin type 部分は維持するよう提案しました。

Bitcoin Core PR Review Club

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

Add bitcoin wrapper executableは、 ryanofskyによるPRで、さまざまなBitcoin Coreバイナリを検出して起動するのに 使える新しいbitcoinバイナリを導入します。

Bitcoin Core v29は7つのバイナリ（bitcoind、bitcoin-qt、bitcoin-cliなど）と一緒にリリースされましたが、 将来マルチプロセスバイナリもリリースされると、 その数は増えていきます。新しいbitcoinラッパーは、 コマンド（guiなど）を正しいモノリシック（bitcoin-qt）またはマルチプロセス（bitcoin-gui）バイナリにマッピングします。 検出機能に加えて、ラッパーはユーザーインターフェースを変更することなくバイナリを再編成できるように前方互換性も提供します。

このPRにより、ユーザーはbitcoin daemonまたはbitcoin guiでBitcoin Coreを起動できます。 bitcoindやbitcoin-qtで直接起動することも引き続き可能で、このPRによる影響はありません。

  • Issue #30983では、4つのパッケージ戦略がリストアップされています。 このPRは「サイドバイナリ」アプローチの具体的な欠点のうち、どのような点に対処しているのでしょうか？

    このPRで想定されているサイドバイナリアプローチでは、 新しいマルチプロセスバイナリを既存のモノリシックバイナリと並行してリリースします。 多数のバイナリがあると、ユーザーは自分の目的のバイナリを見つけて理解するのが難しくなります。 このPRは、オプションの概要とヘルプ文言を含む単一のエントリーポイントを提供することで、 こうした混乱を大幅に軽減します。あるレビュアーは、これをさらに簡単にするためにあいまい検索の追加を提案しました。 ➚

  • ExecCommandにおけるfallback_os_searchブール値の目的を説明してください。 OSがPATH上のバイナリを検索させないほうが良い状況はどのような場合ですか？

    ラッパー実行ファイルが検索（例：”bitcoin”）ではなくパス（例：”/build/bin/bitcoin”）で呼び出されるように見える場合、 ユーザーがローカルビルドを使用していると想定され、fallback_os_searchにはfalseがセットされます。 たとえば、ユーザーがguiをローカルでビルドしていない場合、 /build/bin/bitcoin guiはシステムインストールされたbitcoin-guiにフォールバックするべきではありません。 作者は、PATH検索を完全に削除することを検討しており、ユーザーからのフィードバックが役立つでしょう。 ➚

  • ラッパーは、インストールされたbin/ディレクトリから実行されていることを検知した場合のみ、 ${prefix}/libexecを検索します。なぜ、常にlibexecを検索しないのでしょうか？

    ラッパーは、実行しようとするパスについて保守的であるべきで、 標準のPREFIX/{bin,libexec}レイアウトを推奨すべきです。 パッケージの作成者が非標準のレイアウトを作成したり、 予期しない方法で配置されたバイナリで動作したりすることを推奨すべきではありません。 ➚

  • PRでは、ラッパーにFORTIFYが有効になったglibc呼び出しが含まれていないため、 security-check.pyに例外を追加しています。なぜそれらが含まれていないのでしょうか。 また、bitcoin.cppに単純なprintfを追加すると、現在のルールでは再現可能なビルドが機能しなくなるのでしょうか？

    ラッパーバイナリは非常に単純なため、FORTIFYが有効になった呼び出しは含まれていません。 将来的にそのような呼び出しが含まれるようになった場合は、security-check.pyの例外を削除できます。 ➚

リリースとリリース候補

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

  • ● LND 0.19.0-beta.rc4は、この人気のLNノードのリリース候補です。 おそらくテストが必要な主な改善の1つは、協調クローズにおける新しいRBFベースの手数料引き上げです。

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

最近の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 #8227は、BLIP50で定義されているように（ニュースレター #335参照）、 BOLT8ピアツーピアメッセージ上でJSON-RPC形式を用いて、 LSPノードとそのクライアント間の通信プロトコルを実装するRustベースの lsps-clientおよびlsps-serviceプラグインを追加します。これは、 BLIP51で定義されている流動性リクエストの受信と BLIP52で定義されているJITチャネルの実装の基盤となります。

  • ● Core Lightning #8162は、ピアによって開始された保留中のチャネル開設の処理を更新し、 最新100件まで無期限に保持するようにしました。これまでは、未承認のチャネル開設は2016ブロック後に消去されていました。 さらに、ノードがピアのchannel_reestablishメッセージに応答できるように、 閉じられたチャネルはメモリに保持されるようになりました。

  • ● Core Lightning #8166は、wait RPCコマンドを強化し、 単一のdetailsオブジェクトをサブシステム別のオブジェクト invoices、forwards、sendpaysおよびhtlcsに置き換えました。 さらに、listhtlcs RPCは現在、新しいcreated_indexとupdated_indexフィールドおよび、 index、start、endパラメーターによるページネーションをサポートします。

  • ● Core Lightning #8237は、listpeerchannels RPCコマンドに short_channel_idパラメーターを追加し、提供された場合に指定されたチャネルのみを返します。

  • ● LDK #3700は、HTLCが失敗した理由と、 原因がローカルか下流かについての追加情報を提供するためにHTLCHandlingFailedイベントに 新しいfailure_reasonフィールドを追加します。failed_next_destinationフィールドは、 failure_typeに名前が変更され、UnknownNextHopバリアントは非推奨となり、 より汎用的なInvalidForwardに置き換えられました。

  • ● Rust Bitcoin #4387は、BIP32のエラー処理をリファクタリングし、 単一のbip32::Errorを、導出、子番号/パスのパース、拡張鍵のパース毎に別々の列挙型に置き換えました。 このPRでは、256階層を超えるパスに対して、新しくDerivationError::MaximumDepthExceededバリアントも導入されています。 これらのAPIの変更により後方互換性が損なわれます。

  • ● BIPs #1835は、BIP48（ニュースレター #135参照）を更新し、 m/48’プレフィックスを持つ決定論的マルチシグウォレットにおいて、 既存のP2SH-P2WSH (1′)およびP2WSH (2′)スクリプトタイプに加えて、 Taproot (P2TR)導出用のスクリプトタイプ値3を予約しました。

  • ● BIPs #1800は、Bitcoinプロトコルに長年存在していた複数の脆弱性を修正するための コンセンサスクリーンアップソフトフォーク提案を定義した BIP54をマージしました。このBIPの詳細については、ニュースレター#348をご覧ください。

  • ● BOLTs #1245は、インボイスにおける非最小長エンコーディングを禁止することで BOLT11を厳格化します。有効期限（x）、最終ホップのCLTV有効期限delta（c）および機能ビット（9）の各フィールドは、 先頭にゼロを付けずに最小の長さでシリアライズする必要があり、 読み取り側は先頭にゼロを含むインボイスを拒否する必要があります。 この変更は、LDKが最小長以外のインボイスを最小長に再シリアライズ（余分なゼロを削除）すると、 インボイスのECDSA署名が署名の検証に失敗するというファジングテストの結果に基づいています。