今週のニュースレターでは、Bitcoinプロトコルに形式検証を適用する新しいプロジェクトについて掲載しています。 また、新しいリリースとリリース候補の発表や、人気のBitcoin基盤ソフトウェアへの注目すべき変更点など恒例のセクションも含まれています。

ニュース

• ● Bitcoinプロトコルの形式検証: Keagan McClellandは、Bitcoinプロトコルの形式検証に取り組んでいることについて、 Bitcoin-DevメーリングリストとDelving Bitcoinに投稿しました。形式検証とは、数学の形式手法を用いて、 システムが仕様に対して正しいことを証明することを目指すソフトウェア開発の実践手法です。これは、 Bitcoinのコンセンサスルールへの変更提案に関する事実の論争を解決する助けとなる可能性があります。Optechは以前、 Bitcoinのコンセンサスルールの宣言的な実行可能仕様を開発する関連プロジェクトを取り上げました（ニュースレター #402参照）。

  McClellandは、検証プロセスのLean4による実装であるbtc-verifiedを開発しています。 著者は、このアプローチを実証する初期結果を提供しました。特に、Bitcoinがマークルルートの計算に用いるアルゴリズムに注目しました。 このアルゴリズムには、2つの異なるトランザクションリストが同一のマークルルートを生成しうるという 既知の欠陥（CVE-2012-2459）が含まれています。Bitcoin Coreのマークルルート構築には、 この変異を検出することを目的としたチェックが含まれています。McClellandはbtc-verifiedを用いて、このチェックが正しいこと、 そしてSHA256が衝突耐性を持つという仮定の下で、2つの異なるトランザクションリストがこのチェックを通過して 同一のマークルルートを生成することはできないことを、形式的に証明しました。

  最後に著者は、リポジトリと全体的なアプローチの両方について、他者からのフィードバックを求めました。 また、リポジトリでAIを多用していることや、プロジェクトが現状では未成熟であることなど、いくつかの但し書きも示しました。

リリースとリリース候補

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

• ● Bitcoin Core 30.3は、主要なフルノード実装のメンテナンスリリースです。 通常運用時に過剰なディスクの読み書きを引き起こす可能性があったchainstateデータベースの問題を修正したほか、 ウォレット、PSBT、miniscript、ネットワーク、ビルド、テスト、ドキュメントに関する修正が含まれています。 詳細はリリースノートをご覧ください。

• ● Bitcoin Core 29.4は、主要なフルノード実装のメンテナンスリリースです。30.3と同じchainstateデータベースの書き換えの問題を修正し、 選択された検証、ウォレット、ビルド、テスト、ドキュメント、CI、互換性に関する修正が含まれています。 詳細はリリースノートをご覧ください。

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

最近の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 #35295は、ブロックのトランザクションインプットによって使われるコインを並列に取得することで、 ブロック検証を高速化します。検証を開始する前に、Bitcoin Coreは複数のワーカースレッドを起動して異なる過去のアウトプットを並行して取得し、 その一方でメインスレッドは通常の順序でブロックを処理します。新しい-prevoutfetchthreadsオプションはデフォルトで8つのワーカーを使用し、 最大16まで許可され、0に設定することでこの最適化を無効化できます。この変更により、多数のディスク読み込みのレイテンシが逐次的に積み重なるのを防ぎます。 ハードウェアと設定次第で、著者のベンチマークでは初期ブロックダウンロード（IBD）が1.18倍から3倍以上の高速化を示しています。

• ● Bitcoin Core #34897は、インデックスの先端が最後にフラッシュされたchainstateブロックの祖先でない限りインデックスのコミットをスキップすることで、 オプションのインデックスがchainstateの最後の耐久的なUTXOフラッシュよりも先の状態を決して永続化しないようにします。これまでは、 正常でないシャットダウンによって、chainstateがindexよりも前のブロックにある状態でBitcoin Coreが再起動し、 2つのデータベース間で不整合が生じる可能性がありました。これは特にcoinstatsindexにとって問題でした。 そのローリングMuHashの状態は、対応するブロックを再処理しない限り元に戻すのが難しく、 しかもそのブロックはchainstate上では利用できなくなっているためです。インデックスはメモリ上でより新しいブロックを処理できますが、 現在ではその進捗をディスクに保存する前にchainstateが追いつくのを待つようになりました。

• ● Bitcoin Core #35406は、プライベートブロードキャストの追跡キューを 10,000トランザクションに制限します（ニュースレター #409参照）。この方法でブロードキャストされたトランザクションは、 ネットワークから戻ってくるのが観測されるまで追跡されます。以前は追跡キューのサイズが無制限だったため、 ポリシーの相違により決して戻ってこないトランザクションが無限に蓄積し、無制限のメモリとCPUを消費する可能性がありました。上限に達すると、 Bitcoin Coreは既存のエントリを削除することなく新しい提出を拒否します。ユーザーはgetprivatebroadcastinfoでキューを確認でき、 abortprivatebroadcastで行き詰まったトランザクションを削除できます。

