I am studying the MuSig protocol and am having trouble grasping certain segments. This is my understanding thus far:

In current Bitcoin CHECKMULTISIG format, the size of the signature grows linearly with the number of additional "m" signers. The way CHECKMULTISIG works is that each signer produces their own independent signature, and we embed all these individual values in the scriptsig. So, a 3 of 5 unlocking script might read [sig 1][sig 2][sig 5]...for simplicity sake I will be calling this compilation of all individual sig values the "group signature". In the given example, this signature field would be 3x the length of a standard P2PKH.

In a "naive" Schnorr multisignature scheme, rather than dropping all the potential public keys and [much larger] group signature onto the blockchain for verifier computation, we can have the signers interactively sum their individual public keys in a precommitment phase to derive a single "aggregate" key, that reads synonymously to a traditional public key. An outside member could then send BTC to this aggregate key, where it would be controlled by the group members. For the group to spend, each party would create a partial signature using their unique personal keys, and interactively sum all these signature values to create a group signature. At this point, we are left with a group signature (that is the size of a basic P2PKH sig) and aggregate public key being appended to the blockchain, providing us great space savings. However, this scheme is insecure unless operating under a KOSK model. We turn to another Schnorr variant, MuSig, that can offer provably secure key aggregation while operating in the plain public key context.

The 2018 Blockstream blog post states:

Instead of restricting ourselves to one signature per input, we can actually get one signature for the entire transaction. Key aggregation can’t be used across multiple inputs, as the public keys are committed to by the outputs, and those can be spent independently.

I am having trouble understanding this paragraph. I am guessing that each aggregate key must be referenced in the scriptsig, since the previous sender's scriptpubkey would have mandated proof in order to unlock the encumbrance. I am struggling to understand how the aggregated signature across multiple inputs part is accomplished.

2 Answers 2


Note: This is meant as an extended comment but was too long. I can unfortunately not directly answer your question.

But just to be sure you understand the differences in the Schnorr proposal (because your question is actually not about MuSig):

Schnorr signatures has three "levels" of signature manipulations.

  1. Inside Script itself (such as using MuSig with aggregation of its signatures inside a script),
  2. In the block-validation Schnorr allows batch-validation of its signatures inside a block. This is much faster than validating signatures individually,
  3. Within a transaction Schnorr allows aggregation of signatures from different inputs in the same transaction.

Your question is regarding point 3, and as far as I know has not yet been formalized with a BIP and is still under development.

In case you haven't seen this blog-post yet, there are also many good references at the bottom.


This is a feature of Schnorr digital signatures (ECSDSA) that did not exist in the digital signature scheme (ECDSA) that we are currently using. You should not compare the two multisig schemes together, the current design is a workaround.

Schnorr allows you to "aggregate" multiple signatures into only one signature by combining both private/public keys in the process of signing and produce a single signature (r,s) based on them. As a result you should only see one signature and one public key in your Schnorr transaction scriptSig and the output scripts (scriptPubkey) should also only use a single public key.

Take a look at this answer for a simplified collective signature scheme to get the general idea of how we only have one signature/pubkey, MuSig adds some additional steps to this process to prevent certain attacks.

  • 6
    This does not answer the question (which is about cross-input aggregation; not just within-input-key-aggregation). Apr 6, 2019 at 16:23
  • @PieterWuille do you mind answering it, then?
    – Agis
    Oct 3, 2019 at 8:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.