BA-07 · LESSON 07

MuSig and key aggregation

KEY DEFINITIONS

Terms used in this lesson

MuSig: A multi-party Schnorr-signing protocol that combines several public keys into one aggregate key.
Schnorr signature: Bitcoin’s Taproot signature scheme, whose algebra supports compact verification and advanced multi-party signing.
BIP327: The Bitcoin Improvement Proposal specifying the MuSig2 multi-party Schnorr-signing protocol.
BIP340: The Bitcoin Improvement Proposal specifying Schnorr signatures for the secp256k1 curve.

Interactive multisignature schemes aggregate public keys and signatures while defending against rogue-key attacks.

55 min Difficulty 2/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · taproot treeAn internal key and hidden script tree commit one Taproot outputSelect any state to inspect its exact role.

RELATIONSHIP MAPCommitment and derivation tree

01
INTERNAL KEYX-only point P
The internal public key is combined with a tagged commitment to the script tree.
02
TAPTREETapLeaf and TapBranch
Leaf scripts are hashed and branches are ordered before hashing.
03
TWEAKH(P || root)
The tagged TapTweak hash becomes a scalar added to the internal key.
04
OUTPUT KEYMuSig and key aggregation
The MuSig and key aggregation lesson identifies which committed data must be reconstructed.
05
SPENDSignature or leaf proof
Key path reveals no script; script path reveals one leaf and its Merkle siblings.

Rule shown: A key-path signature or a revealed leaf plus control block must reconstruct the committed output key.

STAGE 1 OF 5INTERNAL KEY: X-only point P

The internal public key is combined with a tagged commitment to the script tree.

Governing relationship: A key-path signature or a revealed leaf plus control block must reconstruct the committed output key. Complete path: 1. INTERNAL KEY, X-only point P. The internal public key is combined with a tagged commitment to the script tree. 2. TAPTREE, TapLeaf and TapBranch. Leaf scripts are hashed and branches are ordered before hashing. 3. TWEAK, H(P || root). The tagged TapTweak hash becomes a scalar added to the internal key. 4. OUTPUT KEY, MuSig and key aggregation. The MuSig and key aggregation lesson identifies which committed data must be reconstructed. 5. SPEND, Signature or leaf proof. Key path reveals no script; script path reveals one leaf and its Merkle siblings.

1. State transitionWhat exists, what changes, and what results

BEFORE

Alice publishes public key A. Without coefficient binding, Mallory tries to register M = B - A so the naive aggregate A + M equals a key B Mallory controls.

MECHANISM

Participants agree on an ordered key list. Hash-derived coefficients weight each key before summing them into the aggregate key.

AFTER

Schnorr linearity enables aggregation, but secure key and nonce binding make that linearity safe against malicious participants.

Text equivalent: Starting from Alice publishes public key A. Without coefficient binding, Mallory tries to register M = B - A so the naive aggregate A + M equals a key B Mallory controls. The mechanism begins when Participants agree on an ordered key list. Hash-derived coefficients weight each key before summing them into the aggregate key. The resulting lesson is Schnorr linearity enables aggregation, but secure key and nonce binding make that linearity safe against malicious participants.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 6

Collect and bind public keys

Participants agree on an ordered key list. Hash-derived coefficients weight each key before summing them into the aggregate key.

Complete path: 1. Collect and bind public keys: Participants agree on an ordered key list. Hash-derived coefficients weight each key before summing them into the aggregate key. 2. Create session nonces: Each signer derives fresh secret nonces for the exact message and session, then exchanges public nonce commitments or nonces under the selected MuSig version. 3. Aggregate nonces: Public nonces combine with protocol-defined coefficients into one aggregate nonce, with parity handled for BIP340 verification. 4. Create partial signatures: Each signer combines its nonces, weighted private key, and common challenge into a partial signature for the same message. 5. Verify and aggregate: Partial signatures can be checked and summed into one BIP340-compatible signature under the aggregate public key. 6. Handle interruption safely: Aborted sessions must not cause secret nonce reuse. Signers bind state to session identifiers and destroy used nonce material.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

Pinned BIP327 MuSig2 v1.0.3 binds the ordered compressed keys, coefficients, two public nonces, message, aggregate nonce, partial equations, and final BIP340 signature.

CHANGED CONDITION

Rogue-key cancellation, reused secret nonce, changed session, or invalid partial signature aborts before aggregation and used nonce state is destroyed.

Important distinction: Adding Schnorr public keys and signatures is sufficient for secure multisignature. Naive addition enables rogue-key and nonce attacks. MuSig specifies key aggregation, nonce handling, message binding, partial verification, and session rules.

Text equivalent: The accepted path is enforced by Pinned BIP327 MuSig2 v1.0.3 binds the ordered compressed keys, coefficients, two public nonces, message, aggregate nonce, partial equations, and final BIP340 signature. If the required condition changes, Rogue-key cancellation, reused secret nonce, changed session, or invalid partial signature aborts before aggregation and used nonce state is destroyed.

Loading lesson visuals...

Learn the idea

MuSig is a family of interactive Schnorr multisignature protocols that combines several public keys into one aggregate public key and produces one aggregate signature. BIP327 is the Bitcoin Improvement Proposal that specifies MuSig2. Key coefficients defend against rogue-key attacks, where a malicious participant chooses a key that algebraically cancels others. Nonce commitments and session binding defend against nonce manipulation.

GUIDED EXPLANATION1/6 ideas inspected

Collect and bind public keys

Participants agree on an ordered key list. Hash-derived coefficients weight each key before summing them into the aggregate key.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Adding Schnorr public keys and signatures is sufficient for secure multisignature.”

Naive addition enables rogue-key and nonce attacks. MuSig specifies key aggregation, nonce handling, message binding, partial verification, and session rules.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.