<p>TL;DR: depending on what you mean, there is probably no published scheme with a security proof, but there is hope for such a scheme.</p>
<h4>First, a few clarifications</h4>
<p><strong>Aggregation</strong> is just a concept, not an actual protocol, and there are many ways of accomplishing that. It is made significantly simpler due to Schnorr's linearity property, but the security of a scheme depends on the specifics of the protocol, and cannot be answered generically.</p>
<p>Signature aggregation and key aggregation are not the same thing, and perhaps you're confusing them:</p>
<ul>
<li><strong>Signature aggregation</strong> is the ability for multiple signers to jointly produce a single compact signature that can be verified by a verifier that knows all the public keys and messages (as each signer can choose their own message). While signature-aggregation of <a href="https://cseweb.ucsd.edu/%7Emihir/papers/multisignatures.pdf" rel="noreferrer">variants of Schnorr</a> signatures can be constructed, Bitcoin's Schnorr functionality (<a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki" rel="noreferrer">BIP340</a>) does <em>not</em> support this.</li>
<li>A <strong>multi-signature</strong> scheme is like a signature aggregation scheme, except that all signers are signing the same message. Note that this isn't the same as what is called &quot;multisig&quot; in the context of Bitcoin.</li>
<li><strong>Key aggregation</strong> is a multi-signature scheme for which the result can be verified by a verifier who only knows some aggregation <em>of the keys</em>. BIP340 is compatible with these (because the verifier is a simple Schnorr verifier that sees a single key), in the form of the MuSig family of algorithms (<a href="https://eprint.iacr.org/2018/068" rel="noreferrer">MuSig</a>, <a href="https://eprint.iacr.org/2020/1261" rel="noreferrer">MuSig2</a>, <a href="https://eprint.iacr.org/2020/1057" rel="noreferrer">MuSig-DN</a>), or <a href="https://eprint.iacr.org/2018/483.pdf" rel="noreferrer">MSDL-pop</a>. However, it's important to note that these protocols consist of multiple algorithms:
<ul>
<li>There is the <strong>key aggregation function</strong>, which given a number of public keys, computes the aggregate key for those (it is generally not just adding the keys together).</li>
<li>There is the <strong>signing protocol</strong>, which consists typically of multiple rounds of interactions between the signers (2 or 3), and the final outcome is a single signature valid for the aggregate key. It is <em>not</em> simply &quot;adding up the signatures&quot;, and having things magically work.</li>
</ul>
</li>
</ul>
<h4>Defining your question</h4>
<p>I'm going to interpret your question as follows:</p>
<blockquote>
<p>Does a secure key-aggregation scheme, compatible with Bitcoin's BIP340 signatures, exist where keys can be aggregated hierarchically without signers having knowledge about their &quot;niece/nephew&quot; keys (i.e., permits signing with key <code>agg(B,K1)</code> where <code>K1=agg(C,D)</code>, but <code>B</code> does not need to be aware of the fact that <code>K2</code> is an aggregate on its own or of the identity of <code>C</code> and <code>D</code>).</p>
</blockquote>
<p>This &quot;without knowledge about&quot; part is essential. Without that part, a trivial solution exists: just &quot;flatten&quot; all the nesting (i.e., transform it into signing with <code>agg(B,C,D)</code> in the example above).</p>
<p>Note that all Schnorr key aggregation schemes require signers to be aware of at least the aggregated key they're signing for, and interact with their co-signers, so it's certainly not possible to accomplish in a setting where signers don't have knowledge about their <em>siblings</em> even.</p>
<h4>Back to your question</h4>
<p>As far as I know, no published scheme actually describes security in the nested settings.</p>
<p>However, <strong>MuSig2</strong> was actually specifically designed to be compatible with nesting. The MuSig2 paper does not describe nesting because the nesting construction has no security proof yet (confirmed by Tim Ruffing in a comment below), and other advantages of MuSig2 over MuSig made it worth publishing on its own. (I know this from private communication with the paper's authors).</p>
<p>What this means is that it is fairly simple to modify the MuSig2 scheme to do what you're asking for (but, beware, there is no published security proof, so while it may <em>work</em> in that it produces valid signatures, that doesn't mean it doesn't open up the signers to attacks):</p>
<ul>
<li>The aggregation function is allowed to be nested (i.e., can be applied on a key that is itself the result of aggregation).</li>
<li>In the first signing round, the &quot;leaves&quot; of the hierarchy produce 2 (or 4) nonces as normal, and send them &quot;upwards&quot; the tree. The inner nodes of the tree simply add them point-wise (i.e., given (R1a, R2a), (R1b, R2b) from sub-signers a and b, send on (R1a+R1b, R2a+R2b)).</li>
<li>In the second signing round, the multipliers do not depend on just the aggregate key, but on all intermediary aggregate keys between the signer and the root of the tree as well.</li>
</ul>
<p>This is not possible with MuSig (1), because it has a precommitment round where all signers publish a hash of the nonce they're going to use. Given the hashes of the nonces of your &quot;children&quot;, you cannot compute the hash of their sum. Trying to avoid this problem by first running both round 1 and 2 of the children before running round 1 of the parent is known to be insecure (other signers can trick you into revealing your private key this way).</p>

CC BY-SA 4.0
2021-11-30T21:20:58.617Z
The CoSi scheme supported this kind of nested aggregation but was broken by https://eprint.iacr.org/2020/945.pdf. However, it was broken not because of the nested key aggregation but because of the same reasons why the initial version of MuSig1 was broken. And these issues have been resolved with MuSig2. So we (the MuSig2 authors) conjecture that the protocol you sketch here is secure but noone has worked out a formal security proof so far.
real-or-random
CC BY-SA 4.0
2021-11-30T20:31:00.580Z
2021-12-01T14:38:12.690Z
2021-12-01T14:38:12.690Z
Pieter Wuille
<p>The way I've understood Schnorr signatures is that multiple parties can combine their signatures into a one shared signature, thus obfuscating the number of participants involved in the signature scheme.</p>
<p>I wonder: is it possible for one of those signatures to <em>itself</em> be an aggregate signature? And can we keep on doing this multiple levels down?</p>
<p>EDIT: Here's a diagram to clarify my question. The grey nodes represent aggregate signatures, the black nodes represent keys/entities. In this example, A doesn't necessarily need to know all the complexity hidden below K2.</p>
<p><a href="https://i.sstatic.net/syIql.png" rel="noreferrer"><img src="https://i.sstatic.net/syIql.png" alt="enter image description here" /></a></p>

<script><multi-signature><taproot><schnorr-signatures>
Can Schnorr aggregate signatures be nested inside other Schnorr aggregate signatures?
max
# Can Schnorr aggregate signatures be nested inside other Schnorr aggregate signatures?

(Asked by: username_0 on 2021-11-20)

The way I've understood Schnorr signatures is that multiple parties can combine their signatures into a one shared signature, thus obfuscating the number of participants involved in the signature scheme.

I wonder: is it possible for one of those signatures to *itself* be an aggregate signature? And can we keep on doing this multiple levels down?

EDIT: Here's a diagram to clarify my question. The grey nodes represent aggregate signatures, the black nodes represent keys/entities. In this example, A doesn't necessarily need to know all the complexity hidden below K2.

[![enter image description here](https://i.sstatic.net/syIql.png)](https://i.sstatic.net/syIql.png)

**Tags:** script, multi-signature, taproot, schnorr-signatures


---

## 1 answers

### Answer by username_1 on 2021-11-30. Score: 10 | Accepted answer

TL;DR: depending on what you mean, there is probably no published scheme with a security proof, but there is hope for such a scheme.

#### First, a few clarifications

**Aggregation** is just a concept, not an actual protocol, and there are many ways of accomplishing that. It is made significantly simpler due to Schnorr's linearity property, but the security of a scheme depends on the specifics of the protocol, and cannot be answered generically.

Signature aggregation and key aggregation are not the same thing, and perhaps you're confusing them:

* **Signature aggregation** is the ability for multiple signers to jointly produce a single compact signature that can be verified by a verifier that knows all the public keys and messages (as each signer can choose their own message). While signature-aggregation of [variants of Schnorr](https://cseweb.ucsd.edu/%7Emihir/papers/multisignatures.pdf) signatures can be constructed, Bitcoin's Schnorr functionality ([BIP340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki)) does *not* support this.
* A **multi-signature** scheme is like a signature aggregation scheme, except that all signers are signing the same message. Note that this isn't the same as what is called "multisig" in the context of Bitcoin.
* **Key aggregation** is a multi-signature scheme for which the result can be verified by a verifier who only knows some aggregation *of the keys*. BIP340 is compatible with these (because the verifier is a simple Schnorr verifier that sees a single key), in the form of the MuSig family of algorithms ([MuSig](https://eprint.iacr.org/2018/068), [MuSig2](https://eprint.iacr.org/2020/1261), [MuSig-DN](https://eprint.iacr.org/2020/1057)), or [MSDL-pop](https://eprint.iacr.org/2018/483.pdf). However, it's important to note that these protocols consist of multiple algorithms:
  + There is the **key aggregation function**, which given a number of public keys, computes the aggregate key for those (it is generally not just adding the keys together).
  + There is the **signing protocol**, which consists typically of multiple rounds of interactions between the signers (2 or 3), and the final outcome is a single signature valid for the aggregate key. It is *not* simply "adding up the signatures", and having things magically work.

#### Defining your question

I'm going to interpret your question as follows:

> Does a secure key-aggregation scheme, compatible with Bitcoin's BIP340 signatures, exist where keys can be aggregated hierarchically without signers having knowledge about their "niece/nephew" keys (i.e., permits signing with key `agg(B,K1)` where `K1=agg(C,D)`, but `B` does not need to be aware of the fact that `K2` is an aggregate on its own or of the identity of `C` and `D`).

This "without knowledge about" part is essential. Without that part, a trivial solution exists: just "flatten" all the nesting (i.e., transform it into signing with `agg(B,C,D)` in the example above).

Note that all Schnorr key aggregation schemes require signers to be aware of at least the aggregated key they're signing for, and interact with their co-signers, so it's certainly not possible to accomplish in a setting where signers don't have knowledge about their *siblings* even.

#### Back to your question

As far as I know, no published scheme actually describes security in the nested settings.

However, **MuSig2** was actually specifically designed to be compatible with nesting. The MuSig2 paper does not describe nesting because the nesting construction has no security proof yet (confirmed by Tim Ruffing in a comment below), and other advantages of MuSig2 over MuSig made it worth publishing on its own. (I know this from private communication with the paper's authors).

What this means is that it is fairly simple to modify the MuSig2 scheme to do what you're asking for (but, beware, there is no published security proof, so while it may *work* in that it produces valid signatures, that doesn't mean it doesn't open up the signers to attacks):

* The aggregation function is allowed to be nested (i.e., can be applied on a key that is itself the result of aggregation).
* In the first signing round, the "leaves" of the hierarchy produce 2 (or 4) nonces as normal, and send them "upwards" the tree. The inner nodes of the tree simply add them point-wise (i.e., given (R1a, R2a), (R1b, R2b) from sub-signers a and b, send on (R1a+R1b, R2a+R2b)).
* In the second signing round, the multipliers do not depend on just the aggregate key, but on all intermediary aggregate keys between the signer and the root of the tree as well.

This is not possible with MuSig (1), because it has a precommitment round where all signers publish a hash of the nonce they're going to use. Given the hashes of the nonces of your "children", you cannot compute the hash of their sum. Trying to avoid this problem by first running both round 1 and 2 of the children before running round 1 of the parent is known to be insecure (other signers can trick you into revealing your private key this way).

> **Comments:**
> **username_2**: The CoSi scheme supported this kind of nested aggregation but was broken by https://eprint.iacr.org/2020/945.pdf. However, it was broken not because of the nested key aggregation but because of the same reasons why the initial version of MuSig1 was broken. And these issues have been resolved with MuSig2. So we (the MuSig2 authors) conjecture that the protocol you sketch here is secure but noone has worked out a formal security proof so far.  

---

