Add MuSig2 module

[jonasnick]

I think a module for MuSig2 would be in the scope of libsecp256k1. Its relevance for the Bitcoin ecosystem is demonstrated by several factors:

• MuSig2 is already being adopted for Bitcoin payments.
• I have been inquired by various Lightning and (hardware) wallet developers about if and when MuSig2 will be in libsecp.
• Various developers of LN and (hardware) wallets have inquired about the integration of MuSig2 into libsecp and its timeline.
• There are specifications that depend on MuSig2, such as the "simple taproot channels" BOLT and MuSig2 PSBT and descriptor BIPs.

MuSig2 has a detailed specification (with reference code and test vectors) and security proofs.

I suggest to copy the MuSig2 module from libsecp256k1-zkp which has already undergone significant review. I volunteer to do this. We should, however, remove the functions for MuSig2 adaptor signatures as they lack both a specification and a satisfactory security proof.

[real-or-random]

Concept ACK

We should, however, remove the functions for MuSig2 adaptor signatures as they lack both a specification and a satisfactory security proof.

Makes sense.

[LLFourn]

We should, however, remove the functions for MuSig2 adaptor signatures as they lack both a specification and a satisfactory security proof.

I read this and assumed it just means not peer reviewed to the same standard as the MuSig2 protocol itself not that you had found a problem with your security proof you proposed for MuSig + adaptor before. Is this right?

[sipa]

Concept ACK

[t-bast]

Concept ACK, we'd be happy to start integrating this into lightning once that PR is opened!

[jonasnick]

@LLFourn Yes that's right. I'm not aware of any problems with the adaptor signature scheme as implemented in the secp256k1-zkp MuSig2 module. The only analysis of its security I'm aware of is this proof sketch: https://github.com/BlockstreamResearch/scriptless-scripts/blob/a8b6ff21fc7f4529eabbe639fbff49f047a3579d/md/musig2-adaptorsig.md.

[jonasnick]

I should note that the MuSig2 implementation in libsecp256k1-zkp uses a secp256k1_scratch_space in the API which affects attempts to get rid of the scratch space.

[hugohn]

Hi everyone,

Thank you for your hard work on secp256k1 and MuSig2!

We’ve integrated the MuSig2 branch into the Nunchuk wallet so you can try it with a real UI: https://nunchuk.io/blog/taproot-multisig.

Quantum‑computing question (let me know if this belongs elsewhere):

If I create a Taproot output whose internal key is a NUMS point (H + r·G per BIP‑341) so that I only intend to spend through script leaves, am I right that the output is still vulnerable once a large‑scale quantum computer exists?
My reasoning is that the tweaked output key Q visible on‑chain still has an ECC private key, so a QC attacker could derive it with Shor’s algorithm and present a key‑path signature, bypassing my script. Disabling that possibility altogether would require a soft fork that introduces a script‑only or post‑quantum output type.
Is this understanding correct, or am I missing something?

@sipa @jonasnick @real-or-random

[real-or-random]

We’ve integrated the MuSig2 branch into the Nunchuk wallet so you can try it with a real UI: nunchuk.io/blog/taproot-multisig.

Great to see it in production!

Quantum‑computing question (let me know if this belongs elsewhere):

If I create a Taproot output whose internal key is a NUMS point (H + r·G per BIP‑341) so that I only intend to spend through script leaves, am I right that the output is still vulnerable once a large‑scale quantum computer exists? My reasoning is that the tweaked output key Q visible on‑chain still has an ECC private key, so a QC attacker could derive it with Shor’s algorithm and present a key‑path signature, bypassing my script. Disabling that possibility altogether would require a soft fork that introduces a script‑only or post‑quantum output type. Is this understanding correct, or am I missing something?

Yes, this is perfectly correct.

https://bitcoin.stackexchange.com/ is probably the best place for this kind of question. Your questio is a nice one, you could still post it and your own answer there so that others can find it in the future.

There's also a discussion section here: https://github.com/bitcoin-core/secp256k1/discussions But I think it's the best place for discussions and questions specific to the library.

[hugohn]

Thank you @real-or-random ! I’ll post the question & answer on Stack Exchange.

Update: StackExchange link https://bitcoin.stackexchange.com/q/127660/178235