Nostr Web Client

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)

Sjors Provoost 2y ago

Thanks for your thoughts!

By commitment I indeed meant the point, not the hash of a point. Since that commits to a secret. But in the context of how musig1 worked, that's probably not the best term.

I'm a bit confused by what R_{...} means in this notation: R_{A1}+R_{B1})

Did you mean to add an extra closing curly bracket here: b * (R_{A2 + R_{B2})

So: b * (R_{A2 + R_{B2}})

Or did you mean: b * (R_{A2 + B2})

What I was wondering about is what happens if B1 = -A1 and B2 = -A2, and then Alice goes ahead and produces a partial signature. In the case of b * (R_{A2 + R_{B2}) the aggregate nonce would be zero, but in the case of b * (R_{A2 + R_{B2}) the aggregate nonce can't be zero.

IIUC if Alice were to provide a partial signature with an aggregate nonce of 0 she'd reveal her private key? But if the aggregate can't be zero then that's not a concern. Or if the partial signature doesn't use the aggregate key, I guess it's also not a concern.

Reply to this note

Please Login to reply.

Discussion

waxwing 2y ago

Huh, I sent a reply an hour ago on the phone but just seems to have vanished.

First, about the curly braces, yes there was just one missing sorry (R_{A2} + R_{B2}).

Second, doh, I totally missed the point of the question, and, my fault, your language was pretty clear.

So I don't think there's any issue, no: if Alice gives R_{A1} and Bob picks -R_{A1} as his R_{B1} (and same for index 2) then, yes, the aggregate cancels.

But that doesn't allow him to cancel the secret nonce:

Alice may send him s_alice = k_{A1} + bk_{A2} + (hashes of stuff) * x_{A}. But he cannot cancel out those k-values by adding his s_bob because he cannot provide e.g. -k_{A1}. He doesn't know those scalars (DLP).

So he can't get the secret key by doing that cancellation (and yes, absolutely, he *would* be able to get Alice's key if he could effect that cancellation).

(It's a sidebar but 0 values for the nonce are explicitly disallowed in plain ECDSA and plain Schnorr iirc).

Sjors Provoost 2y ago

Disappearing replies is always sad. I'm still a bit confused about the R_{...} notation.

So one important element here is that Alice never reveal an individual (secret) nonce, i.e. never reals k_{A1} or k_{A2}, but only some linear combination of both?

waxwing 2y ago

Oh, no Alice wouldn't explicitly reveal even the combination of k values.

Back to the single signer case: s = k + ex. You never reveal k, only R (the "commitment" to k, as discussed before). You publish R and s, so revealing k would expose the key (x). It's the fact that there are *two* secret unknowns (k and x) on the RHS that provides the security against leakage. If I give you the number 41 and say it's the sum of two numbers (mod 43), I'm not telling you anything (it could be any sum of 2 numbers in range).

Same here; Alice will give Bob s_alice, the partial signature of Alice, which is: k_{A1} + bk_{A2} + hashes * x_alice. But she would never separately hand over just k_{A1} + bk_{A2} ; that's her secret nonce.

About notation like k_{A1} I'm just doing the same as in LaTeX, it means everything in the curly braces is the subscript of the thing before _ .