Bitcoin Core v32.0rc1、ウォレット周辺のプロトコル変更でアプリに一時的な影響の恐れ

Bitcoin Core v32.0rc1の公開により、9月14日から10月10日にかけての期間は、ノード運用者、ウォレット事業者、そしてBitcoin CoreのRPCインターフェースに依存する各種サービスにとって集中的な互換性検証の局面となった。rc1は9月14日に検証済み署名付きでタグ付けされた。公式のリリース予定では最終版v32.0のタグ付け目標日が10月10日とされ、経過は26日間となる。 CryptoSlateが8月に報じたプレビューではRC1の目標が9月10日だった一方、現行スケジュールは9月14日を示しており、4日分の差がある。ただし、期限が変更されないまま遅延したと断定できる情報は示されていない。なお、v32.0rc1はあくまでプレリリースであり、本番環境向けの確定アップグレードを意味しない。コンセンサスルールの新たな有効化を示すものでもない。草案BIP 323に関連する変更として、シグナリングビットや未知のデプロイメントに関する警告の扱いが調整されるが、提案自体はDraftのままだ。 運用者は、Bitcoin Coreの最新RCテストガイドが示す基本手順に沿い、普段使う機能を一時的なデータディレクトリで個別に検証し、候補版を直前リリースと比較するのが現実的だ。公式ダウンロードページでは31.1が現行の基準版として案内されている。候補版を通常の本番更新として扱わず、ノード起動、ウォレット挙動、RPC応答の差分を確認できる。 性能面で目立つ変更として、ブロック接続時のトランザクション出力のプリフェッチが並列化される。デフォルトは8ワーカーで、最大16まで対応し、無効化も可能。ディスクI/Oに制約のある検証では複数設定で回し、ブロック処理の高速化がCPU、メモリ、ストレージ遅延の面で許容できないコストを招かないか、自身のハードウェアで見極める必要がある。 一方、ウォレットやサービスの連携には別の破壊的変更リスクがある。4つのRPCがPSBTv2をデフォルトとし、別のインターフェースでは非推奨フィールドの削除や、旧版が許容していた引数の拒否が行われる。PSBTの作成、変換、手数料引き上げ（feebump）を扱うチームは、下流のパーサーや署名系コンポーネントまで含めて当該トランザクションの通過経路を追跡し、影響を確認しておきたい。 手数料推定の失敗経路も検証対象となる。デフォルトのestimatesmartfeeはblockpolicy推定とmempool推定を組み合わせる設計となり、推定値がより低く出る可能性があるほか、いずれかのコンポーネントが失敗するとエラーになり得る。起動直後やmempoolが希薄・不健全な状況を観察し、監視系や明示的なblockpolicyフォールバックが想定どおり動くか確認が求められる。 HTTPサーバーの書き直しにより、テスト範囲はノード本体を超えて広がる。ヘッダー上限8,192バイトの導入、不正形式ヘッダーへの取り扱い厳格化、RPC接続数のデフォルト上限16、RESTのキャッシュ制御追加、未認可クライアントアドレスの即時切断などが含まれる。リバースプロキシ、ヘルスチェック、クライアントプール、エラーハンドラといった周辺部で差分が顕在化する可能性がある。 ロールバックも同等に注意が必要だ。再構築されたトランザクションインデックスはディスク使用量が半分未満になる一方、旧リリースは新形式を読み取れないため、ダウングレードすると数時間に及ぶ再構築が走る恐れがある。プライバシー重視の運用者は、Torフォールバック修正に関連するprivatebroadcastの失敗経路、10,000件キュー、1,000回試行上限、負荷時のリレー挙動も再現して確認したい。 最終タグはあくまで目標に過ぎず、RC期間中にこうしたエッジケースを潰すことが実務上の焦点となる。