MuSig2 は、複数人が一つの Schnorr 署名を共同で作る仕組みです。特定のメッセージへの承認を示しながら、各自の秘密鍵は明かしません。BIP327 の手順では二回の通信を行い、公開鍵を集約して、各自の寄与を BIP340 互換の署名にまとめます。基本形は n-of-n で、参加する署名者全員の寄与が必要です。
アリスとボブの両方が支払いを承認する共同金庫を考えてみます。デジタル署名は、秘密の数値である秘密鍵を使って支払いの許可を証明し、鍵そのものは公開しません。従来のスクリプトによるMultisigでは、取引に複数の鍵や署名が公開される場合があります。MuSig2では、それぞれが秘密鍵を手元に保ち、共同署名に寄与します。ネットワークが検証する結果は一つです。節約できるのはチェーン上の記録と検証の負担であり、参加者間の調整は引き続き必要です。 Jonas Nick、Tim Ruffing、Yannick Seurin は、2020年10月に公開した論文でこのプロトコルを発表しました。 [3] [2] [10]
MuSig2だけでは、三人のうち任意の二人が欠けた一人を補える2-of-3方式にはなりません。n-of-nでは、グループの各メンバーの寄与が必要です。連絡できない人や署名を拒む人がいれば、協力は止まります。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。その場合も使えるウォレットにするには、別の支出経路や署名方式をあらかじめ設計する必要があり、MuSig2という名前だけで用意されるものではありません。 [1] [8]
署名前に参加者は集約公開鍵を作ります。公開鍵は署名の検証に使うもので、秘密にしておく必要はありません。一回目は、署名を準備するための一度限りの寄与である公開 nonce を交換します。二回目は同じメッセージとコンテキストに対する部分署名を作って送り、最終署名にまとめます。プロトコルの条件に従えば、支払い内容が決まる前に一回目を準備できます。ただし各参加者は、自分の部分署名を作る前に、具体的な取引、特に送金先、金額、手数料を確認しなければなりません。準備は未知の支払いへの承認ではなく、署名後の確認では遅すぎます。 [1] [3]
単純な加算では、攻撃者が他人の鍵を悪用できるように自分の公開鍵を選べるおそれがあります。そこでMuSig2は、鍵の一覧から計算した数値の重み、つまり係数を使います。KeyAggは鍵の順序も考慮し、アプリケーションはKeySortで順序を統一できます。全員が同じ一覧と規則を使わなければ、同じ集約公開鍵にはなりません。 [1] [5]
ここでのnonceはマイニング用カウンターではありません。一度限りの署名材料であり、pubnonceは相手に渡しますが、secnonceは署名者が保持します。秘密nonceを別のSign呼び出しに再利用してはいけません。再利用によって作った二つの部分署名から秘密鍵が漏れる可能性があります。メッセージを変えたり、同じに見える支払いをやり直したりしても、安全な例外にはなりません。 [1] [7]
暗号計算が正しくても、再起動後にバックアップから使用済みsecnonceを復元したり、二つの並行処理に同じものを渡したりすれば安全ではありません。Libsecp256k1は署名時に秘密nonceを上書きして無効化しますが、管理外にあるコピーはその保護をすり抜けます。エラー、復元、並行処理でも再利用を防ぐ状態管理が必要です。署名用の秘密鍵自体は繰り返し使えます。一度限りなのはnonceです。 [7]
調整役は公開nonceと部分署名を集め、交換を仲介できます。プロトコルが正しく使われていれば、誠実な参加者の代わりに署名する能力は得られませんが、処理を妨害することはできます。各署名者は署名内容を確認しなければなりません。部分署名の検証は問題の発見に役立ちますが、元の公開寄与と正しいコンテキストが必要で、集約nonceだけでは原因となった相手を特定できません。 [1] [7]
結果は 64 バイトの BIP340 署名です。Taproot key path は、出力に記録された鍵に対する署名をネットワークが検証し、予備のスクリプトを公開せずに支出する方法です。既定のモードを使わない場合は、署名の後に sighash の種類を示す一バイトが付きます。これは署名が取引のどの部分に結びつくかを指定し、その部分が変わると署名が無効になります。署名だけでは参加者数や個々の鍵は分かりません。ただし MuSig2 は金額、支払いを取り巻くすべての関連、当事者間の通信を隠しません。別々の入力の署名も自動的には統合しません。入力は、この取引で使う、以前受け取った出力を参照します。 [5] [6]
Taproot には共同の key path に加え、別の鍵の組み合わせやタイムロックなどのスクリプト条件を用意できます。タイムロックは指定した時間やブロック高の後に特定の経路を使えるようにするもので、必要な署名の代わりにはなりません。ブロックは、共有する履歴に追加する取引のまとまりです。ブロック高は、チェーン内でのブロックの位置を表します。条件は、支出ルール付きの金額である出力を作る時点で、暗号学的に確定させる必要があります。署名者を失ってから追加はできません。Script path は、そのスクリプトを通じた支出で、該当する条件が公開され、費用が増える場合もあります。復元には、個々の秘密鍵だけでなく、選んだ構成の情報も必要です。 [6] [1] [9]
BIP327はプロトコルを説明しますが、実際のインターフェース、バックアップ、手順はライブラリとウォレットで決まります。版、テストベクトル、nonceの管理、署名する取引の確認を調べてください。Schnorr署名への対応だけで、どのウォレットもMuSig2を完全に使えるわけではありません。共同署名は既存のBIP340とTaprootの規則を使うため、MuSig2の利用自体に新しい合意規則のopcodeは必要ありません。 [4] [7] [2]
理解を深めるには、この項目とあわせて次もお読みください Schnorr Signature, Taproot, Multisig, PSBT. 次の項目からも参照されています Schnorr Signature, Submarine Swap, FROST, PTLC.