用語集 / アドレスと鍵
BIP-86の導出
- BIP-86の導出とは？
- BIP-86の導出では、単一鍵のTaprootアカウントをm/86'/0'/0'に配置し、その後に導出した各鍵をそれ自体のハッシュで調整（tweak）するため、アドレスは使用不可能なスクリプトパスにコミットします。
BIP-86で規定されています。
BIP-86は、単一署名者が保有するTaproot出力を扱うウォレットを対象とし、BIP-44のアカウント構造をpurpose階層に86'を置いて再利用します。BIP-49とBIP-84も第二のアドレス生成段階を定義していますが、鍵そのものを変更するのはBIP-86だけです。アドレス内の32バイトの値は、導出した鍵そのものに、その鍵自身のハッシュによる調整（tweak）を加えたものです。BIP-84のみをスキャンするソフトウェアにシードフレーズを復元すると、bc1p残高はゼロと表示されます。
仕組み
BIP-86の導出は2つの段階で行われ、鍵ツリーをたどるという見慣れた手順なのは最初の段階だけです。
第1段階はパスです。テンプレートはm / purpose' / coin_type' / account' / change / address_indexで、purposeの位置に86'を置き、それより下の各階層は変更せずに使用します。したがって、最初のビットコインアカウントはm/86'/0'/0'に、その最初の受信用の鍵はm/86'/0'/0'/0/0に位置します。
第2段階が、BIP-86が先行する規格と袂を分かつところです。BIP-49とBIP-84も第二の段階を定義していますが、それらは導出した鍵をスクリプトで包むだけで、witnessはパスが生成した鍵を依然として明かします。BIP-86は鍵を置き換えます。BIP-86は満たすべき規則についてBIP-341を引用しています。「If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path.」つまり、導出した鍵はlift_xを通じて内部鍵（internal key）として読み取られ、チェーンに届くのは、その内部鍵にint(HashTapTweak(bytes(internal_key)))Gを加えたものです。結果はOP_1の後ろに置かれた単一の32バイトのプッシュで、0x5120に調整済みの鍵を続けて表記し、これを使用するにはscriptSigを空にしたwitness内の署名だけで済みます。
公開されているテストベクターがその隔たりを示しています。m/86'/0'/0'/0/0において、シードから導出される内部鍵はcc8a4bc64d897bddc5fbc2f670f7a8ba0b386779106cf1223c6fc5d7cd6fc115ですが、ネットワークが見る鍵はa60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684cで、bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcrとしてエンコードされます。第2段階を省略する実装は代わりに前者の値を公開するため、同じシードを復元する規格準拠のウォレットが決して見つけられない、もっともらしく見えるアドレスを渡すことになります。
この文書はAva Chowが執筆し、2021年6月22日に割り当てられ、現在はDeployedのステータスを持っています。
どこで見られるか
BIP-86の導出は、どの形式を希望するかを尋ねずにbc1pアドレスを渡す、大半の単一署名ウォレットの背後にあります。Bitcoin Coreはバージョン23.0でディスクリプタウォレットをデフォルトにし、そのバージョンのリリースノートには、新しく作成されたディスクリプタウォレットには自動生成されたtr()ディスクリプタが含まれ、「which allows for creating single key Taproot receiving addresses」と記載されています。
ハードウェアの対応は非常に異なる速度で進みました。当サイトのKeepKeyレビューでは、この機器のTaproot出力対応を2025年2月のファームウェア7.10.0としています。そのため、安価な署名デバイスが、86'のブランチを表示しないシードを保持できる一方で、同じシードフレーズを読み取る別のソフトウェアはそのコインを通常どおり使用できます。
この仕様書は、なぜ固定パスが依然として必要なのかについて、異例なほど率直です。動機のセクションでは「there are now solutions which obviate the need for fixed derivation paths for specific script types」と認めています。これはディスクリプタを指しており、続いてそれが問題を解決しない理由を挙げています。多くのソフトウェアウォレットとハードウェア署名デバイスは依然としてシード単体をバックアップしており、パスやスクリプト種別の記録を併せて持っていません。ディスクリプタはその情報を運びますが、単語リストは運ばないため、代わりにpurpose階層の番号がそれを運びます。
BIP-86の導出vs P2TR
BIP-86の導出はP2TR出力を埋めるための1つのレシピであり、その定義ではありません。P2TRはwitnessバージョン1であり、32バイトの出力鍵をどのようなものでも受け入れます。MuSig2の下で複数の署名者から集約された鍵や、実際に使用可能なスクリプトのツリーにコミットする鍵も含まれます。BIP-86が対象とするのはその空間の中で最も狭いケースです。署名者1人、シード1つ、そして鍵の背後に何も隠れないよう意図的に使用不能にしたスクリプトパスです。BIP-86が生成するすべてのアドレスはP2TR出力であり、P2TRが表現できるものの大半はその範囲の完全な外側にあります。そのため、Taproot対応をうたうウォレットでも、同じアドレス形式をまとったマルチシグやタイムロック付きのブランチを拒否することがあります。