Abstract.  Gregory Maxwell, Andrew Poelstra, Yannick Seurin, and Pieter Wuille introduced MuSig, an n-of-n multi-signature scheme based on Schnorr, in which the joint signature and aggregated public key are the size of regular Schnorr objects. The central cryptographic idea is the deterministic weighting of keys by a hash function: this eliminates rogue-key attacks, preserves the “plain public key” model, and makes the result verifiable as a single standard signature. This paper systematizes the design, security model, historical cryptanalytic lessons of the early two-round version, and the implications of the scheme for Bitcoin.

Keywords:  MuSig, Schnorr, multi-signature, key aggregation, signature aggregation, rogue-key attack, discrete logarithm, secp256k1, Bitcoin, nonce, cryptanalysis.

Structure:  problem statement; Schnorr; aggregation and key spoofing attack; MuSig protocol; security; cryptanalytic fact of 2018; Bitcoin; engineering risks; comparative analysis; conclusions.

1. Object and boundaries of the study

The source of the study is ePrint 2018/068, subsequently published in  Designs, Codes and Cryptography  (2019). In the current edition, the authors highlight an important historical correction: the originally proposed two-round version had a flaw in the security proof; the text was revised in favor of a three-round version, for which a proof is given under the assumption that discrete logarithm hardness.

MuSig should be distinguished from threshold signatures: in the described basic design, all participants must participate, meaning an n-of-n policy is implemented. Threshold variants require additional distributed key generation, secret share processing, and a different failure model.

2. Algebraic basis of Schnorr

Let  G be the generator of the cyclic group of prime order  qused in Bitcoin (effectively, the point group secp256k1). Each signer chooses a secret scalar  x_i ∈ Z_q and publishes a point  X_i = x_iG. Security relies on the computational difficulty of recovering  x_i from  X_i, i.e., the discrete logarithm problem.

Secret and public keys: x ∈ Z_q, X = xG

In a typical Schnorr signature, the signer chooses a one-time nonce  r, forms a commitment  R = rG, and computes a challenge  e = H(R || X || m) and response  s = r + ex mod q. The signature is a pair  (R, s); the verifier accepts it when the linear equality below holds.

R = rG; e = H(R || X || m); s = r + ex (mod q)
Check: sG ?= R + eX

Historical cryptanalytic example: nonce repetition

Schnorr’s linearity is useful, but it makes proper nonce handling critical. If one private key signs two messages with the same  r, then   the key is extracted  s_1 = r + e_1x from  . This class of errors has historically manifested itself in ECDSA: nonce repetition allowed private keys to be recovered, notably in the famous PlayStation 3 incident, and in cryptocurrency systems, incorrect random number generators have also led to wallet compromises.s_2 = r + e_2xx = (s_1 − s_2)(e_1 − e_2)^{-1} mod q

When repeating nonce: x = (s₁ − s₂) · (e₁ − e₂)⁻¹ mod q

3. Why is aggregation necessary?

A conventional n-of-n scheme might store n individual signatures and n public keys. Aggregation aims to represent group agreement with a single signature and a single group key: ideally, an external observer sees an object of the same format as a single owner’s signature.

Property	A set of individual signatures	MuSig
Signature on the exit	n signatures	One Schnorr-compatible signature
Key material for verification	List of n keys	Aggregated key X̃
Observed policy	The structure of the participants is clearly revealed	In the correct context, this may appear as a single-key spend.
Main additional protection	Depends on the scheme	Key Ratios vs. Rogue-Key Attacks

4. Naive aggregation and rogue-key attack

A naive aggregate key  X = Σ X_i is insecure if a participant can choose their key after observing the keys of other parties. An attacker with a secret key  x_A publishes  X_A = x_AG − X_V, where  X_V is the key of an honest victim. Then the aggregate is  X_A + X_V = x_AG; the attacker alone creates a signature that appears to be a joint agreement with the victim.

Naive aggregate: X = Σᵢ Xᵢ
Substitute key: X_A = x_A G − X_V
Consequence: X_A + X_V = x_A G

Cryptanalytic interpretation

This isn’t a discrete logarithm attack or finding the victim’s private key. It’s a structural attack against the lack of proof of key ownership: the algebraic freedom to choose a public endpoint is transformed into a substitution of the meaning of the shared key. In PKIs, this risk is typically mitigated by proof of possession, but MuSig sets a stronger goal: not requiring such external proof or certification authority.

5. MuSig design

MuSig associates each public key with a complete ordered list of participants  L. First, is calculated  L = H(X_1 || ... || X_n), then for each key, the coefficient  a_i = H(L || X_i). The aggregated key becomes a weighted sum  X̃ = Σ a_iX_i, and the corresponding implicit aggregated secret is  x̃ = Σ a_ix_i.

