<p>As Pieter Wuille states <a href="https://twitter.com/pwuille/status/1391118297052041217?s=20" rel="nofollow noreferrer">here</a> key aggregation is completed at address creation time not at signing time or post signing time.</p>
<blockquote>
<p>Of course, key aggregation has an impact on the signing algorithm, and that's probably one of the main reasons why it's useful to do it before CISA: the work needed to support MuSig signing in wallet will take a while, but it's pretty similar to CISA signing.</p>
<p>Why is key aggregation better? Because it means the original keys never end up on chain. With signature aggregation you still have on-chain keys, but with 1 signature....Key aggregation means the consensus rules can be completely oblivious of even the concept of aggregation.</p>
<p>Downside: key aggregation cannot be used cross input, as you can't predict which UTXOs will be spent together.</p>
</blockquote>
<p>Meanwhile signature aggregation is completed at signing time or post signing time, not at address creation time. To implement it it would possibly need a specific opcode that observes multiple keys.</p>
<blockquote>
<p>Signature aggregation implies a verification algorithm that receives a list of (message,pubkey) pairs and a signature.</p>
</blockquote>
<p>You could see key aggregation as a special case of signature aggregation as the aggregated signature is also a valid &quot;single key&quot; signature for the aggregated key. But conceptually there is a huge difference in how they would be implemented.</p>
<blockquote>
<p>Why is it important to be careful to use the correct term in its correct setting?</p>
</blockquote>
<p>The proposed Taproot soft fork does not enable signature aggregation at all (<a href="https://bitcoin.stackexchange.com/questions/100216/what-makes-cross-input-signature-aggregation-complicated-to-implement">cross input</a> or otherwise), it facilitates key aggregation schemes e.g. MuSig. As Pieter says, the consensus rules of Taproot and Schnorr don't have any awareness of aggregation. Hence if you say Taproot enables signature aggregation this is incorrect and will confuse. In addition, when moving onto the discussion of what soft fork(s) could potentially follow Taproot, enabling signature aggregation will be a candidate feature that is seriously considered as the block space savings could be significant. (Note witness data is already discounted post SegWit). Key aggregation allows you to aggregate keys <strong>within one input</strong> but cross input signature aggregation could potentially allow you to aggregate signatures <strong>across inputs</strong>.</p>
<p>Aggregating signatures not only across inputs but <strong>across transactions</strong> could potentially mean only one signature goes onchain for the entire block. However, this is not possible with discrete logarithm based cryptography (see Pieter's comment below). It needs non-interactive aggregation as you can't require transaction authors to cooperate. This aggregation needs to be done by miners.</p>

CC BY-SA 4.0
2021-05-11T23:11:23.740Z
Aggregation across transactions isn't possible with DL-based cryptography (it needs non-interactive aggregation, as you can't require transaction authors to cooperate - this aggregation needs to be done by miners). And the savings of cross-input aggregation aren't that large, as they're witness data that's already discounted.
Pieter Wuille
CC BY-SA 4.0
2021-05-09T11:42:25.667Z
2021-05-12T22:03:07.890Z
2021-05-12T22:03:07.890Z
Michael Folkson
<p>What is the difference between key aggregation (e.g. MuSig) and <a href="https://bitcoin.stackexchange.com/questions/100216/what-makes-cross-input-signature-aggregation-complicated-to-implement">signature aggregation</a>?</p>
<p>Many people (including myself) have in the past used these terms interchangeably. Why is it important to be careful to use the correct term in its correct setting?</p>

<terminology><taproot><schnorr-signatures><musig><cross-input-signature-aggregation>
What is the difference between key aggregation and signature aggregation?
Michael Folkson
# What is the difference between key aggregation and signature aggregation?

(Asked by: username_0 on 2021-05-09)

What is the difference between key aggregation (e.g. MuSig) and [signature aggregation](https://bitcoin.stackexchange.com/questions/100216/what-makes-cross-input-signature-aggregation-complicated-to-implement)?

Many people (including myself) have in the past used these terms interchangeably. Why is it important to be careful to use the correct term in its correct setting?

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


---

## 1 answers

### Answer by username_0 on 2021-05-09. Score: 4 | Accepted answer

As username_1 username_1 states [here](https://twitter.com/pwuille/status/1391118297052041217?s=20) key aggregation is completed at address creation time not at signing time or post signing time.

> Of course, key aggregation has an impact on the signing algorithm, and that's probably one of the main reasons why it's useful to do it before CISA: the work needed to support MuSig signing in wallet will take a while, but it's pretty similar to CISA signing.
>
> Why is key aggregation better? Because it means the original keys never end up on chain. With signature aggregation you still have on-chain keys, but with 1 signature....Key aggregation means the consensus rules can be completely oblivious of even the concept of aggregation.
>
> Downside: key aggregation cannot be used cross input, as you can't predict which UTXOs will be spent together.

Meanwhile signature aggregation is completed at signing time or post signing time, not at address creation time. To implement it it would possibly need a specific opcode that observes multiple keys.

> Signature aggregation implies a verification algorithm that receives a list of (message,pubkey) pairs and a signature.

You could see key aggregation as a special case of signature aggregation as the aggregated signature is also a valid "single key" signature for the aggregated key. But conceptually there is a huge difference in how they would be implemented.

> Why is it important to be careful to use the correct term in its correct setting?

The proposed Taproot soft fork does not enable signature aggregation at all ([cross input](https://bitcoin.stackexchange.com/questions/100216/what-makes-cross-input-signature-aggregation-complicated-to-implement) or otherwise), it facilitates key aggregation schemes e.g. MuSig. As username_1 says, the consensus rules of Taproot and Schnorr don't have any awareness of aggregation. Hence if you say Taproot enables signature aggregation this is incorrect and will confuse. In addition, when moving onto the discussion of what soft fork(s) could potentially follow Taproot, enabling signature aggregation will be a candidate feature that is seriously considered as the block space savings could be significant. (Note witness data is already discounted post SegWit). Key aggregation allows you to aggregate keys **within one input** but cross input signature aggregation could potentially allow you to aggregate signatures **across inputs**.

Aggregating signatures not only across inputs but **across transactions** could potentially mean only one signature goes onchain for the entire block. However, this is not possible with discrete logarithm based cryptography (see username_1's comment below). It needs non-interactive aggregation as you can't require transaction authors to cooperate. This aggregation needs to be done by miners.

> **Comments:**
> **username_1**: Aggregation across transactions isn't possible with DL-based cryptography (it needs non-interactive aggregation, as you can't require transaction authors to cooperate - this aggregation needs to be done by miners). And the savings of cross-input aggregation aren't that large, as they're witness data that's already discounted.  

---

