en | ja | es | cs | hi | zh | de | fr | pt

Bitcoin Optech Newsletter #430

Nov 6, 2026

今週のニュースレターでは、家庭用ルーターの背後にあるノードを到達可能にするために TCPホールパンチングを利用することに関する継続的な議論と、コベナンツをエミュレートする際に共同署名者が適用する支払いポリシーを標準化するBIPドラフトを掲載しています。また、Bitcoinのコンセンサスルールの変更に関する提案と議論、新しいリリースとリリース候補の発表、人気のBitcoin基盤ソフトウェアの注目すべき更新など、恒例のセクションも含まれています。

ニュース

● ホームノードのためのTCPホールパンチングに関する議論の継続: 家庭用ルーターの背後にあるノード同士が互いの接続を受け入れられるようにするためにホールパンチングを利用するという 0xB10CによるDelving Bitcoinスレッドについての5月のまとめに続き、0xB10Cは、仕様と実験的なBitcoin Core実装の作業が再開されたことを投稿しました。ホームノードは通常、アウトバウンド接続しか行えず、Bitcoin Core 30.0で NAT-PMPによるポートマッピングをデフォルトで有効にしても、期待されたほど多くのノードが到達可能にはなりませんでした。ホールパンチングは、2つのホームノードが同時に互いへの接続を開始し、それぞれのルーターが相手のトラフィックを通過させるようにする手法で、ポートフォワードを補完する手段となります。到達可能な誠実なノードが増えれば、外部から接続しやすいノードを持つ攻撃者が、ターゲットとなるノードのアウトバウンド接続スロットを埋め尽くすことが難しくなります。

0xB10Cはこれまでに議論された4つの設計を振り返り、コーディネーターを必要としない新しい選択肢を提案しました。この設計では、ノードはホールパンチ可能なアドレスと一時的な公開鍵を新しいaddr v2メッセージ形式でアナウンスし、各ノードペアは共有シークレットと新しいブロックごとに、同じ候補リストとホールパンチングのタイミングを導出します。攻撃者が実在するアドレスでこの方式を溢れさせることができるというAnthony Townsの異論を受け、さらにその後、到達不能なノードはリスニングノードに比べてこうしたアナウンスを受信できる確実性がはるかに低いことが判明したため、彼は、ピアを探しているホームノードの検証済みアドレスをリスニングノードが保持する「掲示板」方式の代替案も示しました。

Townsは、ランダムなインバウンド接続がそもそもホームノードの役に立つのか疑問を呈し、ホールパンチングは攻撃者が誠実なノードに直接到達することを容易にする一方で、誠実なノードへの接続を保証することにはほとんど役立たないと主張しました。彼は、約10,000個のアドレスをアナウンスする攻撃者は、大半の誠実なノードにとって早い段階でマッチする相手になると見積もり、より低リスクな代替案としてランダムなピアとの短時間の接続を提案しました。Jonathan Harvey-Buschelは、誠実なノードは攻撃者が制御するノードよりも到達可能性が低いことを示すデータを引用し、ノード自身のTorサービスを介した調整を支持しました。その後Townsは、最近のTCPやプロトコルの脆弱性を踏まえると、ホームユーザーにとってはインバウンド接続を受け入れないことの方が安全なデフォルトなのではないかと問いかけました。議論は継続中です。
● 共同署名者の支払いポリシーを標準化するためのBIPドラフト: Luke Carriereは、コベナンツをエミュレートする際に共同署名者が適用する支払いポリシーを標準化する提案について、 Delving Bitcoinに投稿しました。Johan Halsethのブラインド共同署名者やチェーンコードの委任など、最近のいくつかの設計はそれぞれ独自のポリシーを定義しているため、ある設計向けに構築されたウォレットは、別の設計向けに構築された共同署名者やオラクルを使用できません。 CarriereはこのドラフトについてBIP番号を求めてはおらず、標準化するレイヤーとしてここが適切かどうかを問いかけています。