L = H(X₁ || X₂ || … || Xₙ)
aᵢ = H(L || Xᵢ)
X̃ = Σᵢ aᵢXᵢ = (Σᵢ aᵢxᵢ)G
x̃ = Σᵢ aᵢxᵢ

The idea behind the protection is that the attacker must choose a key that compensates for the contribution of the honest key after hashing. However, the attacker’s coefficient depends on the key already chosen and the complete list: this creates a self-referential equation in the random oracle model, for which there is no efficient way to construct the required compensation.

Signing rounds

In the provably secure edition, MuSig uses three communication rounds. The first is a commit-reveal for nonces: a participant chooses  r_i, receives  R_i = r_iG , and first broadcasts a commitment  t_i = H(R_i); only then does it reveal  R_i. The second involves revealing nonce points and computing  R = ΣR_i. The third involves issuing partial responses  s_i = r_i + e a_i x_i with a shared challenge  e = H(R || X̃ || m).

tᵢ = H(Rᵢ), Rᵢ = rᵢG, R = ΣᵢRᵢ
e = H(R || X̃ || m)
sᵢ = rᵢ + e aᵢxᵢ mod q
s = Σᵢ sᵢ; σ = (R, s)

The final signature verification matches the form of Schnorr:  sG = R + eX̃. Indeed, summing the partial answers yields  Σr_i + eΣa_ix_i, which, after multiplying by ,  G equals  R + eX̃.

sG = (Σᵢ rᵢ + eΣᵢ aᵢxᵢ)G = R + eX̃

Illustrative code

Below is some sample pseudocode for scalars and group points. It describes the mathematics and  is not  a ready-made library: a real implementation must use the proven secp256k1 library, strong point encoding, tagged hashes, nonce replay protection, and verification of all partial signatures.

# Учебный псевдокод MuSig n-of-n
L = H(encode(X[0]) || ... || encode(X[n-1]))
a[i] = H_to_scalar(L || encode(X[i]))
Xagg = sum(a[i] * X[i] for i in range(n))

# Раунд 1 и 2: commit-reveal nonce
r[i] = secure_fresh_nonce(i, session_id, message)
R[i] = r[i] * G
commit[i] = H(encode(R[i]))
assert all(H(encode(R[i])) == commit[i] for i in range(n))
R = sum(R[i] for i in range(n))

e = H_to_scalar(encode(R) || encode(Xagg) || message)
s[i] = (r[i] + e * a[i] * x[i]) % q
assert s[i] * G == R[i] + e * a[i] * X[i]  # до агрегации
s = sum(s[i] for i in range(n)) % q
assert s * G == R + e * Xagg

Practical Scenario: Corporate Reserve

Consider a Bitcoin reserve controlled by three independent company departments: the CFO, the security department, and an external custodian. Under a 3-of-3 policy, each party generates their own signature only after the transaction has been agreed upon; the result is a single signature under an aggregated key, rather than three independent signatures. The cryptanalytic meaning of the coefficients  a_i here is straightforward: an external custodian cannot choose a “tricky” public key that would allow them to unilaterally imitate the agreement of the other two parties.

6. Evidence-based safety model

The authors formulate security using a plain public-key model: before interaction, participants only need to provide a public key, without proof of ownership. This is essential for open, decentralized systems, where the requirement to interactively prove ownership of each key may be inconvenient or absent from the protocol.

The proof links successful forgery of an aggregated signature to solving the discrete logarithm problem in a group, modeling hash functions as random oracles. It’s important not to overstate the result: this is a conditional reduction in an explicitly defined model, not an absolute proof of the security of a specific source code, communication channel, or random number generator.

7. Cryptanalytic Fact: Why Early MuSig Was Revised

The original preprint claimed a two-round construction. In 2018, a paper by Drijvers et al. on the provable security of two-round multisigs pointed out subtle flaws in a number of published proofs and demonstrated a barrier to algebraic reductions under standard assumptions. Subsequently, the authors of MuSig explicitly labeled the earlier proof as flawed. The wording of the source is important: no known practical attack on that version was claimed, yet the security proof was not considered achievable by known methods.

Methodological conclusion.  “No hack found” and “the scheme has a valid proof” are different statements. For a cryptographic protocol, the absence of a published exploit is no substitute for a rigorous adversary model, reduction, and concurrent session analysis.

A more recent development is MuSig2 (Ruffing, Seurin, 2020/2021): a practical two-round scheme that claims security for concurrent sessions, key aggregation, and a standard Schnorr signature format. Therefore, in modern projects, it is unacceptable to unconditionally migrate the early MuSig details from ePrint 2018/068 to production: the current specification and a proven implementation of the chosen protocol generation should be used.

8. Significance for Bitcoin

For Bitcoin, the MuSig effect consists of compressing a shared authorized spend into a standard Schnorr signature. This potentially reduces the data volume, reduces the verification burden, and improves privacy: the on-chain result makes it harder to distinguish a shared authorization from a single one, unless the scenario and the environment itself reveal other clues.

