BIP 360 — マークルルートへの支払い（P2MR） - ビットコイン・インスティテュート

BIP: 360
  Layer: Consensus (soft fork)
  Title: Pay-to-Merkle-Root (P2MR)
  Authors: Hunter Beast <hunter@surmount.systems>
           Ethan Heilman <ethan.r.heilman@gmail.com>
           Isabel Foxen Duke <isabel.duke@gmail.com>
  Status: Draft
  Type: Specification
  Assigned: 2024-12-18
  License: BSD-3-Clause
  Version: 0.11.0
  Requires: 340, 341, 342

イントロダクション

概要

本文書は、ソフトフォークによる新しい出力型 Pay-to-Merkle-Root (P2MR) を提案する。P2MR 出力は P2TR (Pay-to-Taproot) 出力とほぼ同等の機能で動作するが、キーパス使用が除かれている。

この変更により、P2MR 出力は開発者に対して、以下の特性を備えた形でスクリプトツリーとタップスクリプトを使用することを可能にする。

暗号学的に重要な量子コンピューター (CRQC) による長期暴露攻撃に耐性がある。
ビットコインで用いられている楕円曲線暗号 (ECC) を将来的に危殆化させる可能性のある暗号解析手法に耐性がある。

なお、提案する P2MR 出力は楕円曲線暗号に対する「長期暴露攻撃」にのみ耐性があることに留意されたい。すなわち、使用トランザクションの確認に必要な時間よりも長く公開鍵が暴露された場合の攻撃に対する耐性である。

トランザクションが確認待ちでメンプールに置かれている間に暴露される公開鍵から秘密鍵を復元する攻撃 (いわゆる「短期暴露攻撃」) を含む、より洗練された量子攻撃からの防護には、ビットコインへのポスト量子署名の導入が必要になる可能性がある。我々はこの方向を将来的に検討する価値があると考えており、さらなる研究の上で別の提案を出すことを意図している。

本文書はさらに「長期暴露」攻撃と「短期暴露」攻撃、その他の新しい用語を用語集に定義する。

著作権

本文書は 3 条項 BSD ライセンスの下でライセンスされている。

動機

