btc: MuSigは難しい

2025/02/01

はじめに

前回、MuSig の調査をした。

• P2TR script path では従来の MultiSig 命令は使えないようになった
• 1つずつ検証するスクリプトに置き換えるか、key path に置き換える方法がある

key path に置き換えるのが MuSig 方式。
最初に提案された MuSig 方式(MuSig 1とも呼ばれる)と、次に提案された MuSig 2 があるそうだ。

libsecp256k1 で MuSig 1 2 する

※2025/02/02追記 🙇 libsecp256k1 に載っていたのは MuSig 1 ではなく MuSig 2 だったことが分かった。 詳細は[次回](/2025/02/20250202-btc.html)。

libsecp256k1 に MuSig 用 API が実装されている。
MuSig 1 だ。

正直なところ、何をやってこうなっているのか理解できていない。。。
サンプルコード はそんなに長くないのだが、私は理解を諦めた。
秘密鍵を集約してやっていくのかと思っていたが、集約するのは公開鍵だった。
集約した tweak な公開鍵でアドレスを作り、そこに送金してもらう。
集約することはできるが、署名にせよ検証にせよ M-of-N で M != N ではないパターンはできないと思う。

libsecp256k1 を使って、無理やり自作 API に穴を開けながらも regtest で動かすことができた。

• commit

計算は libsecp256k1 のサンプルコードをほとんど持ってきた。
サンプルはトランザクションのデータではなかったので、以前作っていた P2TR key path のサンプルを改造していった。

むずかしい！

key path で処理する以上、署名は 1つになる。
普通の MultiSig なら各自で行った署名があればよかったが、集約するとなると署名時には秘密鍵を誰かが集めないといけないのでは？
もしかしたら鍵そのものではなく加工した値でもよいのかもしれないが、PSBT でやりとりするのとはまた違ったことを考えないといけない気がする。

いやー、むずかしい！

おわりに

軽い気持ちで MuSig を見ていったが、ほとんどサンプルコードながらも実装するとまた違った難しさが見えてきた。