ドラフトは以下のいくつかの設計原則に従っています:
- Bitcoin Scriptで適用できるものはすべてScriptで適用しなければならず、共同署名者のポリシーはScriptで適用できないものだけを定義します。
- 共同署名者を必要としない支払いパスが少なくとも1つ常に利用可能でなければなりません。
- 共同署名者が支払いをどのように検証するか、そしてその誠実性を何が担保するかは、ポリシーごとに選択する差し替え可能なプロファイルとします。
- 既存のオラクルを変更なしで再利用できるように、共同署名者はDLC形式のオラクルのアテステーションを受け入れなければなりません。
ポリシーは5つの要素で構成されています。アウトプットは資金を保持するTaprootディスクリプターを定義し、共同署名者グループはどの共同署名者が参加し、何人が署名しなければならないかを示し、テンプレートは共同署名者が署名できるトランザクションをその正確なアウトプットとともに列挙し、条件は各テンプレートに署名する前に何が成立していなければならないかを定め、プロファイルは検証モード、証拠の形式、および不正時の責任追及の仕組み（もしあれば）を指定します。シリアライゼーションにJSONとTLVのどちらを使うか、ブラインド検証を今仕様に規定すべきか、それとも実装経験がさらに蓄積されるまで待つべきか、ステートメントのアテステーション形式をこの提案で規定するかDLCの仕様で規定するか、フォールバックパスにタイムロックを必須とするかなど、いくつかの点は未解決のままです。

その後の議論で、PREDGEは、statement-v0と呼ばれる証拠プロファイルの1つにファイナリティフラグがないため、共同署名者が後で訂正される暫定的なアテステーションに基づいて行動してしまう可能性があると指摘しました。さらにtehiyaduは、異なる実装が同じバイト列を受け入れながら異なる条件を適用することを防ぐために、ポリシーハッシュは正確な検証者のセマンティクスにコミットすべきだと述べました。 Carriereは両方の指摘に同意し、ファイナリティフラグを追加し、検証者のルールを厳密に定めると述べました。

コンセンサスの変更

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

● BIP54に関する議論の継続: Antoine Riardは、コンセンサスクリーンアップソフトフォーク（BIP54）の現状に関する自身の見解を Bitcoin-Devメーリングリストに投稿しました。witnessを除いたサイズがちょうど64 byteのトランザクションを禁止するルールが、依然として最も議論の多いルールです。 Bitcoin Coreの実装がレビューとテスト中で、BIPからリンクされているリファレンス実装となっています（Bitcoin Core #35793）。このPRはregtestで新しいルールを有効にするもので、mainnetでのアクティベーションは含まれません。彼はまた、 btcdでの相互運用性の作業（btcd #2537）にも言及し、libbitcoinの実装については把握していないと述べました。彼の見解では、残っているのは、さらなるレビューとテスト、segwit以前のScriptにおける署名操作数を2,500に制限する提案と 64 byteルールについてウォレットが把握できるようにするためのドキュメント、そしてその後でアクティベーションロジックです。あくまで個人的な見解として、コミュニティがそれまでに合意すれば、 2027年後半にアクティベーションの検討を開始するのは現実的かもしれないと述べました。

Pieter Wuilleは、BIP54の2つのタイムスタンプルールがチェーン長をどのように制限するかに関する Delving Bitcoinのスレッドを更新しました（ニュースレター #425参照）。最初の投稿には現在、作業量の下限を求める正確な式が含まれており、その式と10進数近似の両方が、リンクされたLeanコードで証明されるようになりました。

Riardは、BIP54の設計中に提起された懸念点についてフォローアップしました。それは、タイムワープバグを修正すると、Mark Friedenbachが提案したフォワードブロックのようなスタイルのコンセンサス変更が、将来にわたって不可能になるというものです。今回の修正はタイムスタンプの操作を排除するのではなく制限するものであるため、より限定的なフォワードブロックの提案であれば依然として実装可能です。彼は、修正後も許容される7,200秒のウィンドウ幅によって、難易度調整期間ごとに難易度を約0.60%下げ、ブロックレートをほぼ同程度上げることができると見積もりました。これは、元の提案による容量の拡大には遠く及びません。Riardはまた、このアイディアは従来ルールのもとでも健全ではないと主張しました。検証者は、トランザクションをフォワードチェーン上で一度処理し、互換チェーンに同期される際に再度処理することになりますが、ユーザーが二重に支払わない限り手数料は同じであり、アップグレードしていないノードも追加データをダウンロードしなければなりません。 Riardは、この主張を述べた短い脚注をBIP54に追加することを提案し、Friedenbachに反論を求める予定です。
● オプトインのリプレイ保護プロトタイプ: Sjors Provoostは、チェーン分岐時のオプトインのリプレイ保護に関する Delving Bitcoinのスレッド（ニュースレター #420参照）で、新しいwitnessバージョンを使用するプロトタイプについて提案しました。ペイロードが0x01で始まるannexを用いて特定のブロックを4 byteのブロック高で指定し、インプットに含まれるすべての署名が、意図したチェーン上のそのブロックのハッシュにコミットします。ハッシュ自体はトランザクション内には含まれません。彼は追加コストを1.75 vbyteとしています。指定されるブロックは、コインベースの成熟期間と同じく、少なくとも100ブロック前のものでなければなりません。彼は、ハッシュレートが均等に分かれた場合でも、ルールは片側でのみ成立すればよいため、コインを分割できるまでの待ち時間は最長でも2日になると述べました。彼は、このwitnessバージョンを、 CISA（BIP460）、BIP360、後からキーパスを無効化できるP2TRv2スタイルのアウトプットなど、新しいwitnessバージョンを必要とする別の提案と一緒にリリースすることを提案しました。

