ビットコイン(BTC)Taprootアップグレードはブロック709632で有効化もウォレット対応は任意

ウォレットと取引所が直面するbc1p対応の課題

Taprootの選択肢を表示するビットコイン (BTC)のウォレット、そしてそれが生成するbc1pアドレスを受け入れる必要がある取引所やハードウェア署名機器。アップグレードの恩恵が一般利用者に届くかどうかを最終的に決めるのは、この三者である。ビットコインのTaprootはソフトフォークであり、2021年にブロック高709,632でメインネット上で有効化された。Pay-to-Taproot(P2TR)出力を導入し、バージョン1の証人ルールに従う。ただし変更が及ぶのはコインの使い方であって保有資産そのものではない。受け取りは従来どおりBTCであり、独立したTaprootトークンは存在しない。ビットコインの価格や供給スケジュールもこの改修の対象外だ。

このアップグレードは、三つの提案を一つに束ねたものである。BIP 340はsecp256k1曲線上のSchnorr署名を規定する。ビットコインが長く依存してきたECDSAとは異なる代数的構造を持ち、複数当事者による署名プロトコルに向く設計だ。BIP 341はTaproot出力の形式、コミットメント構造、その使用(スペンド)ルールを定める。さらにBIP 342はTapscriptの名称で知られ、これらの出力内でのスクリプト実行ルールを扱う。三者は相互に連動しつつ、記述する階層はそれぞれ異なる。一つの機能として捉えてしまうのは、よくある誤解だ。

アドレス表記では、メインネットのTaproot出力は通常bc1pで始まりBech32mエンコードを使う。一方、ネイティブSegWitのバージョン0アドレスはbc1qで始まりBech32である。両者は同じチェーン上に存在し、第二のビットコインネットワークがあるわけではないし、接頭辞を手動で書き換えて変換できるものでもない。接頭辞の違いは、番号付きのウィットネスバージョンを生み出したSegWitのバージョニング機構に基づくもので、Taprootはそのバージョン1を占有する。有効化後も旧来の出力は有効なままで、移行は任意だ。コインをTaproot出力へ移すにはオンチェーンの手数料が仍然と掛かる。ソフトフォークであるためProof of Workのコンセンサス層にも触れない。互換性対応の焦点がプロトコルではなくウォレット側に置かれる理由はここにある。

Key PathとScript Pathは役割が異なる

Taproot出力の使用方法は二通りあり、この分岐がオンチェーンで観察されるすべてを左右する。Key Pathは、出力の公開鍵に対して検証されるSchnorr署名で支払いを承認する。代替スクリプトについては何も開示されず、MuSig型の協調署名プロトコルのような設計では、複数の参加者が単一所有者のような署名を共同で生成できる。単独の支払いと協調的な支払いを、チェーン分析が確実に区別することはできない。Script Pathは、コミット済みの条件が行使される場面で使われる。支出者は選択したスクリプトを明らかにし、それを満たすデータを提示し、そのスクリプトが出力のコミットメントに属することを証明する。使われなかった分岐は隠れたままだが、行使されたスクリプトとその証明はオンチェーンに現れる。

典型的な用途もそれに応じて分かれる。直接の送金や協調的な複数当事者支払いはKey Pathを通る一方、タイムロックやバックアップ条件、その他の偶発条件はScript Pathに乗る。資金を扱う者にとって重要な誤解が二つある。第一に、マルチシグが有効化と同時に一つの署名へ自動的に縮約されるわけではない。適切な署名プロトコルとウォレットの対応が別途必要で、旧形式のマルチシグコインが変換されることもない。第二に、入力間の署名集約も、このアップグレードが自動的に提供する機能ではない。プライバシーに関しては、Taprootは支出条件の開示を減らし、異なる設計を同一に見えるKey Path支出へ収れんさせられるが、金額、出力構造、トランザクション間の結び付きは公開かつ分析可能なままだ。bc1pアドレスは匿名性の保証ではない。

手数料が一律に下がるわけでもない。コストはトランザクションの仮想サイズ、選択したsat/vBレート、メモリプール上の競合に依存する。Taproot出力の作成に要するデータコストと、その後の使用コストは異なるため、両段階をセットで評価する必要がある。二当事者のカストディ構成を例に取れば、通常時はKey Path経由で協調署名し、タイムロック付きのバックアップスクリプトは事前にコミットしておき、協調が破綻した場合にのみ明示・行使する形が一般的だ。概念は汎用的だが、鍵、スクリプト、バックアップ、署名プロトコルを正しく構築して初めてこの効果は機能する。

ウォレット対応が残す課題

プロトコル側の作業はすでに終わっている。BIP 341が出力、コミットメント、支出ルールを確定し、現行のコンセンサスルールを動かすノード運用者は、追加設定なしにP2TR支出を検証できる。未解決なのは周辺のツール群だ。Taprootアドレスで受け取りができるウォレットが、Key Path支出に署名できるとは限らない。ハードウェア機器や独自のマルチシグ構成は、新経路を安全に使うために作り直しが必要である。Bitcoin DeFiの傘下にまとめられるプロジェクトが築く拡張されたスクリプト設計空間も、後にBitcoin Ordinalsのインスクリプションを載せたバージョン1のウィットネス構造も、いずれもこの同じルール群に立脚する。署名機器、デバイス、入金対応プラットフォームがbc1pで足並みをそろえるまで、採用はオプトインのまま、偏りを伴って進むことになる。