BitGoのBrandon Blackより

最初のMuSigの論文は2018年に発表され、BitcoinにおけるMuSigの可能性は、 Taprootのソフトフォークの支持を得るためのセールスポイントの1つでした。 MuSigの研究は続き、2020年にMuSig-DNとMuSig2が発表されました。 2021年にBitcoinのmainnetでTaprootのアクティベートが近づくにつれ、 MuSig署名をBitcoinユーザーに提供することに対する興奮が高まっていました。 BitGoでは、Taprootのアクティベートと同時にMuSig Taprootウォレットをローンチしたいと考えていましたが、 仕様や、Test Vector、参照実装が不完全でした。 代わりに、BitGoは最初のTapscriptマルチシグウォレットをローンチし、 mainnet上で最初のTapscriptマルチシグトランザクションを作成しました。 それから約2年後、BIP327でMuSig2が定義され、BitGoは最初のTaprootマルチシグウォレットをローンチしました。

MuSig2を使用する理由

スクリプトマルチシグとの比較

MuSigには、スクリプトマルチシグと比べて2つの主な利点があります。 1つは、最も明白な利点で、トランザクションサイズとマイナー手数料の削減です。 オンチェーンの署名は、64-73バイト（16-18.25仮想バイト（vb））で、 MuSigは2つ（またはそれ以上の）署名を1つにまとめることができます。 BitGoの2-of-3の場合、MuSigのキーパスのインプットのコストは57.5vBですが、 ネイティブSegwitのインプットのコストは104.5vB、深さ1のTapscriptのコストは107.5vBです。 MuSigの2つめの利点は、プライバシーの向上です。 MuSigのキーパスで協力的に保持されているアウトプットの場合、 第三者のブロックチェーンの観察者が、その協力的な支払いと単一署名のTaprootの支払いを区別することはできません。

当然ながら、MuSig2には欠点もあります。2つの重要な欠点は、 ナンスに関連するものです。 素のECDSA（楕円曲線デジタル署名アルゴリズム）やSchnorr署名とは異なり、 MuSig2の署名者は一貫して決定論的なナンスを使用することができません。 このため、高品質のナンスを保証したり、ナンスの再利用を確実に防止することがより困難になります。 MuSig2では、ほとんどの場合、2ラウンドの通信が必要です。 最初にナンスを交換し、次に署名します。場合によっては、最初のラウンドを事前に計算できますが、 これは慎重に行わなければなりません。

他のMPCプロトコルとの比較

MPC（マルチパーティ計算）署名プロトコルは、前述の手数料とプライバシーの利点から人気が高まっています。 MuSigはシンプルなマルチシグ（n-of-n）プロトコルであり、これはSchnorr署名の線型性によって実現されています。 MuSig2は30分のプレゼンテーションで説明でき、完全な参照実装はPythonで461行のコードです。 FROSTのような閾値署名（t-of-n）プロトコルはかなり複雑で、 ECDSAベースの2者間のマルチシグでさえPaillier暗号やその他の技術に依存しています。

スクリプトの選択

Taproot以前でさえ、マルチシグ（t-of-n）ウォレット用の特定のスクリプトを選択することは困難でした。 複数の支払いパスを持つTaprootは、さらに問題を複雑にし、MuSigはさらに多くの選択肢を重ねています。 BitGoのTaproot Musig2ウォレットの設計に取り組む際に考慮したいいくつかの点を紹介します:

  • 辞書順のソートではなく、鍵の順序を固定します。各署名鍵には、特定の役割が鍵とともに保存されているため、 毎回同じ順番でこれらの鍵を使用することは簡単で予測可能です。
  • 私たちのMuSigのキーパスには、最も一般的な署名の充足数“user”/“bitgo”のみが含まれています。 ”backup”の署名鍵をキーパスに含めると、その鍵の使用頻度が大幅に低下します。
  • “user”と“bitgo”の署名ペアはTaptreeには含めません。これは2つめのTaprootスクリプトタイプであり、 1つめは3つのTapscript設計であるため、スクリプト署名が必要なユーザーは１つめのタイプを使用できます。
  • Tapscriptの場合、MuSigの鍵を使用しません。当社のウォレットには、”backup”鍵が含まれていますが、 これは当社の管理外のソフトウェアではアクセスや署名が困難である可能性があるため、 “backup”鍵に対してMuSigで署名できることを期待するのは現実的ではありません。
  • Tapscriptの場合、OP_CHECKSIGADDよりもOP_CHECKSIG / OP_CHECKSIGVERIFYスクリプトを選択します。 トランザクションを構築する際に、どの鍵が署名するかは分かっており、2-of-2の深さ1のスクリプトは、 2-of-3の深さ0のスクリプトよりもわずかに安価です。

最終的な構造は以下のようになります:

BitGo's MuSig taproot structure

（決定論的およびランダムな）ナンス