暗号学的に重要な量子コンピューター (CRQC) がビットコインにもたらす主要な脅威は、ビットコインで用いられるデジタル署名を支える根幹の暗号学的仮定を破る可能性にある。暗号学的に重要な量子コンピューターは、現時点では量子物理学上の特性によってのみ緩く定義される対象である。本 BIP およびビットコインの文脈においては、ショアのアルゴリズムを効率的に実行できるだけの論理キュービットをコヒーレントに保つアーキテクチャを備えた、ハードウェア非依存のコンピューターと理解できる。より具体的には、ショアのアルゴリズム (https://arxiv.org/pdf/quant-ph/0301141)によって CRQC は離散対数問題 (DLP) を古典的手法と比較して指数関数的に高速に解くことができる。ショアのアルゴリズムは、256 ビットの楕円曲線公開鍵を破るのに 10^8 回の演算を要するとされる。これにより、公開鍵から秘密鍵を導出することが可能となる ― ここでは本過程を量子鍵復元と呼ぶ。すなわち、ショアのアルゴリズムを用いて公開鍵から秘密鍵を導出することを意味する。 CRQC が将来的にいつ実現可能となるか、あるいは実現するか自体が不明である一方、この水準の防護に関心のある利用者向けに、量子耐性のあるスクリプトツリー出力型の追加を提案する。

これまでの限定的な機能性を踏まえて量子コンピューターがビットコインにもたらす潜在的脅威を一蹴する向きもあるが、政府・企業・一部の既存および潜在的ビットコイン利用者を含む他の主体は、その進歩の可能性を懸念している。例えば Commercial National Security Algorithm Suite (CNSA) 2.0 は、ソフトウェアおよびネットワーク機器を 2030 年までにポスト量子方式へ更新し、ブラウザーおよびオペレーティングシステムを 2033 年までに完全に更新することを義務付けている。さらに NIST IR 8547 によれば、楕円曲線暗号 (ECC) は 2035 年以降、米国連邦政府内で使用を禁止する計画である (ハイブリッド暗号、すなわち ECC とポスト量子アルゴリズムを併用する場合に限り例外が認められる)。こうした義務付けは一部の ECC 利用者の懸念を呼び起こしており、そこには念には念を入れて備えたいビットコイン利用者も含まれている。

最も楽観的な場合、すなわち量子コンピューターが ECC に対して重大なリスクをもたらすことが決してないとしても、量子の進歩の可能性そのものがビットコインネットワークへの採用や広範な信頼に影響を与えうると我々は理解している。言い換えれば、CRQC の実現性とは独立に、利用者の量子コンピューターへの懸念に対処する価値があると考えている。これらの懸念を踏まえると、量子耐性のある形でビットコインを使用する選択肢を生む、単純で低リスクの変更を検討する価値があると我々は考える。

この取り組みの保守的な第一歩として、量子耐性のある形で使用できるスクリプトツリー出力である Pay-to-Merkle-Root (P2MR) を提案する。

長期暴露攻撃 vs 短期暴露攻撃

明確を期すために述べると、本提案は特にタップスクリプトとスクリプトツリーをサポートする出力に対する長期暴露攻撃のリスクを低減するものである。P2SH のように長期暴露攻撃に対して安全な他のビットコイン出力型もあるが、Taproot はそうではなく、また Taproot は現時点で有効化された出力型のうちタップスクリプトとスクリプトツリーをサポートする唯一のものである。

長期暴露攻撃は、公開された公開鍵や使用済み出力のスクリプトなど、暴露されたブロックチェーンデータに対して行われる攻撃である。これはビットコインに対して最初に可能になる量子攻撃である可能性が高い。攻撃者は脆弱な鍵が暴露されている期間と同じだけ ― つまり潤沢な時間 ― を量子鍵復元の実行に充てられるためである。

一方、短期暴露攻撃は、トランザクションがメンプール内で未確認である比較的短い時間内に行わなければならないため、より高速な量子コンピューターを必要とする。

ビットコイン出力は一般に短期暴露攻撃に対して脆弱である。なぜなら、ほとんどのビットコイントランザクションは使用時に対応する公開鍵を開示する必要があるためである。出力を短期暴露攻撃から完全に防護するには、ポスト量子署名方式の使用が必要になる可能性がある。

公開鍵に対する長期暴露攻撃はビットコインに対する最初の量子由来の脅威となる可能性が高いため、量子コンピューターの潜在的脅威に対してビットコインを堅牢化するための第一歩として、長期暴露攻撃に耐性のあるスクリプトツリー出力を提案する。

以下の出力型の一覧は、それぞれの長期暴露攻撃に対する脆弱性を示す。

型	脆弱	接頭辞	例
P2PK	Yes	Varies	02103203b768951584fe9af6d9d9e6ff26a5f76e453212f19ba163774182ab8057f3eac
P2PKH	No*	1	1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
P2MS	Yes	Varies	52410496ec45f878b62c46c4be8e336dff7cc58df9b502178cc240e…
P2SH	No*	3	3FkhZo7sGNue153xhgqPBcUaBsYvJW6tTx
P2WPKH	No*	bc1q	bc1qsnh5ktku9ztqeqfr89yrqjd05eh58nah884mku
P2WSH	No*	bc1q	bc1qvhu3557twysq2ldn6dut6rmaj3qk04p60h9l79wk4lzgy0ca8mfsnffz65
P2TR	Yes	bc1p	bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u
P2MR	No*	bc1z	bc1zzmv50jjgxxhww6ve4g5zpewrkjqhr06fyujpm20tuezdlxmfphcqfc80ve

以下の出力型は本質的に長期暴露攻撃に対して脆弱である。

P2PK 出力 (例: サトシのコイン、CPU マイナー)
再使用された出力*
Taproot 出力 (bc1p で始まる)
P2PKH、P2SH、P2WPKH、P2WSH、および P2MR 出力にある資金は、そのスクリプトが公開鍵を開示した時点で長期暴露量子攻撃に対して脆弱になりうる。

注: 拡張公開鍵 (一般に「xpubs」として知られる) およびウォレットディスクリプターも、量子脆弱な公開鍵情報を開示する。量子攻撃ベクトルのさらなる明確化については、用語集を参照されたい。

設計

Pay-to-Merkle-Root (P2MR) は、スクリプトツリーのルートにコミットする新しい出力型として提案されるものである。P2TR (Pay-to-Taproot) 出力とほぼ同等の機能で動作するが、量子脆弱なキーパス使用が除かれている。

言い換えれば、P2MR 出力は内部鍵にコミットせずにスクリプトツリーのマークルルートにコミットする。ただし、コミットされるスクリプトには鍵または鍵ハッシュが含まれていてもよい。

この出力型は、利用者に対して長期暴露量子攻撃からの防護を提供すると同時に、将来的にポスト量子署名が採用された場合に利用可能な実用的な出力型として設計されている。

P2MR 出力にはキーパス使用がないため、Taproot 内部鍵を省略する。代わりに、P2MR 出力は BIP 341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) で定義されるスクリプトツリーの 32 バイトのルートを、以下に示すようにタグ「TapBranch」でハッシュ化したものを含む。

