今週のニュースレターでは、Bitcoinのコンセンサスルールの変更に関する議論のまとめや、 新しいリリースおよびリリース候補の発表、人気のBitcoinイ基盤ソフトウェアの注目すべき更新など、 恒例のセクションを掲載しています。

ニュース

今週は、どの情報源からも重要なニュースは見つかりませんでした。

コンセンサスの変更

Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション

  • ● SLH-DSAのSTARK集約のベンチマーク: Remix7531は、多数のSPHINCS署名検証を 単一のSTARK証明に集約したベンチマーク結果をBitcoin-Devメーリングリストに投稿しました。 これは、STARKを使ってポスト量子ブロックをスケーリングするという Ethan Heilmanの以前の提案に続くものです。このベンチマークスイート(RISC ZeroのzkVM上に構築)では、 証明時間は署名数にほぼ線形にスケールし(RTX 5090上で1署名あたり約3.1秒)、 証明サイズは署名数に対して劣線形に増加し(署名1件で218KiB、署名512件で454KiB、素の署名なら3.8 MiB)、 検証時間はバッチサイズにかかわらず12〜15ミリ秒程度に留まります。 ブロック全体を1台のGPUで証明するには依然として数時間かかりますが、 Remixは専用のAIR回路(汎用zkVMではなく署名検証に特化した多項式制約)、mempoolでの前処理、 マルチGPUでの証明によりこれを改善できる可能性があると示唆しています。 また、このベンチマークは、よりコンパクトなBitcoin向けに最適化されたSPHINCS+バリアントではなく、 標準のSPHINCSを使用しています。

  • ● Bird of Prey 2(BoP-2): 非マリアブルなSchnorr + PQ署名: Pieter Wuilleは、Schnorr系の署名方式と任意の ポスト量子署名方式からハイブリッドな強偽造不可能な署名方式を構築することに関する EuroCrypt 2026の論文について、Delving Bitcoinに投稿しました。 両方式の署名を単純に連結するだけでも、少なくとも一方が安全であれば偽造不可能ではありますが、強偽造不可能ではありません。 どちらかの方式が破られると、攻撃者は署名全体としては有効なまま、破られた方式の部分署名を差し替えることができます。 論文のBoP-2構成は、Schnorr署名のチャレンジハッシュにポスト量子署名へのコミットメントを含めることで、これを回避します。

    Adam GibsonとConduitionは、Segwit以降はwitnessがtxidに影響しなくなったため、 強偽造不可能性が依然として重要なのかどうかを議論しました。 Wuilleは、量子的あるいは古典的な暗号の破壊によって、 誰でも破られた方式の署名要素をマリアブル化(改変)できるようになることが懸念点だと説明しました。 Conduitionは、この構成をBoris Nagaevの省スペースなハイブリッドハッシュベースの設計(下記の格子ベース署名の項を参照)と比較し、 BoP-2の方がより強力な統合ハイブリッド方式の有力候補に見えると結論づけましたが、 WuilleとConduitionはどちらも、個別のBIP360（P2MR）リーフや 単純なスクリプトの組み合わせで同様の結果を達成できる場合に、 統合ハイブリッド方式がその複雑さに見合う価値があるのかについては疑問を呈しました。

  • ● 格子ベース署名: Nikita Karetnikovは、ポスト量子署名ファミリーを比較する Blockstreamのブログ記事について、Delving Bitcoinに投稿し、 Bitcoin-Devメーリングリストにもクロスポストしました。この比較では、 格子ベースの方式がサイズと機能性の面で有利に見えます。彼は、 なぜBitcoinのポスト量子関連の作業がハッシュベース署名に焦点を当てているのか尋ねました。

    Conduitionは、より弱いセキュリティ仮定、実装のシンプルさ、高速な検証、 そして長期的なフォールバックとしての適性ゆえに、ハッシュベース署名はBitcoinにとって依然として魅力的だと返信しました。 Mikhail Kudinovは、素朴に実装すると格子ベース署名は浮動小数点演算を必要とすることが多いが、 Falconの浮動小数点演算は整数でシミュレートできると指摘しました。 ConduitionとJesse Posnerは、統合ハイブリッドSchnorr+格子方式が必要なのか、 それとも別々のBIP360(P2MR)リーフで同様のセキュリティを達成できるのかを議論しました。 一方、Boris Nagaevは、ハイブリッド署名を複数の署名方式の単純な連結としてではなく単一の構成として扱うことによる スペースの節約について説明しました。たとえば、各方式が必要とする特定のランダム化パラメータを共有できる可能性があります。

  • ● P2MRのECリーフの公開鍵復元: stariusは、 BIP360(P2MR)に復元可能な楕円曲線(EC)鍵のリーフタイプを追加する提案をDelving Bitcoinに投稿しました。 このアイデアは、Schnorr署名からEC公開鍵を復元するというものです。 公開鍵はスクリプトの代わりにP2MRのマークルツリーにコミットされ、 Schnorr署名のチャレンジは公開鍵そのものの代わりにマークルルートとコントロールブロックを含むように変更されます。 マークルルートとコントロールブロックは署名時と検証時の両方で既知であるため、公開鍵を知らなくても署名を検証でき、 その後コントロールブロックを介して公開鍵がマークルルートに含まれていることを検証できます。 この手法を使うと、深さ1のSchnorrリーフのwitnessは135 byteから100 byteに縮小され、 P2TRのkey-spendとP2WPKHの支出の中間のサイズになりますが、 その代償としてBIP340のバッチ検証を諦めることになります。stariusとConduitionは、 コントロールブロックをチャレンジに含めることで、 複数のこうしたリーフが1つのツリーを共有する場合の関連鍵攻撃を防げると説明しました。 Pieter Wuilleはこの構成を好意的にレビューしました。Anthony Towns、Pieter Wuille、 Conduitionは、BIP32導出への影響、バッチ検証によるディスカウント、 そしてConduitionの深さゼロツリー禁止案との相互作用について議論しました(深さゼロの復元可能リーフは、 ポスト量子フォールバックなしのP2TRのwitnessサイズに匹敵し得る)。 stariusは、witnessの解析ルールを変更するため、これはアクティベーション前にBIP360に組み込まれるべきだと説明しました。

  • ● P2MRにおけるプライバシーインセンティブの調整: Conduitionは、 すべてのP2MRコントロールブロックに少なくとも1つの32 byteのマークル認証パスを含めることを必須とする BIP360(P2MR)の変更案をBitcoin-Devメーリングリストに投稿しました (つまり深さゼロのスクリプトツリーを禁止します)。深さゼロのツリーは、 単一のスクリプトパスのみを必要とする一部のプロトコルがP2TRよりもP2MRで効率的になり、 協調的な署名パスを省略する誤ったインセンティブが生じ、 一部のコントラクトプロトコルをオンチェーンで識別しやすくなります。

    Antoine Poinsotは、この変更がそのプライバシー上の懸念に対処することには同意しましたが、 典型的な単一鍵のP2MR支払いはP2TRv2よりもコストが約15%高いため(前述の鍵復元を使えばもっと少なくなる可能性あり)、 大規模な移行には依然としてP2TRv2を選好しています。Pieter Wuilleは、 長期的なポスト量子効率よりも量子以前の導入インセンティブの方が重要であり、 P2TRv2の方が移行コストを最小化できると主張しました。また、P2MRは、 将来のソフトフォークでP2MR内の楕円曲線パスが無効化されることをユーザーが当てにできる場合にのみ意味を持つとも指摘しました。 Conduitionは、どちらの設計でも自発的な移行率は同様に低いと予測し、一般的な楕円曲線支払いに対する 今後のwitnessサイズの最適化(次の項を参照)に言及しました。Hayashiは、コスト差をさらに縮めるために、 P2MRのSchnorrリーフに追加のwitnessディスカウントを与えることを提案しました。

  • ● 最小の64 byteトランザクションをエンコードするマークル内部ノードのプリイメージの禁止: Jeremy Rubinは、witnessを除いた64 byteのトランザクションをコンセンサス上無効とする コンセンサスクリーンアップ(BIP54)のルールに代わる案を提案するドラフトBIPを Bitcoin-Devメーリングリストに投稿しました。Rubinのルールは、 トランザクション自体を禁止するのではなく、トランザクションマークルツリー内に、 1インプット1アウトプット、witnessを除いたトランザクションのbyteレイアウトを持つノードプリイメージが含まれるブロックを無効とします。 これは、潜在的に有用な64 byteトランザクションを維持しつつ(ニュースレター #408 参照)、 同じマークルツリーの脆弱性に内部ノードの境界で対処するものです。 SPV検証者は、ブランチのプリイメージが禁止パターンに一致する証明を拒否する必要があります。 このドラフトには、マイナー向けの復旧ガイダンス(問題のあるトランザクションの並べ替えまたは除外)が含まれており、 偶発的な違反は稀なはずだと述べています。

    複数の返信では、BIP54のよりシンプルな64バイトトランザクションの全面禁止の方が支持されました。 Antoine Poinsotは、価値を守るシステムはすでにこれらのトランザクションを適切に検証しているため、 Rubinの提案する区別は実用上ほとんど意味がないと主張しました。Matt Coralloは、この案では、 マイナーはブロック構築ソフトウェアを変更するか、無効なブロックを生成するリスクを負うことになると指摘しました。 Murchは、時折1バイトのパディングを追加する方が、ブロック検証時にすべてのノードで数千のハッシュを チェックさせるよりも負担が小さいと指摘しました。Sjors Provoostは、よりクリーンな修正は 将来のブロックヘッダーフォーマット変更まで先送りすることを提案しました。

  • ● NUMSポイント支払いまたはハッシュレート過半数によるEC無効化のトリガー: Pieter Wuilleは、 BIP360(P2MR)やP2TRv2などの 新しいポスト量子アウトプットタイプ内の楕円曲線(EC)支払いパスについて、 将来予想されている無効化を成文化することについてBitcoin-Devメーリングリストに投稿しました。 コンセンサスで強制されるトリガーがなければ、ユーザーはEC支払いが実際に無効化されると確信できず、 当初は安価なEC支払いを許容するアウトプットタイプの耐量子性のストーリーが損なわれてしまいます。

    Wuilleは、導入するソフトフォークにバンドルする2つのメカニズムを提案しました。 トリップワイヤー(P2XX-T)は、<NUMS> OP_CHECKSIGの支払いが成功し secp256k1が破られたことが証明された後、新しいアウトプットタイプ内のECパスを無効化するもので、ECの利用可能期間に没収を伴わない上限を設けます。 そしてマイナーロックダウン(P2XX-ML)は、非常に長いアクティベーション期間を持つ別途シグナリングされるソフトフォークを通じて、 ハッシュレートの過半数が同じ無効化を発動できるようにするものです。 Boris Nagaevはトリップワイヤーを支持しましたが、 大規模な古典的窃盗の後にマイナーロックダウンが誤検知を起こす懸念を提起しました。 Sjors Provoostは、その対策として長い遅延とP2TRへのユーザーの再移行を提案しました。 Conduitionはトリップワイヤーを支持し、証明はオンチェーンでマイニングされる必要はないと指摘するとともに、 早期のマイナーロックダウンには手数料面のインセンティブが働き得ると警告しました。 Wuilleは、無効化はそのアウトプットタイプ内のすべてのEC利用(key-pathだけでなく)を対象にしなければならないこと、 そしてEC無効化後の支払い可能性を保証するために、ハイブリッド署名は任意のスクリプトの組み合わせではなく 専用のopcodeを使うべきであることを明確にしました。

リリースとリリース候補

人気の Bitcoin インフラプロジェクトの新しいリリースとリリース候補です。 新しいリリースへのアップグレードやリリース候補のテストへの協力をご検討ください。

  • ● Bitcoin Core 31.1rc1は、主要なフルノード実装のメンテナンスバージョンのリリース候補です。 トランザクションの発信元プライバシーを損なう可能性のあった -privatebroadcastのIPアドレス漏洩を修正し(ニュースレター #409 参照)、 chainstateの圧縮、ウォレットの移行、 インプットサイズの推定、MuSig2の鍵集約、 v2 P2Pトランスポート再接続時のプロキシ処理に関する修正が含まれています。

  • ● Bitcoin Core 30.3rc1は、主要なフルノード実装のメンテナンスバージョンのリリース候補です。 通常動作中に過剰なディスク読み書きを引き起こす可能性のあったchainstateデータベースの問題を修正し、 ウォレット、PSBT、miniscript、ネットワーキング、ビルド、テスト、 ドキュメントの修正が含まれています。

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

  • ● Core Lightning v26.06.2は、TLSルート証明書がインストールされていない最小限のOSや Docker環境でのcln-currencyrateを修正するメンテナンスリリースです。

  • ● LND v0.20.2-beta.rc1は、この人気のLNノード実装のメンテナンスリリースのリリース候補です。 DNSフォールバックのパニックとオンチェーンのフォワードインターセプター決済のバグを修正し、 下記の注目すべきコードのセクションで説明されている最終ホップのHTLC CLTV有効期限の検証を追加します。

  • ● LND v0.21.1-betaは、この人気のLNノード実装のメンテナンスリリースです。 新規にTorを有効化したノードでのTor v3オニオンサービスの作成、 DNSフォールバックのパニック、オンチェーンのフォワードインターセプター決済のバグを修正し、 最終ホップのHTLC CLTV有効期限の検証を厳格化します。

  • ● LDK v0.2.4は、LN 対応のウォレットやアプリケーションを構築するためのこのライブラリのメンテナンスリリースです。 lightningクレートの最小サポートRustバージョンを引き上げてしまったv0.2.3のリグレッションを修正し、 このクレートは再びrustc 1.63でコンパイルできるようになりました。

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

最近の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 #35266は、migratewallet RPCにload_wallet引数 (デフォルトは true)を追加し、 レガシーウォレットをディスクリプターウォレットに移行する際、 移行後のウォレットを即座に読み込むことなく移行処理を行えるようにします。 これは、chainstateがウォレットの誕生日より前までプルーニングされているノード上で、 レガシーウォレットを移行するユーザーの助けになります。この場合、移行自体には不要であるにもかかわらず、 移行後のウォレットを読み込むには利用不可能なブロックデータが必要になるためです。

  • ● Bitcoin Core #35550は、コンパクトブロックリレーのネゴシエーション処理を更新し、 BIP152で規定されているとおり、sendcmpctメッセージ内のブール値のアナウンスフィールドが厳密に 0または1でない場合は拒否するようにします。これまでのBitcoin Coreは このフィールドを直接C++のboolとしてデコードしていたため、0以外の任意の値がtrueとして受け入れられていました。 このPRでは、フィールドを整数として読み取り、1より大きい値をピアの不正行為として扱い、そのピアを切断します。

  • ● Bitcoin Core #35610は、bitcoin-utilにnetmagicコマンドを追加します。 これは、カスタムsignetを含む、選択されたチェーンのBitcoin P2Pメッセージで使用される 4 byteのネットワーク識別子を出力します。このコマンドは、提案されているマルチsignet対応のデータディレクトリサポートに有用です。 この機能では、カスタムsignetはネットワーク識別子をサフィックスとするデータディレクトリに保存されます。 これにより、スクリプトがbitcoindを起動する前に正しいディレクトリを選択できるようになります。

  • ● BIPs #2196は、Testnet 4を置き換えることを意図した新しいテストネットワーク であるTestnet 5のドラフト仕様BIP95を追加します(ニュースレター #409 参照)。 Testnet 4には、ブロック生成の間隔が長く空いた後に最小難易度のブロックを許容する難易度に関する例外規定があります。 しかし、この例外は執拗に悪用され、頻繁な小規模の再編成を引き起こし、テスト用途でのネットワークの利用を困難にしています。 Testnet 5はこの例外を削除し、最小難易度を約1,048,561に引き上げ、 ブロック1からBIP54のコンセンサスクリーンアップルールを適用します。 このドラフトはまた、メッセージ開始バイト0x46495645(FIVE)とデフォルトP2Pポート18335 を規定していますが、ジェネシスブロックの値は今のところプレースホルダーのままです。

  • ● BIPs #2165は、ニュースレター #181で紹介された「Optical Proof-of-Work」の提案である BIP52を更新し、そのステータスをDraftからClosedに変更します。BIP52は、 マイニングコストを電気代や運用から専用の光学マイニング機器へと移すと主張するハードフォークを提案していました。 数年間進展がなく、最近になって著者への連絡も試みられたものの成功しなかったため、この提案はクローズされました。

  • ● BIPs #2201は、Reduced Data Temporary Softfork提案であるBIP110を Completeステータスに進めます(ニュースレター #392 参照)。 この更新は、アクティベーション前に作成されたUTXOには旧ルールが適用され、 デプロイ期間中も旧ルールの下で支払いできることを強調しています。 また、リファレンス実装のテストカバレッジとトランザクションレベルのテストベクターを追加します。 さらに、tapscriptリーフでのOP_IFおよびOP_NOTIFの実行を一時的に禁止することの影響を明確にしています。 既存のUTXOは対象外ですが、これらのopcodeを使う新しい構成には、別々のリーフを使うなどの代替手段が必要になります。

  • ● LND #10900は、1P1Cのトランザクションパッケージを LNDのチェーンバックエンドに送信するためのWalletKit.SubmitPackage RPCと lncli wallet submitpackageコマンドを追加します。bitcoindバックエンドの場合、 LNDはパッケージをBitcoin Coreのsubmitpackage RPCに転送し、 エフェメラルアンカーを持つ 手数料ゼロのv3トランザクションリレーの親トランザクションを、 CPFPで手数料を支払う子トランザクションと一緒に受け入れられるようにします。 他のバックエンドは同様のパッケージ送信を提供していません。btcdはunimplementedを返し、 neutrinoはトランザクションを個別にブロードキャストします。

  • ● LND #10927は、最終ホップのHTLC CLTV有効期限の検証を厳格化します。 これまでは、最終ホップのHTLCは、転送用のCLTVデルタはすでに制限されていたにもかかわらず、 受信者のポリシーが許容するよりもはるかに先の有効期限を指定でき、過剰な期間にわたって流動性を拘束する可能性がありました。 LNDは、受信者のCLTVポリシーの範囲外の最終HTLCをincorrect_or_unknown_payment_detailsで拒否し、 関連する設定の境界を検証し、プリイメージを使ってHTLCをオンチェーンで請求するかどうかを決定する前に チャネルが強制閉鎖された場合にも同じチェックを適用するようになりました。

  • ● LDK #4748と#4751は、遅延メッセージが関係する 2つのスプライシングステートマシンのエッジケースを修正します。 LDK #4748は、無関係なHTLCプリイメージのチャネルモニター更新が保留中の間に、 遅延したスプライスのtx_signaturesが到着し、LDKが誤ってスプライスフローの完了をブロックしてしまうケースを修正します。 LDKは現在、保留中のモニター更新が、先に永続的に保存されなければならないスプライス関連の更新である場合にのみ待機します。 #4751 は、ローカルユーザーが自身の資金拠出をキャンセルした後に、 ピアの送信中だったスプライスのcommitment_signedが到着し、 LDKが古くなったスプライスのファンディングトランザクションに対する署名を検証してしまい、 まだ有効なチャネルを強制閉鎖してしまう可能性のあるケースを修正します。 LDKは現在、commitment_signedのオプションのfunding_txidをチェックし、 古くなったスプライスのファンディングトランザクションに対する署名を無視します。

もっと知りたいですか？

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