Key Generation and Aggregation

Round zero is key setup. Every leaf signer samples a secret scalar $sk$ and publishes a public key:

So far this is normal Schnorr key generation. The NestedMuSig2-specific behavior starts when we aggregate keys at each internal node.

MuSig-style aggregation cannot be a simple point sum, because that would allow rogue-key attacks. Instead, each key gets a coefficient derived from the full key list for that aggregation context:

where $L$ is the local key multiset and $X_i$ is one member key. The hash input is order-independent in practice because implementations sort keys before hashing. The aggregate key is then:

In implementation terms this is a multi-scalar multiplication over the child points and their coefficients.

The recursive insight is that an internal node’s aggregate key becomes a normal key in its parent list. Suppose Group B contains Bob and Carol:

At the root, if children are Alice, Group B, and Group C:

Substituting X̃_B and X̃_C expands the root key into weighted contributions from all leaves. This is why the tree composes algebraically: every level uses the same rule, and each child output is still an elliptic curve point.

Notice that coefficients are local to each level. A signer’s public key can appear in multiple derived expressions through ancestor aggregation, but each coefficient comes from that level’s own list $L$. This locality is exactly what Round 2 will later reconstruct for cascading challenge terms.

From a systems view, key aggregation gives you two benefits. First, rogue-key resistance remains intact at each aggregation boundary. Second, the parent node never needs to inspect internal details of a subtree. It only consumes the subtree aggregate key as one input to its own aggregation.

The demo below regenerates three keys, computes each $a_i$, and shows the final aggregate key X̃.