waxwing on Nostr: I can't see an issue?, but I have an inkling/intuition what you're asking, so I'll ...
I can't see an issue?, but I have an inkling/intuition what you're asking, so I'll try my best :)
Just a point of clarity about "commitment": In MuSig1 we commit to the nonces in the first round; in MuSig2 we don't. We just send "nonce components" if you like. So Alice will send to Bob 2 points: R_{A1} and R_{A2} (the \nu=2 simplest version). And vice versa. Otoh you may be (correctly) referring to just curve points R as "commitments". Anyway ...
So, the aggregate nonce is calculated (by both Alice and Bob) as R_agg = (R_{A1}+R_{B1}) + b * (R_{A2 + R_{B2}) where b is the hash of: the agg pubkey, the list of nonce components (R1, R2 [see note below]), and the message m.
If Bob uses e.g. -R_{A1} incorrectly (sidestepping encoding of BIP340, tricky for coders, but irrelevant to the mathematics; "R" is ambiguously referring to *one* point on the curve, not two), he will get a different aggregate nonce to Alice, which means he won't be able to aggregate his partial signature with Alice's, but it won't change anything about the partial signature that Alice creates (which is s_alice = (k_{A1} + b k_{A2}) + hash(R_agg, P_agg, m) hash(L,P_alice) x_alice).
Presumably you are asking by analogy with the standard "problem" of two sigs with same nonce = reveal key?
The full final signature is supposed to be (R_agg, s_alice + s_bob). If he in his calculations uses say -R_{A1} then he will get the "wrong" R_agg but this doesn't result in "two signatures, same nonce; it's more "two signatures, two nonces" (vaguely) because R_agg (in this scenario) also changes, but moreover, s_alice won't allow Bob to aggregate validly because she doesn't use -k_A1 in getting s_alice.
Getting a bit waffly here. I'll let you extend it more if there's something I'm missing.
Is that anywhere near where your thinking was going here? :)
("note below": it would be better to hash in the serialization of every one of the 4 sub components of R_agg but MuSig2 doesn't as noted in a footnote to the BIP)
Just a point of clarity about "commitment": In MuSig1 we commit to the nonces in the first round; in MuSig2 we don't. We just send "nonce components" if you like. So Alice will send to Bob 2 points: R_{A1} and R_{A2} (the \nu=2 simplest version). And vice versa. Otoh you may be (correctly) referring to just curve points R as "commitments". Anyway ...
So, the aggregate nonce is calculated (by both Alice and Bob) as R_agg = (R_{A1}+R_{B1}) + b * (R_{A2 + R_{B2}) where b is the hash of: the agg pubkey, the list of nonce components (R1, R2 [see note below]), and the message m.
If Bob uses e.g. -R_{A1} incorrectly (sidestepping encoding of BIP340, tricky for coders, but irrelevant to the mathematics; "R" is ambiguously referring to *one* point on the curve, not two), he will get a different aggregate nonce to Alice, which means he won't be able to aggregate his partial signature with Alice's, but it won't change anything about the partial signature that Alice creates (which is s_alice = (k_{A1} + b k_{A2}) + hash(R_agg, P_agg, m) hash(L,P_alice) x_alice).
Presumably you are asking by analogy with the standard "problem" of two sigs with same nonce = reveal key?
The full final signature is supposed to be (R_agg, s_alice + s_bob). If he in his calculations uses say -R_{A1} then he will get the "wrong" R_agg but this doesn't result in "two signatures, same nonce; it's more "two signatures, two nonces" (vaguely) because R_agg (in this scenario) also changes, but moreover, s_alice won't allow Bob to aggregate validly because she doesn't use -k_A1 in getting s_alice.
Getting a bit waffly here. I'll let you extend it more if there's something I'm missing.
Is that anywhere near where your thinking was going here? :)
("note below": it would be better to hash in the serialization of every one of the 4 sub components of R_agg but MuSig2 doesn't as noted in a footnote to the BIP)