Anthony Townsは、新しいwitnessバージョンは不要で、BIP118のようなスタイルで、 Taprootの署名チェック用の新しい公開鍵エンコーディングがあれば十分だと返信しました。 Provoostは、そのエンコーディングは検討したもののハックだと考えており、自身の理解ではキーパスによる支払いでは機能しないと答えました。

Moonsettlerは、この機能が最も重要となる分岐において100ブロックを要求することが望ましいのか疑問を呈し、その遅延を緩和可能なポリシールールとして維持することを提案しました。Provoostは、より速い側でコインが移動して承認を得た後は、遅い側ではもはや保護が必要ないと返信しました。 Provoostはまた、このルールは論争的なハードフォークの前にデプロイされ、両方の側がそれを継承することを想定しており、どちらの側も簡単にはそれを取り除けないと書きました。ブロックハッシュは署名メッセージにのみ含まれるため、ルールを削除するには、ハッシュを含めるようにトランザクションのシリアライゼーションを変更する必要があるためです。
● 未移行のコインのためのQSAVE: James Taggは、コインを焼却することなくポスト量子環境に移行するQSAVE（Quantum Secure Asset Verification and Escrow）の 5つのBIPドラフトを Bitcoin-Devメーリングリストに投稿しました。彼はこれらをBIP361およびHourglassの代替案として位置づけています。ソフトフォークとしていつでもアクティベート可能な適用開始ブロック高を設定し、それ以降、既知のポスト量子タイプのレジストリに含まれないインプットは、未知のScriptタイプや将来のScriptタイプも含め、すべて未移行として扱われます。未移行のインプットは、引き続きロックスクリプトを満たす必要があるのに加え、第2の要素も必要とします。それは、同一のシードから使用対象のスクリプトとポスト量子鍵の両方が導出されることを示すゼロ知識証明、あるいは期限（カットオフ）前にコミットされたポスト量子バインディングのいずれかです。トランザクション内の未移行のインプットのいずれかにこの第2の要素がない場合、使用可能なすべてのアウトプットはリカバリーアウトプットでなければなりません。 QSAVEには期限切れ（サンセット）の概念がないため、第2の要素がなくてもコインが破棄されることはありません。オンチェーンの証明があれば、第三者なしでいつでも直接使用できます。それ以外の場合について、彼はオフチェーンの遺失物処理プロセスについても言及しました（その法的・経済的な扱いはコンセンサスの範囲外としています）。このプロセスでは、分散型のカストディアンのセットが、バックアップカストディアンと拒否権を持つコントローラーとともにリカバリーアウトプットを保持し、さらにその資金から得られる0.5%程度の保守的な運用益は慈善事業に充てられる仕組みとなっています。ドラフトでは、カットオフ前のウォーターマーク、彼がQD5と呼ぶオプションのML-DSA-87鍵および BIP360（P2MR）アウトプット用のzk-STARK支払いリーフの仕様も規定されています。
● 未移行のアウトプットに対するProof-of-decay: bitKingAEは、初期のP2PKコインのようにポスト量子の脅威にさらされるアウトプットのうち、猶予期間内に移動されないものを縮小させるスケッチをDelving Bitcoinに投稿しました。猶予期間が終了すると、アウトプットの金額はブロック高に応じたスケジュールで段階的に減少します。失われたsatoshiは、コインを凍結したり署名を作成できる人に委ねたりするのではなく、焼却されるかマイニング報酬として支払われます。投稿の例では、50,000ブロックごとに残高の数パーセントを減少させるものでした。 Vinicius Cestariは、3つの異論を返信しました。量子攻撃者は猶予期間の終了を待ち、減衰が大きく進む前に脅威にさらされたアウトプットを奪取できること、量子攻撃の急激な進歩があればさらに早く資金を奪えること、そしてこの仕組みは、すでに鍵を盗まれた所有者を含め、何もしない所有者の残高を減少させてしまうことです。
● BIP300のバンドル検閲: Ori Newmanは、ドライブチェーンの提案（BIP300）において、ハッシュレートの26%を持つマイナーが有効な引き出しバンドルを無期限に検閲できると Bitcoin-Devメーリングリストで主張しました。彼によれば、 26%のマイナーが、自身がマイニングするすべてのブロックでALARMを送信すると、それらのブロックはそれぞれ保留中のすべてのバンドルのスコアを1ずつ下げます。残りの74%のハッシュレートがすべてのブロックで特定のバンドルに対して賛成票を投じたとしても、 26,300ブロックのウィンドウの終了時点でのスコアの期待値は12,624となり、必要な13,150に届きません。彼は、 ALARMおよびその他の反対票を禁止することを提案しました。これにより誠実な多数派の前提が回復し、ハッシュレートの51%に支持されたバンドルはほぼ確実に承認され、49%の支持しか得られないバンドルはほぼ確実に否認されます。現在のルールが意図的なものである場合は、代わりにBIPに「75%の誠実な多数派の前提」を明記するよう求めました。彼はこれをBitcoinのセキュリティモデルからの大きな逸脱だとしつつも、この前提を支持する根拠の1つとして、ハッシュレートが75%未満の攻撃者にとっては資金を盗むことがより困難になる点を挙げました。

