Abstract. MuSig2 is an n-of-n  aggregated multisig scheme  in which a group of participants creates a single regular Schnorr signature under an aggregated public key. The work by Nick, Ruffing, and Seurin addresses a fundamental practical problem with earlier two-round schemes: resistance to concurrent signing sessions without sacrificing a compact, standardly verifiable signature. The central idea is to replace each participant’s single nonce with a pair of nonces and form an effective nonce as a hash-dependent linear combination; this is precisely what deprives an attacker of the controlled linearity on which ROS attacks are built. The paper discusses the mathematical construction, proof premises, cryptanalytic context, and requirements for a secure implementation.

Keywords:  MuSig2, Schnorr, secp256k1, discrete logarithm, OMDL, AOMDL, ROS, Wagner, rogue-key attack, Taproot, BIP340, BIP327.

1. Context and contribution of the work

Multi-signature is needed when authorization must be a joint action by several independent key holders: for example, two co-founders, a cold storage system with multiple devices, or participants in a Lightning channel. Naive deployment of individual signatures reveals the policy structure and increases the data; MuSig2, by contrast, produces a single aggregated key and a single signature that looks like a standard Schnorr signature.

Property	MuSig2 meaning	Practical consequence
Key aggregation	Non-interactive, with key coefficients	Prevents rogue-key substitution
Signing rounds	Two broadcast rounds	Less latency and less protocol state
Result	Schnorr’s usual signature	BIP340 compliant and compact on-chain footprint
Parallel sessions	Supported in the security model	There is no need to artificially serialize operations
Preprocessing	The first round does not depend on the message	Nonce can be prepared before the transaction occurs.

A historical cryptanalytic fact.  A study by Drijvers et al. (IEEE S&P 2019) showed that the then-known two-round Schnorr multisigs in the “pure” discrete logarithm group were vulnerable to ROS (Random Oracle Subversion) attacks: a malicious cosigner could conduct multiple parallel sessions and guess responses using Wagner’s generalized birthday technique. This result made the two-round multisig not just an engineering optimization, but a cryptanalytic problem; MuSig2 became a constructive response to it.

2. Mathematical model

Let us use the additive notation below for the cyclic group of exact prime order  ngenerated by the point  G. In Bitcoin practice, this is the elliptic curve group secp256k1. The participant’s secret key  i is a scalar  x_i ∈ Z_n, and the public key is  P_i = x_i G.

LaTeX block: Schnorr basic signature

\[
P = xG, \qquad R = kG, \qquad e = H(R \parallel P \parallel m),
\]
\[
s = k + ex \pmod n, \qquad sG \stackrel{?}{=} R + eP.
\]

Correctness follows immediately from the linearity of the group operation:  sG = (k+ex)G = kG + e(xG). However, this same linearity makes the nonce a critical secret: if one is repeated  k in two signatures on different messages, the private key is derived algebraically.

LaTeX block: key extraction when nonce is repeated

\[
s_1 = k + e_1x, \qquad s_2 = k + e_2x,
\]
\[
x = (s_1-s_2)(e_1-e_2)^{-1} \pmod n.
\]

A real-world cryptanalytic example.  Compromises of ECDSA keys in cryptocurrency and hardware systems have repeatedly occurred due to repeated or predictable nonces; the classic public Sony PlayStation 3 incident demonstrated that a fixed nonce in ECDSA allows for the recovery of the secret key. The formula also applies to the linear portion of Schnorr/MuSig2: nonce uniqueness and secrecy are not a recommendation, but a condition for key security.

3. Public key aggregation

The simple sum  P = ΣP_i is insecure due to a rogue-key attack. An attacker, seeing the honest participant’s key  P_A, could choose  P_M = XG - P_A; then the “aggregated” key would become  XG, the private key  X is known only to the attacker, and the honest participant would formally be included in the list.

MuSig2 associates each key with the entire ordered list of keys. Let  L = H(P_1 || ... || P_n), and be the coefficient  a_i = H(L || P_i) (with MuSig2* optimization for a single key). Then:

LaTeX block: key aggregation

\[
L = H(P_1 \parallel P_2 \parallel \cdots \parallel P_n),
\]
\[
a_i = H(L \parallel P_i) \pmod n,
\]
\[
Q = \sum_{i=1}^{n} a_iP_i = \left(\sum_{i=1}^{n}a_ix_i\right)G.
\]

The attacker can no longer choose a compensating key in advance: its coefficient depends on the full list, including the malicious key itself. This is a standard technique for binding a key to the context of a set of signatories, turning the brute-force problem into a self-referential equation in a random oracle.

4. Two-round MuSig2

4.1 Preparation and the first round

Each signer  i selects  two  independent one-time scalars  k_{i,1}, k_{i,2} and publishes two nonces  R_{i,1}=k_{i,1}G,  R_{i,2}=k_{i,2}G. Unlike MuSig1, a separate round of commitments is not required before revealing the nonces.

LaTeX Block: Round One

