waxwing on Nostr: Yes it is, good find, tim ruffing covers it well in that answer. And my bad for not ...

Yes it is, good find, tim ruffing covers it well in that answer. And my bad for not remembering it. If you look at e.g. FROST they argue strongly that for the even more tricky case of *threshold* signatures (ie M of N, not just N of N, which as you can imagine is much more delicate), that a proof of knowledge of key shares is realistically essential, I came to the same conclusion looking at the security proofs of these things - it's stupidly complicated otherwise. MuSig2 is a very "industrial" protocol, by which I mean, partly because of the requirements of bitcoin, they push the limits on sophistication in order to achieve the most performant and smallest interactivity footprint possible version of multisignature. The cruder way is "key + proof of knowledge of key" in setup and then "nonce point + proof of knowledge of nonce point" in signing. But while that is kind of "the" solution to this niche problem, I'm for sure not going to recommend doing some half cocked protocol instead of doing the sane thing of creating fresh keys and then following the very well analyzed standard(s).

On your "more generic question", sure, the immediate thought is "well this was my secret key in the first case so it can't be adversarially chosen", yes, but the signing process has another "key", namely the nonce "shares" you do for each signing event. If they are adversarially chosen you again can get a forgery; in fact you can *use* this to extract the private key of the other signer. This is why the original MuSig was patched up to commit to the nonce points first, in an extra round.

If you add that 3rd round in, the overall idea is *perhaps* safe ... indeed that 3 round musig is quite nice, when I coded it for pathcoin I used that instead of MuSig2, it's a simpler security model at the cost of 3 instead of 2 rounds of comms. But meh, this is too slapdash, i suspect.