リリースとリリース候補

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

● LND v0.21.6-betaおよびv0.20.7-betaは、この人気のLNノード実装の 0.21ブランチと0.20ブランチのセキュリティリリースです。どちらにも、以下のLND #11456で説明するLinuxカーネルの脆弱性CVE-2026-98432の緩和策が含まれています。 LNDの緩和策では根本的な脆弱性は修正されないため、Linuxのオペレーターはアップグレードに加えて、他のサービスを保護するためにホストでMPTCPを無効にし、パッチが適用されたカーネルをインストールする必要があります。
● Core Lightning 26.06.10は、この人気のLNノード実装のセキュリティリリースです。デュアルファンディング、スプライシング、オンチェーンでのHTLCの解決、アクセス制御、その他のコンポーネントの脆弱性が修正されています。セキュリティ修正のソースコードは公開されていますが、ユーザーがアップグレードする時間を確保するため、関連するテストは一時的に非公開となっています。プロジェクトはアップグレードを強く推奨しています。
● BTCPay Server 2.4.7は、このセルフホスト型ペイメントプロセッサーのセキュリティリリースです。支払い上限、他のストアのデータへのアクセス、認証、リソース枯渇に影響する問題を含む、 AnthropicのOSS Scannerプログラムによって報告された 85件のセキュリティ上の問題が修正されています。また、支払いの会計処理と信頼性の問題も修正されています。特に複数のマーチャントで共有されているサーバーでは、アップデートが強く推奨されます。

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