However, an aggregated signature does not automatically anonymize participants. Network observability, address reuse, input composition, broadcast time, leaks through the coordination server, and wallet metadata remain independent channels for deanonymization; MuSig primarily addresses the cryptographic representation of authorization.

9. Real failure classes

Risk	Mechanism	Historical and practical context	Countermeasure
Rogue-key	The key is selected as compensation for someone else’s key	The classical problem of naive linear aggregation without proof of possession	Weighted MuSig aggregation, canonical key list
Nonce reuse	One nonce participates in two different challenges	Nonce repetition or predictability in ECDSA has historically revealed secret keys; the principle of linear derivation applies to Schnorr	One-time nonces, session binding, secure state storage
Nonce cancellation / adaptability	The last participant selects a nonce after others’ reveals	Reason for commit-reveal: Without commitment, message ordering becomes an attack surface	First commitments, then nonce points
Message substitution	Partial answer is not given for that m	Particularly dangerous for offline signatories and coordinators	Include m, R, X̃, and the session ID in the context being checked
Implementation errors	Incorrect serialization, missing checks, side-channel leaks	Mathematical robustness does not eliminate API and code defects	Standard libraries, test vectors, constant-time operations, auditing

10. Test algorithm and session discipline

Before summing, the coordinator or each participant must verify each partial signature:  s_iG ?= R_i + ea_iX_i. This verification localizes a faulty or malicious participant and prevents the error from being masked in the final aggregate.

def verify_partial(s_i, R_i, a_i, X_i, e):
    return s_i * G == R_i + (e * a_i) * X_i

# Привязка nonce к контексту должна исключать повтор
session_id = H("MuSig" || protocol_version || L || Xagg || tx_digest || counter)
r_i = nonce_derivation(secret_nonce_seed, session_id)

In a production protocol, the key list must have an unambiguous canonical representation and order; the same set in different orders represents different contexts  L. The coordinator must not be allowed to surreptitiously change the key list, transaction, or commitment after the hardware wallet has shown the signing details to the user.

11. MuSig, MuSig2 and threshold circuits

Design	The main goal	Interactivity	Key point
MuSig from ePrint 2018/068	n-of-n, key aggregation, provability in a plain public-key model	Three rounds in the revised safe version	The early two-round revision should not be taken as proven safe.
MuSig2	Practical two-round n-of-n multisignature	Two rounds	Later protocol with concurrent sessions analysis
FROST and other threshold-Schnorr	t-of-n with acceptable participant failures	Depends on DKG/pretreatment	This is a different class of problems: secret distribution and threshold policy

12. Practical recommendations

• For a new system, don’t implement an early MuSig implementation “from memory”; use a modern specification, test vectors, and an independently audited library.
• Associate all nonces with a unique session and message; never allow nonces to be reused after a restart or crash.
• Verify partial signatures before aggregation and commit the canonical key list before the nonce phase.
• Consider the coordinator as an untrusted component: it can route messages, but should not solely determine the meaning of the transaction being signed.
• Separate on-chain cryptographic privacy from operational privacy of the network, interfaces, logs, and backups.

13. Conclusion

MuSig was a significant milestone because it demonstrated that Schnorr’s linearity allows for the compression of collective consensus into a single signature without relying on a naive sum of keys. Its central contribution is not only its compactness but also its formalization of how hash-dependent coefficients mitigate rogue-key attacks in a plain public-key model.

The most valuable cryptanalytic lesson of this work is the story of the correction of an early proof of the two-round version. It demonstrates a mature norm in cryptography: protocol security is determined not by the intuitive elegance of formulas, but by the correctness of the model, the analysis of the adaptive adversary, the properties of competitive sessions, and impeccable implementation discipline.

Literature

Study MuSig: Simple Schnorr Multi-Signatures with Applications to Bitcoin:  https://24bitcoin.ru/study-musig-simple-schnorr-multi-signatures-with-applications-to-bitcoin/

1. G. Maxwell, A. Poelstra, Y. Seurin, P. Wuille.  Simple Schnorr Multi-Signatures with Applications to Bitcoin . IACR Cryptology ePrint Archive, Report 2018/068, 2018; published in Designs, Codes and Cryptography, 87(9), 2019. URL:  https://eprint.iacr.org/2018/068 .
2. S. Drijvers et al.  On the Provable Security of Two-Round Multi-Signatures . IACR ePrint 2018/417, 2018.
3. J. Nick, T. Ruffing, Y. Seurin.  MuSig2: Simple Two-Round Schnorr Multi-Signatures . IACR ePrint 2020/1261, 2020.
4. C. Komlo, I. Goldberg.  FROST: Flexible Round-Optimized Schnorr Threshold Signatures . SAC 2020 / Springer, 2021.

---