P2MR スクリプトツリールート、scriptPubKey、ウィットネスの構築

P2MR 出力を構築するには、BIP 341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) で示される手順に従って、スクリプトリーフのマークルルートに相当する最終 tapbranch ハッシュを計算する。ただし、(P2TR 出力の場合のように) マークルツリーのルートで内部鍵をツイークするのではなく、P2MR 出力は「TapBranch」でタグ付けされた最終 tapbranch ハッシュのみにコミットする。

D = tagged_hash("TapLeaf", bytes([leaf_version]) + ser_script(script))
CD = tagged_hash("TapBranch", C + D)
CDE = tagged_hash("TapBranch", CD + E)
ABCDE = tagged_hash("TapBranch", AB + CDE)

P2MR インプットウィットネスは以下を提供する。

initial stack element 0,
...,
initial stack element N,
leaf script,
control block = [control byte, 32*m byte Merkle path] # m is the depth of the script in the Merkle tree

P2MR の初期スタック要素は P2TR スクリプトパス使用と同じ規則に従う。すなわち、リーフスクリプトによって評価される要素をスタックに置く。

コントロールブロックは 1 + 32 * m バイトの配列であり、最初のバイトがコントロールバイト、続く 32 * m バイトがリーフスクリプトへのマークルパスである。コントロールバイトはリーフバージョンの指定に用いられる 7 ビットを含め、P2TR コントロールブロック内のコントロールバイトと同じである。P2MR にはキーパス使用がないため、コントロールバイトのパリティビットは常に 1 である。P2TR とは異なり、P2MR では公開鍵は不要であるためコントロールブロックから省略する。ウィットネス内のオプショナルな annex についてはサポートを維持する (詳細は下記の仕様セクションを参照)。

根拠

P2MR 出力型の設計は以下の意図に導かれている。

ネットワークへの変更を最小化する。既存のビットコインコードを再利用し、可能な限り既存のソフトウェア挙動・ワークフロー・利用者の期待・互換性を保存すべきである。

P2MR は既にビットコインに存在する実戦で鍛えられた P2TR、タップリーフ、タップスクリプトのコードを活用し、既存のコードを再利用できるウォレット・取引所・ライブラリの実装負担を軽減する。この手法は複雑性を抑え、実装上のリスクを最小化する。

将来的にポスト量子署名統合を追加する場合に備え、可能な限り安全な経路を構築する。

重要な点として、我々はタップスクリプトをサポートする出力型、すなわちスクリプトツリー出力を提案しており、それが長期暴露攻撃に耐性を持つ。一部の既存の出力型は既に長期暴露攻撃に耐性を持つ (例: P2WSH) ものの、それらのいずれもタップスクリプトをサポートしない ― タップスクリプトはポスト量子署名オペコードの実用的な実装に必要となる可能性のある機能である。

例えば P2WSH はタップスクリプトをサポートしないため、ビットコインへポスト量子 OP_CHECKSIG オペコードを統合する上で決定的に重要となる OP_SUCCESSx オペコード更新経路もサポートしない。OP_SUCCESSx はタップスクリプトを更新する機構である。

量子コンピューターの進展に応じて反復的に進められる、量子耐性機能の段階的統合を促進する。この手法は、潜在的脅威への過剰反応を避けつつ、現在の脅威水準への即応性を促す。

我々は将来的なポスト量子署名の統合を視野に入れて P2MR を設計しており、CRQC がまだ初期段階にある間により複雑な変更を提案しないようにしている。

P2MR のトレードオフ

P2TR 出力 (およびキーパス使用) はそれを利用したい人々のために選択肢として残り続けるが、量子耐性のためにキーパス使用を無効化する P2MR 出力の使用に関するトレードオフを明確に伝えることを目指す。

P2MR 使用のウィットネスは、P2TR キーパス使用のウィットネスよりも常に大きい。これは P2TR キーパス使用ではウィットネスにシュノア署名のみが必要なのに対し、P2MR ではウィットネスに選択されたリーフスクリプト、初期スタック、そしてコントロールバイトとマークルパス (もしあれば) からなるコントロールブロックを含めなければならないためである。