最近の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 #36539は、GUIからエクスポートされる未署名トランザクションおよび手数料の引き上げについて、 PSBTv0形式を復元しました。Bitcoin Core 32.1では、これらのPSBTをバージョン2でエクスポートしていたため、ユーザーはバージョン0のみをサポートするツールで署名できませんでした。 -signerで設定される別の外部署名者のワークフロー（ニュースレター #138参照）は、引き続きPSBTv2を使用するため、それらのユーザーはHWI 2.1.0以降など、PSBTv2をサポートする外部署名者が必要です。
● Bitcoin Core #35714は、ブロックデータまたはundoデータのディスクへのフラッシュに失敗した後に、ノードがブロックインデックスとUTXOデータベースを更新する可能性があったバグを修正しました。この失敗によってノードにはシャットダウンが通知されますが、これらの書き込みを処理するコードが、ノードが停止する前にデータベースを更新してしまう可能性がありました。これらの更新が成功した場合、裏付けとなるブロックデータまたはundoデータがまだ安全に保存されていない状態をデータベースが記録してしまう可能性がありました。これにより、ノードのローカル状態に不整合が生じ、復旧が困難になる可能性がありました。現在は、失敗したフラッシュの試行中はこれらのデータベースへの書き込みをスキップします。これは、ニュースレター #414で取り上げた、オプションのインデックスに対する以前のフラッシュ順序の保護を補完するものです。
● Bitcoin Core #35492は、bitcoin-wallet dump（ニュースレター #130参照）が、不完全なウォレットのエクスポートを書き込んだ後に成功を報告する可能性があったバグを修正しました。これまでは、このコマンドは出力先のファイルを開けるかどうかはチェックしていましたが、ディスク容量の不足など、その後の書き込みの失敗を検出していませんでした。その結果、ユーザーはエクスポートが完了したと誤解し、ウォレットを復元しようとした際にデータの欠落に気付くことになる可能性がありました。現在は、ファイルの書き込み、フラッシュ、クローズを検証するようになりました。失敗を報告し、不完全なダンプファイルを削除します。
● BIPs #2205、#2210および#2212は、クロスインプット署名集約（CISA）に関する3つのドラフト仕様を追加しました。BIP458は、非対話型のハーフアグリゲーションを規定しており、n個の既存のBIP340署名を、 64 × n byteではなく32 × (n + 1) byteに結合します。BIP459は、複数の鍵とメッセージに対して単一の64 byteの集約署名を生成する対話型プロトコルであるDahLIASを規定しています。 BIP460は、新しいwitnessバージョン2のアウトプットのキーパスによる支払いにこれらのスキームを使用することを提案しており、スクリプトパスによる支払いでは個別の署名を維持し、キーパスのインプットがオプトアウトできるようにしています。この提案がニュースレター #417で取り上げられて以降、オプトアウトしたインプットは特別なマーカーなしで通常のBIP341署名を使用するよう変更され、ウォレットは既存の署名ロジックを再利用しながら新しいアウトプットタイプを採用できるようになりました。これにより、coinjoinやpayjoinなど、複数のインプットが参加するトランザクションのweightと手数料が削減されます。提案されたトランザクションの集約をデプロイするにはソフトフォークが必要です。BIP460では、アクティベーションのメカニズムとパラメーターは規定されていません。
● Core Lightning #9419は、ローカルで失敗した転送の試行について、listforwards RPCとforward_event通知にオプションのfailure_reasonフィールドを追加しました。これまでは、複数の異なる問題が同じプロトコルの失敗コードを共有していたため、オペレーターが転送の失敗理由を判断するのは困難でした。新しいフィールドは、アウトバウンドの流動性の不足、送信先ピアのオフライン、保留中のHTLCの数または合計額の制限などの原因を区別します。
● Core Lightning #9592は、xpay（ニュースレター #330参照）を更新し、転送ノードがunknown_next_peerを2回返した後は、その支払いの残りでそのノードを回避するようにしました。これまでは、失敗ごとに報告されたチャネルのみが除外されていたため、支払いのリトライ時間が切れるまで、後続の試行で同じノードを経由する別のチャネルが選択され続ける可能性がありました。現在は、同じノードからの2回目の失敗後、xpayは支払いのプライベートなaskreneルーティングレイヤーを通じてそのノードを除外します。このヒューリスティックは使用可能なチャネルを除外してしまう可能性がありますが、同じノードを経由した試行の繰り返しを制限します。
● LDK #5089は、アンカーアウトプットを持つチャネルの強制閉鎖時の手数料の引き上げを更新しました。アンカーアウトプットを使用するCPFPの子トランザクションに必要な資金をLDKが取得できない場合、コミットメントトランザクションのみをブロードキャストするようになりました。これまでは、この失敗によって両方のトランザクションがブロードキャストされないままとなり、チャネル資金の回収が遅れる可能性がありました。コミットメントにはすでに手数料が含まれているため、手数料の推定が保守的だった場合やネットワークの需要が減少した場合には、承認に十分な場合があります。ただし、このフォールバックは、リレーに手数料を支払う子トランザクションを必要とするゼロ手数料のコミットメントトランザクションには適用されません。この問題はProject Loupeによって報告されました。
● LND #11456は、MPTCPを使用したリモートコード実行が実証されたLinuxカーネルの脆弱性 CVE-2026-98432を緩和するため、 Multipath TCP（MPTCP）リスナーをデフォルトで無効にしました。Go 1.24以降では、サポートされているLinuxシステムでこれらのリスナーがデフォルトで有効になっているため、 LNDのオペレーターはMPTCPを明示的に設定していなくても脆弱性にさらされる可能性がありました。この変更により、 LNDのGoのデフォルト設定でmultipathtcp=0が設定されます。これにより、 LNDのリスナーを経由する実証済みのエクスプロイトの経路はブロックされますが、根本的なカーネルのバグは修正されません。影響を受けるシステムには、引き続きパッチが適用されたカーネルが必要です。既存のバイナリを使用しているオペレーターは、環境変数GODEBUG=multipathtcp=0を指定してLNDを再起動することで、同じ緩和策を適用できます。
● LND #11357は、BOLTs #1357（ニュースレター #428参照）に従って、 BOLT11インボイスの検証を厳格化しました。最初のフィールドを使用して残りを無視するのではなく、重複したペイメントシークレットフィールドを拒否するようになり、異なる出現箇所を選択するパーサー間での曖昧さを防止します。これは、以前の重複したペイメントハッシュの拒否（ニュースレター #425参照）を基にしたものです。仕様の更新で追加されたテストにより、既存の要件が適用されていなかったことも明らかになりました。デコーダーは、ペイメントハッシュ、description hash、ペイメントシークレット、受信者の公開鍵をパースする際に、これらのフィールドを存在しないものとして扱うのではなく、不正な長さを拒否するようになりました。これまでは、サイズが不正な受信者の公開鍵フィールドがあると、LNDが署名から鍵を復元する処理にフォールバックする可能性がありました。明示的な受信者の公開鍵を含むインボイスについては、low-SのECDSA署名も必須となります。ただし、公開鍵が署名から復元される場合には、この制限は適用されません（ニュースレター #381参照）。
● LND #11413は、SQLiteまたはPostgreSQLを使用するノードにおいて、保存された送信支払いの結果の起動時のクリーンアップを高速化しました。通常の運用中、ノードはローカルで開始され解決されたHTLCの試行ごとに結果を蓄積します。起動時には、不要になった結果を削除します。これまでは、エントリーを個別に読み取って削除するためにデータベースとの往復が繰り返し必要で、リモートのPostgreSQLを使用している負荷の高いノードでは、クリーンアップに数時間かかる可能性がありました。現在は、保留中の支払いを再開するのに必要な結果を保持しつつ、データベース操作をバッチ処理するようになりました。
● LND #11151は、インバウンドのチャネルを受け入れる際に、過剰なコミットメントの手数料率と不十分な初期残高のチェックを追加しました。LNDは、 3ブロックの推定値の10倍と100 sat/vbyteのいずれか大きい方を上回る手数料率の提案を拒否するようになりました。また、BOLT2の初期リザーブのルールを適用し、それとは別に、どちらの当事者の初期残高もその当事者が維持すべきリザーブを超えていないチャネルを拒否します。コミットメントの手数料はチャネルの開設者が支払いますが、過剰な手数料は開設者の使用可能な残高を消費する可能性があり、開設中に受信者の保留中チャネルのキャパシティを浪費させ、ファンディングトランザクションが承認されると使用できないチャネルが残ることになります。これは、ニュースレター #429で取り上げた最低手数料率のチェックを補完するものです。
● Rust Bitcoin #7067は、Taprootの署名ハッシュ（sighash）のヘルパーを拡張し、オプションのannexと、スクリプトパスによる支払いの場合は署名チェックの前に最後に実行されたOP_CODESEPARATORのopcode位置を受け付けるようにしました。どちらも署名がコミットするメッセージに影響します。これまでは、これらの便利な関数はannexがなく、 OP_CODESEPARATORも実行されていないことを前提としていたため、そのような支払いを処理する呼び出し元は、誤ったダイジェストの生成を避けるためにより汎用的なsighash関数を使用する必要がありました。ヘルパーはこれらの値を直接受け付けるようになりましたが、セパレーターの位置は引き続き呼び出し元が決定する必要があります。 annexがなく、OP_CODESEPARATORも実行されていない支払いを処理する呼び出し元は、新しい引数にNoneを渡すことで以前の動作を維持できます。レガシーおよびsegwit v0の支払いに関連するsighash APIの変更については、ニュースレター #427をご覧ください。

もっと知りたいですか？

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