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、エイヴァ・チョウ、Kyle Crews、Pierre-Luc Dallaire-Demers、D++、Mark Erhardt、ジェイムソン・ロップ、Antoine Riard、Armin Sabouri、Vojtěch Strnad、Guy Swann、Joey Yandleにも感謝する。

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

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