ただし、P2MR 使用のウィットネスは同等の P2TR スクリプトパス使用のウィットネスよりも常に小さくなる。これは、P2MR ではコントロールブロック内で公開する必要のある内部鍵がもはや存在しないためである。出力型のトランザクションサイズのより完全な比較については、本提案の後段の「トランザクションサイズと手数料」セクションを参照されたい。

さらに、P2MR と P2TR を比較した場合のプライバシー上のトレードオフがある。P2MR 出力はスクリプトパス使用でしか使用できないため、利用者は P2MR 出力を使用するたびにスクリプトツリーへの使用を開示することになる。P2TR ではキーパス使用で出力を使用する場合、スクリプトパス使用が存在するかどうかを開示しない。このトレードオフは P2TR キーパス使用と P2MR スクリプトパス使用を比較した場合にのみ存在する。両者ともスクリプトパス使用である場合、P2TR と P2MR は同じ水準のプライバシーを提供する。

注: P2MR と P2TR はどちらも、未使用のスクリプトパスを開示しないため、P2SH BIP 16 (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) よりも高いスクリプトプライバシーを提供する。

仕様

Pay-to-Merkle-Root (P2MR) 出力構造を以下のように定義する。

P2MR 出力は (BIP 341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) で定義される) P2TR 出力に類似する。ただし P2TR 出力とは異なり、内部鍵と tap ツイーク手順を省略することで、量子耐性のためにキーパス使用を無効化する。すなわち P2MR 出力は、SegWit バージョン 2 バイトに続いてウィットネスプログラムとしてスクリプトツリーのマークルルートが配置されたものである。

アドレス形式

P2MR 出力は SegWit バージョン 2 を用いるため、メインネットのアドレスは BIP 173 (https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) に従い bc1z で始まる。Bech32m エンコーディングはバージョン 2 をプレフィックス z に対応付ける。

P2MR アドレスの例:

bc1zzmv50jjgxxhww6ve4g5zpewrkjqhr06fyujpm20tuezdlxmfphcqfc80ve

これは 32 バイトのスクリプトツリーのマークルルートにコミットする。

ScriptPubKey

P2MR 出力の scriptPubKey は次の通り。

OP_2 OP_PUSHBYTES_32 <hash>

ここで:

OP_2 は SegWit バージョン 2 を示す。
<hash> はスクリプトツリーの 32 バイトのマークルルートである。

スクリプト検証

P2MR 出力は (BIP 141 (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) を参照) バージョン 2 と 32 バイトのウィットネスプログラムを持つネイティブ SegWit 出力である。比較のために、BIP 341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) のスクリプト検証セクションから可能な限り逐語的に文言を借用している。

q を、スクリプトツリーのマークルルートを表すウィットネスプログラム (scriptPubKey の 2 番目のプッシュ) を格納する 32 バイトの配列とする。
ウィットネススタックの要素が 2 つ未満であれば失敗する。
ウィットネススタックがちょうど 2 要素を持ち、最後の要素の最初のバイトが 0x50 であれば失敗する。
ウィットネス要素が少なくとも 3 つあり、最後の要素の最初のバイトが 0x50 である場合、その最後の要素を annex a と呼び、ウィットネススタックから除去する。annex (またはその不在) は常に署名で保護されトランザクション重みに寄与するが、それ以外は P2MR 検証中は無視される。
残りのウィットネス要素は少なくとも 2 つでなければならない。
- 末尾から 2 番目のスタック要素を s、すなわちスクリプトと呼ぶ (BIP 341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) で定義)。
- 最後のスタック要素はコントロールブロック c と呼ばれ、長さが 1 + 32 * m でなければならない (m は 0 以上 128 以下の整数)。そうした長さでなければ失敗する。
- v = c[0] & 0xfe を リーフバージョン とする (BIP 341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) で定義)。リーフバージョン のエンコーディング互換性を維持するため、c[0] の最後のビットは未使用であり 1 でなければならない。なぜ c[0] の最後のビットを 1 に設定するのか? P2TR と P2MR の双方について、リーフバージョン を c[0] & 0xfe ではなく c[0] としてデシリアライズする欠陥実装を考える。P2MR 出力に対して検査を行い最後のビットが 1 であることを要求すれば、このデシリアライズの誤りは即座にエラーを引き起こす。
- k₀ = hash_TapLeaf(v || compact_size(size of s) || s) とする。これを tapleaf ハッシュ とも呼ぶ。
- j を [0,1,…,m-1] について:
  - e_j = c[1+32j:33+32j] とする。
  - k_j+1 を k_j < e_j (辞書式順序) かどうかに応じて次のように定める。
    - k_j < e_j の場合: k_j+1 = hash_TapBranch(k_j || e_j)。
    - k_j ≥ e_j の場合: k_j+1 = hash_TapBranch(e_j || k_j)。
