Transcript: Online Socratic on MuSig2

Hi

We had an online Socratic on August 11th with Tim Ruffing (co-author of MuSig2 draft BIP) and Elizabeth Crites (co-author of research papers on MuSig(2), FROST). It was previously announced here [0] but ended up being rescheduled.

The transcript is here [1], the video is here [2] and a reading list collecting together a number of resources on MuSig(2), FROST, ROAST etc is here [3].

We discussed a retrospective look at BIP340, handling x-only public keys in MuSig2 and the proposed TLUV covenant opcode, the history from initially broken MuSig1 through MuSig-DN to MuSig2, how MuSig2 and FROST compare for multisig schemes (i.e. n-of-n), why MuSig2 doesn't use proofs of possession and the current state of the draft MuSig2 BIP.

We covered a lot of topics and it was rather long (~2.5 hours) so check out the transcript or video if you are interested in any of the above topics. Many thanks to those who participated.

Jonas Nick recently tweeted [4] that the MuSig2 BIP [5] is approaching a stable version 1.0 which should be helpful to those who are interested (or already!) using it in the wild.

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020772.html [1]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/ [2]: https://www.youtube.com/watch?v=TpyK_ayKlj0 [3]: https://gist.github.com/michaelfolkson/5bfffa71a93426b57d518b09ebd0998c [4}: https://twitter.com/n1ckler/status/1567168267025874944 [5]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki

Hi Michael.

I read the transcript of the Socratic and I have to say that it is quite detailed and touches a lot of problems including the well-known theft/offline problems which also has forms elsewhere such as for passwords.

My question is, do you or anyone else in the Socratic know of any research to this that's don't involve a trade-off of theft or online connectivity?

ROAST and Liquid is perhaps the farthest I know of that addresses this problem, but it's using centralized nodes right now. I was thinking, maybe these federated nodes can be decentralized into a few of these "lite nodes" managed by each service wanting a payment, that make a threshold signature out of many subscribers paying at the same time.

- Ali

Hi Ali

> do you or anyone else in the Socratic know of any research to this that's don't involve a trade-off of theft or online connectivity?

Any generation of a signature(s), whether that be single key (e.g. OP_CHECKSIG), multisig with multiple signatures going onchain (e.g. OP_CHECKMULTISIG, OP_CHECKSIGADD) or key aggregation multisig with only a single signature going onchain (e.g. OP_CHECKSIG), requires private key(s) and hence has concerns with regards to security and theft of those private keys. Clearly funds locked behind any kind multisig arrangement is better than no multisig arrangement as otherwise theft of a single private key can result in loss of funds.

With regards to connectivity or interactivity key aggregation multisig does increase the interactivity requirements so if you wanted to minimize interactivity requirements you'd probably stick to OP_CHECKMULTISIG, OP_CHECKSIGADD that only requires you to generate a signature and then pass it onto the next signer.

> ROAST and Liquid is perhaps the farthest I know of that addresses this problem, but it's using centralized nodes right now. I was thinking, maybe these federated nodes can be decentralized into a few of these "lite nodes" managed by each service wanting a payment, that make a threshold signature out of many subscribers paying at the same time.

I'm not sure what you mean here. In the realm of generating signatures there isn't really a concept of a "lite node". That makes more sense in the realm of verification where you may or may not be doing full verification. In the generating signatures realm you are either contributing to the aggregated signature or generating a standalone signature yourself. If you are not doing either of those and aren't doing some kind of coordination then you are entirely irrelevant to the scheme. In the case of Liquid there is a 11-of-15 threshold signature arrangement where currently 11 signatures go onchain when funds are moved but if Liquid used a key aggregation scheme like FROST only a single signature would need to go onchain. With regards to centralization/decentralization you could increase the 11-of-15 to say a 22-of-30. Or you could have a nested MuSig/FROST scheme behind one of the 11 signers of the 11-of-15. But you can't get around the fact that you are either generating a signature that ultimately contributes to the moving of the funds or you aren't. If you aren't generating a signature then you are just verifying the signature(s) that go onchain like all other full nodes on the network.

Thanks Michael