楕円曲線デジタル署名は、ナンス（一度だけ使用される数値）として知られる一時的な秘密の値を使用して生成されます。 公開ナンス（公開鍵と秘密鍵のようにシークレットナンスに対応する公開ナンス）を署名で共有することで、 検証者に有効期間の長い秘密鍵を明らかにすることなく、署名式の正当性を検証することができます。 有効期間の長い秘密鍵を保護するために、同じ（または関連する）秘密鍵とメッセージでナンスを再利用してはなりません。 単一署名の場合、ナンスの再利用を防ぐ最も一般的に推奨される方法は、RFC6979決定論的ナンス生成です。 一様にランダムな値でも、使用後すぐに破棄すれば安全に使用できます。これらの手法はいずれも、 マルチシグプロトコルに直接適用することはできません。

MuSigで決定論的ナンスを安全に使用するには、MuSig-DNのような手法を使用して、 すべての参加者が決定論的ナンスを正しく生成していることを証明する必要があります。 この証明がないと、不正な署名者は同じメッセージに対して2つの署名セッションを開始し、 異なるナンスを提供することができます。決定論的にナンスを生成する別の署名者は、 異なる有効なメッセージに対して同じナンスを使って2つの部分署名を生成します。 これにより、その秘密鍵が不正な署名者に明らかになります。

MuSig2の仕様の開発中、Dawidと私は、最後にナンスを提供する署名者は、 決定論的にナンスを生成できることに気づきました。 これについてJonas Nickと議論し、彼は正式にそれを仕様に取り込みました。 BitGoのMuSig2実装では、この決定論的署名モードは私たちのHSM（ハードウェアセキュリティモジュール）で使用され、 ステートレスにMuSig2署名を実行できるようにしています。

ランダムなナンスを複数ラウンドの署名プロトコルで使用する場合、 署名者はシークレットナンスがラウンド間でどのように保存されるかを考慮する必要があります。 単一署名の場合、シークレットナンスは作成と同じ署名実行中に削除できます。 攻撃者がナンス作成直後に他の署名者がナンスを提供する前に署名者のクローンを作成できる場合、 署名者は騙されて同じナンスで異なる有効なメッセージに対して複数の署名を生成する可能性があります。 このため、署名者は内部状態にどのようにアクセスでき、いつシークレットナンスが削除されるかを慎重に考える必要があります。 BitGoユーザーがBitGo SDKを使用してMuSig2で署名する場合、 シークレットナンスはMuSig-JSライブラリ内に保持され、署名のためのアクセス時に削除されます。

仕様化のプロセス

BitGoでMuSig2を実装した経験から、Bitcoin分野に携わる企業や個人は、 実装を予定している（または望んでいる）仕様の開発を時間をかけてレビューし、貢献する必要があることがわかります。 私たちが最初にMuSig2の仕様をレビューし、それを私たちの署名システムに統合する最善の方法を検討し始めたとき、 私たちのHSMにステートフル署名を導入するためのさまざまな困難な方法を検討しました。

幸いなことに、私が課題をDawidに説明したところ、彼は決定論的ナンスを使用する方法があると確信し、 最終的には、1人の署名者は決定論的であるという大まかなアイデアに落ち着きました。 その後、私がそのアイディアをJonasに提案し、実現しようとしている具体的なユースケースを説明したところ、 彼はその価値を認め、仕様に正式に取り入れたのです。

これで他のMuSig2実装者も、署名者の1人が状態を管理しないことで得られる柔軟性を活用できるようになりました。 仕様策定中にドラフト仕様をレビュー（および実装）することで、私たちは仕様に貢献し、 仕様が正式にBIP327として公開された直後にMuSig2署名をローンチする準備ができました。

MuSigとPSBT

PSBT (Partially Signed Bitcoin Transaction)形式は、 参加者（たとえば、単純な場合はコーディネーターと署名者）間で トランザクションに署名するために必要なすべての情報を伝達することを意図しています。 署名に必要な情報が多いほど、この形式の価値は高まります。 私たちは、MuSig2署名を容易にするために既存のAPI形式にフィールドを追加して拡張する場合と、 PSBTに変換する場合のコストと利点を検討しました。 私たちは、トランザクションデータのやりとりにPSBT形式を採用することに決め、それは大きな成功になりました。 まだ広く知られていませんが、BitGoウォレット（MuSig2を使用するものを除く、次の段落を参照）は、 PSBTをサポートするハードウェア署名デバイスと統合できるようになりました。

MuSig2署名で使用するPSBTフィールドはまだ公開されていません。私たちの実装では、 Sanketによって共有されたドラフトをベースにした独自フィールドを使用しています。 これは、PSBT形式のあまり語られない利点の1つです。カスタムトランザクションの構築や、 署名プロトコルに必要な追加データを、同じバイナリデータ形式で含めることができます。 グローバル、インプット毎、アウトプット毎の各セクションで既に定義されています。 PSBTの仕様では、未署名のトランザクションを、スクリプトや署名および、 最終的に完全なトランザクションを形成するために必要なその他のデータから分離しています。 この分離により、署名プロセス中により効率的な通信が可能になります。たとえば、 私たちのHSMは、ナンスまたは署名のみを含む最小限のPSBTを返し、 それを署名前のPSBTに簡単に組み込むことができます。

謝辞

BlockstreamのJonas NickとSanket Kanjalkar、FediのDawid Ciężarkiewicz、 そしてSaravanan ManiとDavid Kaplan、BitGoのチームの残りのメンバーに感謝します。