- r = k_m とする。
- q ≠ r であれば失敗する。
- スクリプト s、コントロールブロック c、および存在する場合は annex a を除いたウィットネススタック要素を初期スタックとして、BIP 342 で指定されるスクリプト規則に従ってスクリプトを実行する。これは将来のリーフバージョン (0xC0 以外) について実行が成功しなければならないことを意味する。

上記の手順は BIP 341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) のスクリプトパス使用のロジックに次の変更を加えたものである。

ウィットネスプログラムはツイークされた公開鍵ではなく、スクリプトツリーのマークルルートである。これは BIP 341 のスクリプトパス検証へ直接進むことを意味する。
スクリプトツリーのマークルルート r を計算し、ウィットネスプログラム q と直接比較する。
コントロールブロックは 33 + 32 * m バイトではなく 1 + 32 * m バイトである。

共通署名メッセージの構築

P2MR 出力の共通署名メッセージ (https://learnmeabitcoin.com/technical/upgrades/taproot/#common-signature-message)の構築は、[[bip-0342.mediawiki#user-content-Common_Signature_Message_Extension|BIP 342 共通署名メッセージ]] で定義される手順とまったく同じである。

BIP 141 との互換性

SegWit トランザクション構造とバージョニングに準拠することで、P2MR 出力は既存のトランザクション処理規則と互換性を持つ。SegWit バージョン 2 を認識しないノードはこれらの出力を anyone-can-spend として扱うが、一般にそのようなトランザクションをリレーまたはマイニングしない。

トランザクションサイズと手数料

すべての P2MR と P2TR 出力は常に同じサイズである。P2MR インプットは、P2TR の場合のキーパス使用 vs スクリプトパス使用の選択に応じて、同等の P2TR インプットよりわずかに大きいか小さくなりうる。各ケースを検討する。

P2TR キーパス使用との比較

P2TR 出力がキーパス使用で使用される場合、P2MR ウィットネスは P2TR ウィットネスより大きくなる。P2TR キーパス使用のウィットネスは単に署名のみである。P2MR の量子耐性は P2TR キーパス使用を除去することで得られる。すべての P2MR 使用は P2TR スクリプトパス使用に相当するため、スクリプト、その入力スタック、コントロールブロックを必要とする。結果として、P2MR は量子耐性を獲得する代わりに P2TR キーパス使用のこのサイズ上の利点を失う。スクリプトツリーに単一のリーフスクリプトしかない場合、コントロールブロックにマークルパスは不要となり、コントロールブロックの最小サイズは 1 バイトになる。

深さ 0 のツリーの P2MR ウィットネス (103 バイト):

[count] (1 byte), # Number of elements in the witness
[size] signature (1 + 64 bytes = 65 bytes),
leaf script = [size] [OP_PUSHBYTES_32, 32-byte public key, OP_CHECKSIG] (1 + 1 + 32 + 1 bytes = 35 bytes),
control block = [size] [control byte] [merkle path (empty)] (1 + 1 + 0 bytes = 2 bytes)

P2TR キーパス使用のウィットネス (66 バイト):

[count] (1 byte), # Number of elements in the witness
[size] signature (1 + 64 bytes = 65 bytes)

したがって、P2MR ウィットネスは P2TR キーパス使用のウィットネスより 103 - 66 = 37 バイト大きい。

マークルツリーが単一のリーフより多くを持つ場合、マークルパスをコントロールブロックに含めなければならず、サイズが 32 * m バイト増加する (m はマークルツリーの深さ)。スクリプトツリーは異なる深さのリーフスクリプトをサポートするが、ここでは各リーフが同じ深さになるようにマークルツリーが構築されていると仮定する。この場合、ウィットネスは P2TR キーパス使用のウィットネスより 37 + 32 * m バイト大きくなる。m >= 8 の場合、コンパクトサイズは 1 バイトではなく 3 バイトを用いる。

P2MR ウィットネス (103 + 32 * m バイト):

[count] (1 byte), # Number of elements in the witness
[size] signature (64 + 1 bytes = 65 bytes),
leaf script = [size] [OP_PUSHBYTES_32, 32-byte public key, OP_CHECKSIG] (34 + 1 bytes = 35 bytes),
control block = [size] [control byte] [Merkle path] (1 + 1 + 32*m = 2 + 32*m bytes)

P2TR スクリプトパス使用との比較

P2MR ウィットネスは、同等の P2TR スクリプトパス使用のウィットネスより小さくなる。これは、出力をアンロックして使用するために P2MR がコントロールブロックに内部公開鍵を含める必要がないためである。このため、P2MR ウィットネスは同等の P2TR スクリプトパス使用のウィットネスより常に 32 バイト小さくなる。

性能への影響

P2MR は P2TR スクリプトパス使用よりわずかに計算性能が高い。これは、P2MR 出力の使用に必要な演算が、P2TR 出力に対するスクリプトパス使用に必要な演算の真部分集合になっているためである。

後方互換性

SegWit バージョン 2 と P2MR に対応していない古いウォレットおよびノードは、これらの出力を理解しない。BIP 350 (https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) に従い、古いウォレットでも SegWit バージョン 2 出力に対して資金を使用できるはずである。利用者は、P2MR 出力を受け取り、P2MR 出力を用いるトランザクションを検証するために、更新されたウォレットとノードを使用していることを確認するべきである。P2MR はタップスクリプトと完全に互換性があり、既存のタップスクリプトプログラムを修正なしで P2MR 出力に使用できる。P2MR は新しいリーフバージョンを持つ将来のスクリプトもサポート可能である。

セキュリティ

P2MR 出力は P2TR 出力と同じタップスクリプト機能を提供するが、量子脆弱なキーパス使用が除かれている。これらの出力型の類似性により、利用者は長期暴露量子攻撃への防護のために、スクリプトツリーを P2TR 出力から P2MR 出力へ容易に移行できる。P2TR キーパス使用のみをサポートするウォレットはスクリプトツリー使用へ移行する必要があるが、単純な OP_CHECKSIG リーフスクリプトへの移行のみで足りるため、これは率直な移行である。

長期暴露量子攻撃からの防護はビットコインでのポスト量子署名の有効化に依存しないが、利用者が公開鍵再使用やその他の安全でない慣行を通じて攻撃者に公開鍵を暴露しないことを必要とする。

P2MR は 256 ビットのハッシュ出力を用いており、128 ビットの衝突耐性と 256 ビットのプリイメージ耐性を提供する。これは BIP 141 (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) で規定される P2WSH と同じ水準のセキュリティであり、P2WSH もまた 256 ビットのハッシュ出力を用いている。

P2MR 単独では短期暴露量子攻撃から防護しないが、これらの攻撃は将来的なポスト量子署名の有効化によって緩和できる。

P2MR と組み合わせることで、ポスト量子署名方式は短期暴露攻撃からの防護を含む包括的な量子耐性を P2MR 出力に提供できる。

ただし、長期暴露量子攻撃からの防護のみであっても過小評価すべきではない。初期の CRQC が短期暴露攻撃を実行できるほど高速である可能性は低く、そのため長期暴露攻撃への備えの時間的緊急性はより高い。

ポスト量子署名方式のセキュリティ上の考慮事項

本提案にはポスト量子署名方式の導入は含まれないが、その可能性に関連するセキュリティ上の考慮事項について論じる価値があると考える。

量子耐性のある署名アルゴリズム (例: ML-DSA や SLH-DSA) はそれぞれ異なる水準の防護を提供するため、使用前に精査されるべきである。我々は現在、ビットコインへのポスト量子署名の提案候補を研究しており、他の研究者にもこの研究に参加することを奨励している。

冗長性のために複数のポスト量子署名を導入する可能性も想定している。追加的複雑性のリスクと、署名型の冗長性の便益とのバランスをとることが、ここでの課題となる。

テストベクトルと参照コード

P2MR UTXO 作成のためのテストベクトルデータはここ (https://github.com/bitcoin/bips/blob/master/bip-0360/ref-impl/common/tests/data/P2MR_construction.json)で見つけられる。

これらのテストベクトルは BIP 341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) (Taproot) のテストベクトルを基にしている。重要な相違点として、P2MR テストベクトルにはキーパス使用のシナリオが含まれない。

Rust 実装 (https://github.com/bitcoin/bips/tree/master/bip-0360/ref-impl/rust)と Python 実装 (https://github.com/bitcoin/bips/tree/master/bip-0360/ref-impl/python)のテストベクトルも含まれる。これらのテストの一つは、P2MR UTXO を使用するのに secp256k1 署名を必要とするタップスクリプトを実演する (この Taproot スクリプトパス使用の例 (https://learnmeabitcoin.com/technical/upgrades/taproot/#example-3-script-path-spend-signature)が提供する極めて有用な例の一つをモデルとしている)。BIP 341 のテストベクトルと同様に、すべての署名は全てゼロ (0x0000…0000) の BIP 340 (https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) 補助乱数配列で作成されている。

暗号通貨における量子脆弱性への対処の他の手法

比較のために述べると、イーサリアムの量子脆弱性に対する Vitalik Buterin の提案する解決策 (https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901)は本 BIP の手法とはかなり異なることに留意されたい。

彼の計画は、チェーンのハードフォークと、十分な量の盗難が発生した後のすべてのブロックの巻き戻し、および BIP 32 シードに基づく STARK を署名時の真正な秘密として用いることを含む。我々はいかなる種類のロールバックもビットコインにとって受け入れがたい手法であり、実装も非現実的であろうと考えている。

ただし、ジェイムソン・ロップ他が QBIP (https://qbip.org/) で提案するようにコミュニティが脆弱なコインを焼却することを選択した場合、(量子耐性を持つ) STARK の使用は外部の秘密鍵へのアクセスを証明する手段として有用となりうると我々は考える。

コインの焼却に関する議論、および脆弱なコインの量子による回収によって引き起こされる潜在的な供給ショックを遅らせるための他の試みは、本提案の範囲外である。ただし、我々のチームのメンバーはこの懸念に対処するために別途 Hourglass (https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki) を提案しており、この主題に関する研究を継続している。

結論

本提案では、量子コンピューティングの進歩の可能性に対して「備えあれば憂いなし (prepared not scared)」の姿勢を採り、希望するビットコイン利用者に対してより高い防護の選択肢を提供する。本 BIP は特定の量子コンピューティングのタイムラインについて立場を取るのではなく、それぞれのタイムライン見積もりに応じてこのリスクを緩和したい利用者に対し、柔軟かつ目立たない選択肢を提案するものである。

これは少なくとも 2012 年以降ビットコインフォーラム (https://bitcointalk.org/index.php?topic=133425.0)でかなりの規則性をもって議論されてきた問題であり、量子防護の強化に対する利用者の需要が明らかに存在する。

用語集

量子鍵復元 (Quantum Key Recovery)

楕円曲線暗号 (ECC) における公開鍵からの秘密鍵の導出。離散対数問題 (DLP) を解くことによって可能となる。

ショアのアルゴリズムは 1994 年に Peter Shor によって考案された量子アルゴリズムであり、離散対数問題を効率的に解く ― 将来的に暗号学的に重要な量子コンピューター (CRQC) が実現可能になることで実用化される可能性がある。

長期暴露攻撃 (Long Exposure Attacks)

長期間にわたって暴露された公開鍵から秘密鍵を導出しようとする試み。すなわち、確認待ちの間に公開鍵が一般にメンプールで暴露される時間枠よりも長い期間の暴露が対象となる。

長期暴露攻撃は、資金が出力に残っている限り、攻撃者に量子鍵復元を実行する無制限の時間を与える。ウォレット衛生の不備 (例: アドレス再使用) や公開鍵が暴露された出力 (例: P2TR 出力) の使用は、長期暴露攻撃に対する脆弱性を増大させる。

短期暴露攻撃 (Short Exposure Attacks)

資金がメンプール内で未確認である短い期間に公開鍵から秘密鍵を導出しようとする試み。これらの攻撃は、使用に際して公開鍵を開示することが必要であるため、ウォレット衛生によって防ぐことはできない。

短期暴露攻撃に対する防護にはポスト量子署名方式が必要となる可能性がある。ただし、これらの攻撃の実行には長期暴露攻撃を実行できるものより高速な CRQC が必要であり、そのため近い将来においては長期暴露攻撃よりも低リスクと見なされる。

スクリプトツリー出力型 (Script Tree Output Type)

スクリプトツリー出力型は、リーフスクリプトから構成されるスクリプトツリーをサポートする出力型のカテゴリーである。スクリプトツリー出力型はタップスクリプトをサポートし、スクリプトツリーのリーフスクリプトとして使用可能であれば、ビットコインに追加される将来の新しいスクリプト言語もサポートする。Pay-to-Merkle-Root (P2MR) が有効化されれば、P2MR はビットコインにおける 2 番目のスクリプトツリー出力型となる (もう一方は Pay-to-Taproot (P2TR))。

Pay-to-Merkle-Root (P2MR)

Pay-to-Taproot (P2TR) に類似するスクリプトツリー出力型。ただし量子脆弱なキーパス使用が除かれている。

脚注

変更履歴

本 BIP の更新を実装者が理解しやすくするため、実質的な変更の一覧を保持する。

0.11.0 (2026-02-10) - BIP 名称を Pay-to-Tapscript-Hash (P2TSH) から Pay-to-Merkle-Root (P2MR) へ変更。
0.10.3 (2026-02-06) - タップスクリプトネイティブ出力型をスクリプトツリー出力型へ改名。
0.10.2 (2026-01-23) - 検証のバグ修正、軽微なレビューコメントの反映、および [[bip-0003.md|BIP 3]] 規約の採用。
0.10.1 (2026-01-21) - 用語と明確性の改善、レビューフィードバックへの対応。
0.10.0 (2025-09-17) - 明確性のために BIP を書き直し、P2QRH から P2TSH へ改名。
0.9.0 (2025-07-20) - ウィットネスバージョンを 3 から 2 に変更。
0.8.0 (2025-07-07) - P2QRH は脆弱なキーパス使用を除いた P2TR となった。サポートするポスト量子署名アルゴリズム数を 3 から 2 に削減。ポスト量子署名アルゴリズムのサポートはオペコードまたはリーフバージョン経由で追加されるようになった。
0.7.0 (2025-03-18) - コミットメント構造と証明構造の不整合を修正。マークルツリーコミットメントからソート済みベクトルハッシュコミットメントへ変更。ディスクリプター形式を更新。
0.6.2 (2025-03-12) - 各アルゴリズムの検証時間を追加。256 から 128 へ (NIST V から NIST I へ)。鍵型ビットマスクを追加。マルチシグの意味論を明確化。
0.6.1 (2025-02-23) - レビューによる明確化点を追加。リンク切れを更新。
0.6.0 (2025-01-20) - 性能上の重大な懸念のため SQIsign を検討対象から除外。ブロック再編成攻撃の用語との混同を避けるため、長距離攻撃 (long range attack) から長期暴露 (long exposure) へ用語を変更。
0.5.1 (2024-12-18) - BIP 番号を割り当て。
0.5.0 (2024-12-13) - 証明コミットメントにマークルツリーを使用するよう更新。LR と SR の量子攻撃シナリオを更新。
0.4.0 (2024-12-01) - 証明構造とパースに関する詳細を追加。
0.3.0 (2024-10-21) - NIST 承認とサイズ制約のため XMSS を CRYSTALS-Dilithium に置き換え。
0.2.2 (2024-09-30) - ECC vs PoW セクションをリファクタ。quitness を証明に差し替え。
0.2.1 (2024-09-29) - PoW セクションを更新して部分プリイメージを含めた。
0.2.0 (2024-09-28) - PQC 表に Winternitz、XMSS 署名、およびセキュリティ仮定の型を追加。NIST Level I 表を省略。使用スクリプト仕様を追加。公開鍵開示シナリオ表を追加。
0.1.0 (2024-09-27) - 初稿提案。

謝辞

本文書は、シュノア署名を用いた P2TR (Taproot) 出力型の設計を導入した BIP 341 (https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) に着想を得ている。

共著者として参加し、本 BIP を既存のビットコイン設計とはるかに整合的なものへと変えてくれたイーサン・ハイルマンに大いに感謝する。さらに、思慮深い編集と本提案の文章の多くを練り上げてくれた、我々の直近の共著者イザベル・フォクセン・デュークにも深く感謝する。同様に、貢献の時間を割いてくれた Anduro Quantum Working Group のメンバー Jeff Bride、Michael Casey、notmike にも恩義を感じている。

レビューと貢献の時間を割いてくれた Jon Atack、Adam Borcany、Ava Chow、Kyle Crews、Pierre-Luc Dallaire-Demers、D++、Mark Erhardt、ジェイムソン・ロップ、Antoine Riard、Armin Sabouri、Vojtěch Strnad、Guy Swann、Joey Yandle にも感謝する。

なお残る不正確な点があれば、その責任は著者にのみある。

BIP 360 — マークルルートへの支払い（P2MR）