P2SHマルチシグ

2-of-3のリディームスクリプトは105バイトです。2を表すオペコード、プッシュプレフィックス付きの33バイトの圧縮鍵3個、3を表すオペコード、そしてOP_CHECKMULTISIGで構成されます。1つの入力を消費するにはおよそ297vbyteかかり、ネイティブSegWitの単一鍵入力の約3倍です。これは2012年から、ウィットネスデータに割引が適用されるまでの間、共同カストディの標準的な構成でした。

仕組み

P2SHマルチシグのリディームスクリプトは、必要な署名数、参加する各公開鍵、鍵の総数、OP_CHECKMULTISIGの順に、クォーラムを直接列挙します。コインが未使用のまま置かれている間は、出力がその20バイトのハッシュのみを記録するため、誰にも見えません。

15鍵という上限は、方針による発明ではなく算術です。プッシュプレフィックスを含めて1個34バイトの圧縮鍵15個で510バイトになり、2つのカウント用オペコードとOP_CHECKMULTISIGを加えると513バイトになり、単一のスタック要素に対する520バイトの上限に収まります。16個目の鍵は収まりません。ビットコインのコンセンサスルールではOP_CHECKMULTISIGに20個の鍵まで使えますが、P2SHのリディームスクリプトは物理的にそれだけの鍵を運べません。

消費の経路には古い癖があります。OP_CHECKMULTISIGは使用する数より1つ多くスタックから要素を取り出します。これは当初の実装にあったバグで、ハードフォークなしには取り除けませんでした。署名者はダミー要素を最初にプッシュすることでこれを回避しており、BIP-147によりこの要素は空であることが必須となり、SegWitと同時にブロック481,824で有効になりました。したがって、完成した入力は、空のプッシュ、署名、署名、リディームスクリプトという並びになります。

使われている場面

2013年から2018年の間に構築された企業の資金管理、相続の取り決め、取引所のコールドストレージは、大部分がP2SHマルチシグです。古い個人間取引マーケットプレイスのエスクローは2-of-3を使い、プラットフォームが3つ目の鍵を保有していました。これにより、どちらの取引当事者もコインを完全には管理しないまま紛争を解決できました。

バックアップの要件は人を戸惑わせます。各共同署名者には、他のすべての共同署名者の拡張公開鍵、またはそれらを記録したディスクリプタが必要です。リディームスクリプトは1つのシードフレーズから再構築できないからです。3つのうち2つの秘密鍵を保有していても、公開鍵を1つも持っていなければ消費できません。ディスクリプタをシードのバックアップと一緒に書き留め、この構成が大切なものを保有する前に復元をテストしてください。

今日の新しいクォーラムは代わりにP2WSHやTaprootで構築されます。同じポリシーでも消費にかかるコストがはるかに低く、15鍵の上限もないからです。既存のP2SHのボールトはこれまでとまったく同じように機能し、強制的な移行はありません。

P2SHマルチシグvsマルチシグ

マルチシグはポリシーであり、P2SHマルチシグはそれを書き記す1つの方法です。同じ2-of-3の要件は、ビットコインの最も初期のルールによるベアマルチシグの出力、P2SHのリディームスクリプト、P2WSHのウィットネススクリプト、あるいはTaprootでは通常の支払いのように消費されクォーラムをまったく明かさない1つの集約鍵の中に置くことができます。P2SHを選ぶことは、手数料、15鍵の上限、そして初めてコインを移動した時点で署名の構成全体が公知になるという事実についての判断です。