• ● Bitcoin Core #35380は、各トランザクションインプットのwitness stackとscriptSigを公開するために、 btck_WitnessStackビューとその要素を数え・取得し・コピーする関数を追加し、libbitcoinkernel API(ニュースレター #380参照)を拡張します。これにより、 サイレントペイメントスキャナーを含む外部アプリケーションが、 rawトランザクションを別途デシリアライズすることなく、segwitのwitnessデータやP2PKHの scriptSigに格納された公開鍵を取得できるようになります。これらのインプットの公開鍵は、 サイレントペイメントスキャナーがトランザクションのアウトプットのいずれかがウォレットに属するかどうかを判断するために必要です。

• ● Bitcoin Core #35568は、内部のLevelDB Bloom Filterを無効化することで、 オプションのtxospenderindex（ニュースレター #394参照）の同期時間とディスク使用量を削減します。 これらはデータベース検索の最適化であり、SPVウォレットが歴史的に使用してきた BIP37のBloom Filterとは無関係です。 LevelDBのBloom Filterは一度も参照されておらず、処理とストレージのオーバーヘッドを増やすだけでした。 著者のベンチマークではインデックスの完全な同期が4時間37分から3時間57分に短縮され、ディスク使用量は85.0 GiBから80.9 GiBに減少しました。 既存のインデックスは互換性を保ちますが、以前に生成されたフィルターが使用していた領域を回収するにはインデックスの再構築が必要です。

• ● Bitcoin Core #34538は、externalip オプションで明示的に設定されたアドレスを、 たとえonlynetオプションがそのネットワークを除外していても、通知の対象として適格にします。 この変更は、あるネットワーク経由で自動的なアウトバウンド接続を開き、別のネットワーク経由でインバウンド接続を受け付けるノードにとって有益です。 例えば、IPv4のみでアウトバウンド接続を確立しつつ、別途設定されたTor オニオンサービスを運用しているノードを考えてみてください。これまでは、onlynetオプションがTorを到達不能とマークするため、 Bitcoin Coreは手動で指定されたオニオンアドレスを拒否していました。

• ● BIPs #2208は、BIP54のコンセンサスクリーンアップの根拠を更新します。 この提案は、witnessを除外して64 byteになるトランザクションを無効化し、 そのハッシュがマークルツリーの内部ノードのハッシュと混同されるのを防ぐことを提案しています。このPRは、 64 byteのトランザクションを有効なまま保ちつつ、2つの32 byteの子ハッシュを連結すると有効な64 byteのトランザクションを形成してしまう マークルツリーの内部ノードを拒否する、という代替提案を文書化しています（ニュースレター #412参照）。さらに、 このPRは、マークルプルーフの検証者は更新を決して必要としないというBIP54の従来の主張を訂正します。 通常の64 byte以外のトランザクションのプルーフは自動的に保護されますが、64 byteのトランザクションのプルーフを受け入れる検証者は、 アクティベーション後にそれらを拒否する必要があります。

• ● LND #10962は、RBFによる協調閉鎖フロー（ニュースレター #347参照）が、 Taproot Assetsチャネルのように、 ファンディングアウトプットが追加のプロトコル状態にコミットしている補助的なチャネルに対して使用されるのを防ぎます。 LNDはこれまで、ピアレベルの機能ビットを用いてRBFクローザーを選択していましたが、 そのクローザーは資産をクロージングトランザクションに引き継ぐために必要な補助フックを呼び出しません。 そのため、有効なBitcoinトランザクションをブロードキャストしてしまい、資産のコミットメントを破壊して チャネルを閉鎖待ちの状態のまま行き詰まらせる可能性がありました。

• ● LND #10897は、Taproot Assetsチャネルのような補助的なチャネルのインプットを 恒久的に取り残してしまう可能性があったsweeperのバグを修正します。これらのインプットは、その価値の大部分がオーバーレイ資産で表されるため、 小さなビットコインの手数料予算しか持っていないことがあり、その一方で補助的なsweeperが最終的なsweepトランザクションに追加の予算を提供します。 当初、LNDのフィルターは各インプット自身の予算のみを考慮していたため、失敗したsweepによって必要な開始手数料率が上昇すると、 そのインプットが以降のあらゆる試行から除外される可能性がありました。現在ではフィルターは、 インプットが最小リレー手数料と開始手数料率を賄えるかどうかを判断する際に、補助的な寄与分を含めるようになりました。

• ● BINANAs #21は、ドラフト段階のOP_PAIRCOMMIT提案である BIP442（ニュースレター #395参照）に BIN-2025-0003を割り当てます。

もっと知りたいですか？

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