スクリプトパスによる使用

スクリプトパスによる使用は、Taprootのアウトプットから出るための代替ルートであり、誰もが期待した協調署名がついに現れなかったときに用いられます。証明は33バイトのコントロールブロックに、ツリーの各階層ごとにさらに32バイトを加えた形で載り、BIP-341はそのツリーを128階層までに制限しています。このルートを取ると、実際に用いた分岐が公開されるため、実際に依拠したその1つの条件は非公開ではなくなります。

仕組み

スクリプトパスによる使用を検証するノードは、ウィットネスのスタックを後ろから読みます。最後の要素が作業の大部分を担うためです。

その最後の要素がコントロールブロックであり、その長さは何よりも先に検査されます。長さは、0から128までの整数mに対して正確に33 + 32mバイトでなければならず、それ以外の長さは即座に失敗します。BIP-341が上限を128に定めているのは、最適に詰め込まれたツリーが、使用される確率が2^128分の1未満のリーフに対してのみ、より深くなるからです。

最初のバイトは無関係な2つの情報を運びます。0xfeでマスクするとリーフバージョンが得られ、tapscriptのルールでは0xc0です。マスクで取り除いたビットは、アウトプットキーのY座標のパリティであり、使用をバッチ検証できるようにするために存在します。続く32バイトは内部公開鍵であり、協調的な使用に署名したはずの鍵です。その後に続くすべてがマークルパスで、1階層あたり32バイトです。

次にノードはコミットメントを再構築します。リーフバージョンと明らかにされたスクリプトをハッシュしてタップリーフハッシュとし、パスの各要素を順に畳み込みます。方向は決して送信されません。各ステップの2つの32バイトの値はハッシュ前に辞書順で並べ替えられるため、比較が順序を決め、方向ビットは一切送られません。マークルルートと内部鍵からツイークが生成され、スクリプトの実行が許可される前に、ツイークされた鍵がパリティビットを含めてアドレスにある32バイトと一致しなければなりません。

1バイトが、それより前のすべてを変え得ます。ウィットネスが少なくとも2つの要素を持ち、最後の要素が0x50で始まる場合、その要素は検証が始まる前にアネックスとして取り除かれます。BIP-341はこれに何の意味も定義しておらず、含めると"PERMANENT FUND LOSS"につながる可能性があると警告しています。

どこで見られるか

スクリプトパスによる使用は、ブロックエクスプローラー上では、アネックスを除いてウィットネスが複数の要素を持つTaprootの入力として識別できます。

BIP-341自身の実例は、AからEまでの5つのスクリプトからなるツリーです。スクリプトDで使用するとDが公開され、加えて内部鍵と3つのハッシュ（C、E、およびAとBの結合ハッシュ）を保持するコントロールブロックが公開されます。そのコントロールブロックは5つの条件を持つコントラクトで129バイトであり、他の4つのスクリプトは決して公開されません。

証明はまた、何かを明かしてしまいます。BIP-341のセキュリティの節は、明らかにされたリーフの深さがツリーの最小深さを漏らし、それが"suggests specific wallet software that created the output and helps clustering"と指摘しています。BIP-341が示す防御策は、リーフの確率からすればそうでなければ最適となるツリーから外れることです。

同じ節は鍵の再利用についても率直です。鍵は、使用したリーフだけでなく、すべてのリーフを通じて新しくなければなりません。繰り返された分岐は後の証明で繰り返されたハッシュとして再び現れ、鍵を共有するリーフは明らかにされていないスクリプトの総当たり攻撃を安価にするからです。

スクリプトパスによる使用vs Tapscript

スクリプトパスによる使用はルートであり、tapscriptはその終点で話される言語です。BIP-341は実行が始まる瞬間までのすべてを定義します。すなわちコントロールブロック、並べ替えられたマークル畳み込み、ツイークの検査、パリティビットです。その後に実行されるものはリーフバージョンによって決まります。

現在、tapscriptを意味するのは0xc0のみです。他のバージョンを持つリーフはエラーではありません。BIP-341は未知のリーフバージョンについても実行が成功することを要求しているからです。これが、後のソフトフォークが同じbc1pアドレス形式の中で別のスクリプト言語を定義できるようにするフックであり、スクリプトパスによる使用をこのペアの耐久性のある半分にしています。