\[
R_{i,1}=k_{i,1}G, \qquad R_{i,2}=k_{i,2}G,
\]
\[
R_1=\sum_i R_{i,1}, \qquad R_2=\sum_i R_{i,2}.
\]

A practical example:  Two Bitcoin custodians can prepare and exchange pairs of public nonces in advance, before agreeing to a specific payment. Once the accounting department approves the 32-byte digest of the transaction, a second exchange—partial signatures—is required. This is especially useful in situations with high network latency or intermittent availability of hardware wallets.

4.2. Binding a nonce to a session

After the nonce, aggregate key, and message are captured, the nonce coefficient is calculated  b. Each nonce pair is then compressed into an effective session nonce. The coefficient  b depends unpredictably on the full transcript, so an attacker cannot pre-arrange the desired linear combination, as in vulnerable two-round schemes.

LaTeX Block: Effective Nonce and Challenge

\[
b = H(R_1 \parallel R_2 \parallel Q \parallel m) \pmod n,
\]
\[
R' = R_1 + bR_2,
\]
\[
R = \begin{cases}R', & \text{if } y(R') \text{ is even},\\-R', & \text{otherwise},\end{cases}
\qquad
e = H(\operatorname{x}(R) \parallel \operatorname{x}(Q) \parallel m) \pmod n.
\]

Sign normalization aligns the scheme with the x-only convention of BIP340: only the x-coordinate is transmitted in the final signature  R. In BIP327, the coefficient is calculated using the tagged hash  MuSig/noncecoef, and the challenge is calculated using the tagged hash  BIP0340/challenge, which separates the hash domains.

4.3. Second Round and Aggregation

Each participant generates a scalar partial signature, transmits it to the others or to the aggregator, and then the scalars are summed. In a simplified form without tweaks:

LaTeX block: partial and final signatures

\[
k_i = k_{i,1}+bk_{i,2} \pmod n,
\]
\[
s_i = k_i + e a_i x_i \pmod n,
\]
\[
s = \sum_{i=1}^{n}s_i \pmod n,
\qquad \sigma=(\operatorname{x}(R),s).
\]

Verification of the result remains the verification of one Schnorr signature:

LaTeX block: final check

\[
sG \stackrel{?}{=} R + eQ.
\]

Indeed,  Σs_i G = Σ(k_iG) + eΣ(a_ix_iG) = R + eQ. This property is the reason for MuSig2’s compactness: the blockchain validator does not need to verify the signature for each co-signatory.

5. Cryptanalysis: ROS and Wagner’s method

In a ROS attack, the attacker exploits multiple concurrent sessions with an honest victim and adaptively chooses their own nonce/hash function calls. The goal is to find a combination of sessions in which the victim’s contribution is compensated or forms a useful linear relationship; this search is related to Wagner’s generalized birthday attack on the  k-sum problem .

The key isn’t breaking the discrete logarithm of secp256k1, but exploiting the protocol interface: if an attacker receives many linearly related responses from an honest signer in a loosely coupled context, the random oracle can be subordinated to the desired linear equation. Therefore, simply forbidding nonce replay is insufficient: a provable association of the nonce with the full transcript of the concurrent session is required.

Vulnerable structure	Cryptanalytic possibility	MuSig2 countermeasure
One nonce per participant and two rounds	Adaptive construction of linear relationships between sessions	Two nonce points for each signatory
The effective nonce is predictable before transcript fixation	ROS/Wagner – Collision and Utility Detection	b=H(R_1,R_2,Q,m) after the publication of nonce
Prime sum of public keys	Rogue-key: A participant “compensates” for someone else’s key	Coefficients  a_idepending on the key list
Repeat secret nonce	Algebraic extraction x_i	Single-use, protected state, and nonce erasure

Connections to the history of cryptanalysis.  Wagner’s method (2002) systematized the search for solutions to the generalized birthday/k-sum problem, dramatically reducing the complexity compared to an exhaustive search in suitable parameters. Drijvers et al. extended this idea to the analysis of interactive multiparty Schnorr signatures: their cryptanalysis focused not on the basic complexity of ECDLP, but on the composition of hash challenges, concurrency, and the order of protocol message disclosure.

6. Prerequisites of proof

The authors prove the existential non-forgeability of MuSig2 using the random oracle model (ROM); for the more efficient variant MuSig2*, the proof uses a combination of ROM and the algebraic group model (AGM). This is not an unconditional guarantee: the hash function is modeled as an ideal random oracle, and the group and behavior of the algebraic adversary are subject to formal constraints.

LaTeX block: DL and one-more DL – intuitive form

\[
\text{DL: by } X=xG \text{ find } x.
\]
\[
\text{OMDL: over multiple } X_j=x_jG \text{ calculate more values ​​of }x_j,
\text{ than the number of queries allowed to the discrete logarithm oracle.}
\]

OMDL (one-more discrete logarithm) is stronger than the standard DL assumption: the adversary gains limited access to an oracle that returns discrete logarithms, but must return “one more logarithm” than requested. This assumption is natural for interactive Schnorr-like knowledge proofs and multi-signature proofs, but it is stronger and less conservative than a reduction to DL alone.

