Schnorr signatures are coop for a number of reasons, but one of them is that you can combine a bunch of signatures and make them look like a single signature.
When you make a signature in Bitcoin, you add a bit of randomness to make it impossible for people to derive your private key from your signature.
You really don't want to reuse that little bit of randomness.
Basically it comes down to the fact that there are two unknowns in a Schnorr signaturerandxand if you give someone two signatures using these same unknowns then they get two equations with which they can solve for the two unknowns. But so long as you use fresh random nonces for each signature you produce, you introduce a new unknown each time you create a new equation so that there will always be more unknowns than equations.
When you add multiple signatures that are getting combined, as in MuSig2, it starts to get more complicated.
However, [a certain kind of attack] is only possible if a nonce pair is being reused three times. Does this mean that reusing a nonce just once is safe because a system of equations with two equations and three unknowns still has a degree of freedom? The answer turns out to be no, this is not safe, but it requires a more complicated attack.
This article describes an attack where people might get themselves into trouble with nonce reuse. Even if you are like me and don't follow the math, you can get a sense of why things like MuSig2 are challenging to implement.
this attack also shows that naive approaches to turning MuSig2 into a threshold signature scheme using replicated secret sharing are fraught. Namely, if you attempt to naively use replicated secret sharing on the MuSig2 nonce (say, by following this proposal and trying to naively use it alongside BIP 327 without making some important alterations), then you run into a problem where some nonce contributions are deterministically replicated between many signers, and you can cause those signers to use that same nonce to produce partial signatures for multiple different signature hashes, effectively causing nonce reuse allowing the above attack to be used.
Good writeup. The "limited reuse" framing is key — this attack is scarier than classic nonce reuse because you don't have to be careless. The vulnerability can be triggered by an adversary who controls the signing environment.
Why nonce reuse is catastrophic for Schnorr
A Schnorr signature is (R, s) where s = k + H(R || P || m) * x, with k as the nonce and x the private key. If you sign two messages with the same k, you get two equations with two unknowns (k and x) — trivially solvable. Key extracted.
The MuSig2 twist
MuSig2 uses two nonces per signer per session (R1, R2) to prevent Wagner's attack on the earlier MuSig1. But if an attacker can manipulate which messages you sign in which order — and can reuse even one of those nonces across sessions — they can set up the math to cancel out enough unknowns to extract your key.
The "limited" in the title is doing a lot of work: you don't have to reuse both nonces. Partial reuse, under adversarial conditions, is enough.
Practical implications
It's a reminder that multi-party signing protocols have a larger attack surface than single-signer Schnorr, even when the underlying math is clean.