<p><strong>Note:</strong> <em>This is meant as an extended comment but was too long. I can unfortunately not directly answer your question</em>.</p>

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

<p><strong>Schnorr signatures has three "levels" of signature manipulations.</strong> </p>

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

<p>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.</p>

<p>In case you haven't seen <a href="https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/#signature-aggregation" rel="nofollow noreferrer">this</a> blog-post yet, there are also many good references at the bottom.</p>

CC BY-SA 4.0
2019-09-02T10:26:32.167Z
2019-09-02T10:26:32.167Z
Bjarne Magnussen
<p>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.</p>

<p>Schnorr allows you to "aggregate" multiple signatures into only <em>one</em> 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.</p>

<p>Take a look at <a href="https://crypto.stackexchange.com/a/50450/67204">this answer</a> 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.</p>

CC BY-SA 4.0
2019-04-06T16:23:57.250Z
This does not answer the question (which is about cross-input aggregation; not just within-input-key-aggregation).
Pieter Wuille
CC BY-SA 4.0
2019-10-03T08:09:54.453Z
@PieterWuille do you mind answering it, then?
Agis
CC BY-SA 4.0
2019-04-05T05:02:43.440Z
2019-04-05T05:08:50.560Z
2019-04-05T05:08:50.560Z
Coding Enthusiast
<p>I am studying the MuSig protocol and am having trouble grasping certain segments. This is my understanding thus far:</p>

<p>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.</p>

<p>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.</p>

<p>The 2018 Blockstream <a href="https://blockstream.com/2018/01/23/en-musig-key-aggregation-schnorr-signatures/" rel="noreferrer">blog post</a> states:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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. </p>

<schnorr-signatures><musig><cross-input-signature-aggregation>
How could Schnorr signatures be aggregated across the whole transaction?
Jayyy777
# How could Schnorr signatures be aggregated across the whole transaction?

(Asked by: username_0 on 2019-04-04)

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](https://blockstream.com/2018/01/23/en-musig-key-aggregation-schnorr-signatures/) 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.

**Tags:** schnorr-signatures, musig, cross-input-signature-aggregation


---

## 2 answers

### Answer by username_1 on 2019-09-02. Score: 1

**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](https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/#signature-aggregation) blog-post yet, there are also many good references at the bottom.


---

### Answer by username_2 on 2019-04-05. Score: 0

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](https://crypto.stackexchange.com/a/50450/67204) 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.

> **Comments:**
> **username_3**: This does not answer the question (which is about cross-input aggregation; not just within-input-key-aggregation).  
> **username_4**: @username_3 do you mind answering it, then?  

---

