OP_CHECKMULTISIG

バイト0xaeが共有カストディを可能にしました。キー数、その数の公開鍵、必要署名数、その数の署名、そして余分な要素を1つスタックから取り出します。コンセンサスでは、1回の呼び出しで最大20個の鍵を使用できます。これにより、企業は5人の役員のうち3人の承認を出金の条件としながら、誰1人として単独では行動できないようにできます。

仕組み

検証は、探索ではなく2つのリストを1回たどる処理です。オペコードは署名を順にたどり、それぞれを後続の公開鍵と照合していくため、署名は対応する鍵と同じ相対順序で現れる必要があります。有効な2-of-3の2つの署名を入れ替えて提示するとスクリプトは失敗します。これは、マルチシグの支出を手作業で組み立てる際によくある混乱の原因です。

スタックは常に1要素足りない状態で残り、これはこれまでも変わりません。元の実装は使われることのない余分な要素を1つ取り出しており、これは既存のすべてのコインを壊さずには取り除けないバグでした。署名者は最初に捨てる要素を1つ積むことを覚え、BIP-147はブロック481,824以降、その要素を空にすることを要求することで、結果として生じる展性を解消しました。

問題となるのはコストの計算です。単純な呼び出しは、実際に含まれる鍵の数に関係なく20回の署名操作として計算されます。ただし、直前に小さい数を表すオペコードがある場合は、その数で計算されます。ブロックは署名操作コスト80,000単位に制限され、リレーポリシーでは1つのpay-to-script-hash入力に最大15単位まで認められています。スクリプトアドレスの共同署名者が最大15人までとなるのは、オペコード自体の上限20ではなく、このポリシー上の数によるものです。

Tapscriptはこれを完全に廃止しました。BIP-342により、このオペコードとそのverify版は、Taprootのリーフ内では見つかった時点で失敗するようになりました。Schnorr署名のバッチをリストと1回の操作で照合すると、Schnorrを採用する価値がある理由であるバッチ検証が成り立たなくなるためです。

使われる場面

すべてのライトニングネットワークのチャネルに資金を提供する2-of-2の出力はOP_CHECKMULTISIGを使用しており、これだけでこのオペコードはネットワークのスクリプト支出のかなりの割合を占めています。企業の財務部門、古い個人間取引マーケットプレイスのエスクロー、Taproot以前に構築された取引所のコールドストレージも、通常はスクリプトハッシュ内の2-of-3としてこれを使用しています。

鍵がハッシュを介さず出力に直接置かれる単純な呼び出しは、最大3つの鍵までリレー標準ですが、ほとんど使われません。送信者が鍵ごとに費用を負担し、1枚のコインが動く前に構成全体が公開されるためです。2014年にはこの形式が一時的にオンチェーンにファイルを保存する手段となり、データ保存に関する議論がリレーポリシーに触れるたびに再燃する一因となっています。

現在、共有カストディを設定する場合、ウォレットはおそらく数える方式を用いたTaprootの構成、または手数料よりも互換性を重視するならP2WSHスクリプトを生成します。

OP_CHECKMULTISIG vs P2SHマルチシグ

OP_CHECKMULTISIGは命令であり、P2SHマルチシグはそれを包む方法です。オペコードはクオラムをどのように検証するかを定め、包み方はクオラムがハッシュの背後に隠され、支出時に公開されることを定めます。同じ命令は、鍵がそのまま見える単純な出力、3で始まるアドレスの背後のredeem script、bc1qアドレスの背後のwitness scriptに現れることができ、この3つは同一の検証ロジックを実行しながら、コストとプライバシーが大きく異なります。できないのは、Taprootのリーフ内でこの命令を使うことであり、現代のクオラムがまったく別のオペコードで構築される理由はそこにあります。