The cryptanalytically correct interpretation is this: the paper does not claim that MuSig2 is reducible solely to the difficulty of ECDLP on secp256k1. Its formal guarantee relies on a weakened version of OMDL and an idealized hash; later papers explicitly note that the original MuSig2/FROST relies on a stronger OMDL assumption and explore replacements using regular DL or RSA.

7. Practical safety

A cryptographic scheme may be provably secure, but its implementation is insecure. BIP327 emphasizes that rerunning  Sign with the same secret nonce allows the key to be derived from partial signatures; therefore, the nonce must be unique, stored as sensitive state, and destroyed after use.

Risk	Failure mechanism	Engineering measure
Repeat nonce	Revealing a secret key through signature differences	Generate two fresh random nonces; mark and erase the secret nonce atomically
Substitution of transcript	The signatory believes  Q,  m or nonce, differently than the group	Authenticated channel, local re-aggregation and immutable session context
Unscrupulous aggregator	Denial of service, inconsistent message set	Validate aggregated nonce and partial signatures; the aggregator must not be trusted for unforgeability
Invalid keys/rogue key	Inconsistent or malicious key setup phase	Use KeyAgg and canonical key list order if the application does not specify one
Errors in tweak	Signing the wrong Taproot/BIP32 key	Hard-wire tweak, parity, and session context; use the BIP327 specification

Safe Life Cycle Pseudocode

# Псевдокод: не production-код
keyagg_ctx = KeyAgg(sorted_or_canonical_pubkeys)
secnonce, pubnonce = NonceGen(sk, own_pk, aggpk, optional_message, unique_context)
send(pubnonce)                         # Раунд 1
aggnonce = receive_and_verify_nonces()
session = SessionContext(aggnonce, pubkeys, tweaks, message)
partial = Sign(secnonce, sk, session)  # ровно один вызов
secure_erase(secnonce)
send(partial)                          # Раунд 2
verify_each_partial_signature()
sig = PartialSigAgg(partials, session)
assert BIP340_Verify(aggpk, message, sig)

A practical example.  In a 2-of-2 Lightning channel, two nodes can use MuSig2 to share a Taproot keypath: the first round with a nonce allows for preprocessing, and when updating the state, the parties exchange partial signatures. However, the network “coordinator” should not be a point of trust: it can disrupt the session, but with proper verification, it should not be able to forge a signature on behalf of an honest participant.

8. BIP327 and the Bitcoin Ecosystem

BIP327 standardizes MuSig2 for BIP340-compatible multisigs and explicitly defines it as  an n-of-n , rather than a  t-of-n, threshold-based  scheme. For a threshold policy where any signature  t is  n sufficient, a different primitive should be used, such as FROST or a specialized threshold scheme; MuSig2 cannot be interpreted as a replacement for threshold signatures.

For Taproot, the MuSig2 keypath has virtually the same on-chain footprint as a single-key spend: one x-only public key and one BIP340 signature. This reduces the amount and cost of verification compared to implementing an n-of-n policy via separate keys/signatures in [unclear text]  OP_CHECKSIGADD, and also hides the number of participants from a blockchain observer.

9. Limitations and Conclusions

MuSig2 solves a specific problem: compact, Schnorr-compatible, interactive signature of all predetermined participants in two rounds. It does not eliminate the need for online coordination of the second round, does not provide availability in the event of one participant’s failure, and does not transform the n-of-n policy into a t-of-n one.

The scientific value of this work lies in the precise connection between design and cryptanalysis. Two nonce components and a hash-dependent coefficient  b are not a cosmetic modification, but a minimalistic response to ROS attacks in competitive sessions; key coefficients eliminate the rogue-key class; and the proof formalizes security in ROM based on the OMDL premise. Therefore, MuSig2 should be viewed both as a successful engineering protocol for the Taproot ecosystem and as an example of how the security of multiparty cryptography is determined not only by the strength of ECDLP but also by the transcript, concurrency, nonce state, and proof model.

Literature

MuSig2: scientific basis, two-round protocol and safety:  https://monism.ru/musig2-scientific-basis-two-round-protocol-and-safety/

1. J. Nick, T. Ruffing, Y. Seurin.  MuSig2: Simple Two-Round Schnorr Multi-Signatures . IACR Cryptology ePrint Archive, Report 2020/1261; CRYPTO 2021, LNCS 12825, pp. 189–221.  https://eprint.iacr.org/2020/1261 .
2. M. Drijvers, K. Edalatnejad, B. Ford, E. Kiltz, J. Loss, G. Neven, E. Stepanovs.  On the Security of Two-Round Multi-Signatures . IEEE S&P, 2019.
3. D. Wagner.  A Generalized Birthday Problem . CRYPTO 2002.
4. BIP 327.  MuSig2 for BIP340-compatible Multi-Signatures .  https://bitcoin.org/bip/327/ .
5. BIP 340.  Schnorr Signatures for secp256k1 .