There was an interesting mailing list post from Michael Folkson a few days ago:
Could this mean the standardization of MuSig at long last?
I had a look at the transcript and it provides some context which demonstrates that MuSig(2) is going to have implications across key aggregation applications, including the lightning network:
Having to go through the three rounds every time we want to sign a message is certainly inconvenient. Especially if the signature is time-critical and network messages are slow. So how about this, we do the first two rounds whenever it's convenient for us. And only once there is a message to sign, we exchange partial signatures. In the case of Lightning, for example, the channel peers exchange a bunch of nonce commitments and nonces immediately when establishing a connection. When it comes to signing a channel update, one of the pre-shared nonces is used and only one communication round is required to complete the signature. THIS IS INSECURE.
[by Jonas Nick]
To keep things short and simple, the combined nonce is known so a malicious user can try to make his own artificial message, and N-1 more forged messages such that the sum of those message hashes equals his own artificial message hash. It is surprisingly not difficult to carry out (A revision of the MuSig1 draft patched this hole some time during 2020).
I had posted a tx aggregation scheme on the mailing list at the beginning of September, that had a tradeoff between caching the signatures making it vulnerabile to theft, or risking one of the signers disappears and all funds are permanently lost. ZmnSCPxj among other things pointed out that this is a type of Spilman channel, so I went and read the literature about that. In particular, the Bitcoin Wiki
has a page for that. There were also a bunch of channel types which I didn't study hard enough because I was busy with other stuff.
The QA session actually addressed this point and I think it's beneficial to copy it here (garlonicon in my previous thread also had some words to say about this problem, Pedersen commitments):
MF (Michael Folkson): In terms of the things that can go wrong in a MuSig protocol, you do need signatures from all parties so if one party is not responsive then you can't produce a signature. You'd need a backout, an alternative script path.
TR (Tim Ruffing): This is true in every multisig thing. If the other person doesn't want to or is offline there is no chance.
MF: Either unresponsive or providing an invalid signature and it just can't complete. In terms of sorting pubkeys, signatures, does that present a complication? If people are receiving pubkeys and signatures in different orders do you need a finalizer or combiner? Do you need to fallback onto that? Do you need to allocate a finalizer or combiner at the start?
TR: For key aggregation the way the BIP is written you can do both. The key aggregation algorithm in the BIP gets an ordered list as a data structure. You can parse an arbitrary list, which means you can sort the list of public keys before you parse it or you can choose to not sort it. We took this approach because it is the most flexible and different callers may have different requirements. For example if you use multisignatures with your hardware wallets at home you probably don't want to have the complexity and just sort the keys. But maybe some applications already have a canonical order of keys, for example in Lightning. I'm not sure how they do it, I'm making this up, maybe there you have one party that initiates the channel and the other party which is the responder in the channel. Then you could say "Let's put the initiator always at position 1 and the responder always at position". I think we described this in the BIP in the text somewhere. If you don't want to care about the order you are free to sort the public keys before you pass them to key generation. If you care about the order you can pass in whatever you want. If you pass two lists or two different versions of a list in a different ordering then the resulting key will be different because we don't sort internally. For signatures it doesn't matter in which order you get them. This is really handled in the protocol, that doesn't matter. But if you are asking for things that can go wrong, I think the main thing that can go wrong is what we already talked about, the requirement to have good randomness. This is really the one thing where you need to be careful as an implementer. Of course you always need to be careful. You need some good source of randomness which is typically the random number generator in your operating system.
Even though the later part is just about sorting the partial keys, I included it for context. But the summary is in Tim Ruffing's first answer: MuSig is only going to sign all of the signatures, or none at all. There is no "backout" that the MuSig provides.
i.e. an open problem left open. Although as I mentioned above, garlonicon suggested I use Pedersen commitments along with Multi/MuSig. After reading about that, I am not so sure what the secret r-value should be that will, at the same time, be an invalid secret for an ECDSA or Schnorr-type transaction.
Interestingly the session makes some brief mentions about Pedersen commitments but in the context of some older and more complicated signing scheme (FROST). So that's perhaps the end of it.
In fact, Tim Ruffing as a few things to say about that:
TR: I think there are a few things to say. First of all yes MuSig is simpler than FROST. Multisignature is simpler than threshold signature. Mostly because of the thing we just mentioned, key generation is non-interactive in multisignatures and interactive in threshold signatures. The second thing is use cases. In cryptocurrencies multisignatures have some use cases because in cryptocurrencies you always have an escape hatch when the other parties go offline. For example in a 2-of-2 Lightning channel you always need to have some timelock that says "If the other party disappears I can get the money back after some time". If the other party disappears we can't just create a new key because there's money stored on that key and the money would be gone. In other applications, and the IRTF is probably not interested in cryptocurrencies, threshold signatures make a lot of sense. They also make sense in a lot of blockchain applications, as I said with blockchains we have these special cases where multisignatures make sense. But in general if you ignore cryptocurrencies for a moment then threshold makes more sense. You can scale it better. It is pretty useless to have a 10-of-10. What is the goal of all these schemes? To distribute trust. But with multisignatures you increase security but you decrease safety. Two things can happen, either some people get malicious or steal your keys, that is great with 10-of-10, 9 people can get compromised, their keys stolen, and the scheme is still secure. But on the other hand you always increase the probability that you lose the key material. If you have a 10-of-10 and you lose one of the 10 pieces the key is gone. You increase security against attacks but you decrease security against losing your keys. The only way out of this dilemma is threshold signatures where you don't need to do 10-of-10 but you could do 7-of-10 or something like this. Then you can trade off this security against attackers versus security against losing stuff. This is something you can really only do with threshold keys. This is why in general people are more interested in threshold things. On top of this in Bitcoin I mentioned contracts, for example Lightning or other complicated things, we always have an escape hatch in these contracts. Even in other setups, for example at home when you store some larger amount of coins, maybe you want to have a 2-of-3 between 3 hardware wallets or 2 hardware wallets and your machine. This is a setup that I think a lot of people use. Even there you want threshold because if you lose one hardware wallet you don't want to lose all your coins. But using Taproot there are some ways you could do this even with multisignatures. For example say you have 3 signers, 2 hardware wallets and a backup wallet somewhere else. You could have a Taproot output that is just a 2-of-2 of the two main signing wallets and you have some script paths that cover the other possibilities. You have two primary devices and as long as you have access to those you use this normal key spend. Whenever you need to resort to the backup device, then you need to open the Taproot commitment and show the script path, use the other MuSig combinations. You could implement this 2-of-3 via 3 combinations of 2-of-2s. In the end this may be more convenient in practice than going through the hassle of running this interactive distributed key generation that you would need for FROST. I think this is another reason why multisignatures are interesting in Bitcoin. But of course this doesn't scale. If you want to do 20-of-60 or 20-of-40, you probably don't want to do this at home, you can't enumerate all the possibilities here. It would be very inefficient.
You see, the idea of decreasing transaction size using MuSig combined transactions relies on the strong assumption that nobody will go offline. Of course, you can lower the threshold requirement for the signatures, at the cost of increasing the risk of some people going rogue.
The session wraps up with a discussion about ROAST (some signature scheme like MuSig that makes FROST signatures and is used in Liquid) but some people do not like that because it requires a central oracle to distribute the signatures - thus completing the Trilemma (and before anyone asks: no, Merged Mining is not going to solve anything, it's too controversial and has offline implications in the media and diplomatic circles).
To get back to the point (which is MuSig2):
It's good that a MuSig2 BIP is finally about to roll though. It's about time that something like this happens and has profound implications in both scaling with off-chain threshold transactions or with aggregated transactions.
