OK yes I see. It seems difficult because a musig aggregated key is not a linear sum, to avoid the possibility that less than N can forge a full signature using key subtraction attacks. Constructing the key is an interactive process that produces an unpredictable final key, by design.

Perhaps you can attach a proof of knowledge of each "key portion" works though: you distribute secret keys x1, x2 and x3 such that x1 + x2 + x3 =x, your key. Then when they go through the signing process they add a signature over their key portion at the start. This prevents them from doing key subtraction to forge with < N parties. Then they can go through the normal process of 3 round MuSig - commit to their R portion, then reveal their R, then the final signature on P is the sum of the signatures on P1, P2, P3. Two obvious problems stand out: they can collude to extract your full key; usually that is not acceptable. And of course the fact that signing becomes interactive.

Overall it doesn't seem very practical, and heck, don't even quote me that it's possible or sound, I'm not sure. Even with the massive caveats above. Various kinds of delegation or setup with the initial key, whether using existing FROST or MuSig, feel like they make for a sounder approach. 

 I think we could make it so the possibility of these entities colluding is small and then tradeoff is reasonable for most people (but not for all, of course) -- the alternative of trusting a single provider to hold absolute power over your entire identity, like x.com, is far worse.

I don't get what you mean by "various kinds of delegation or setup with the initial key". What do you have in mind there? 

 About initial setup/delegation, my thinking is: a protocol could allow you to delegate authority to do specific things (like sign) by a direct signature on your main key saying "this sub-key is authorised to sign these events" and then that subkey could be generated collaboratively in a normal way. Common way of using digital signatures (delegation to another key), but admittedly it can be a can of worms... 

 A bunch of proposals for variants of doing that stuff have been (and continnue to be) suggested. I don't know what is the best way (they all look flawed to me given that there is no single source of truth for what is the latest update on the subkeys of each person) -- but even with all that decided and solved I think it's a bad idea because it would add so much complexity to clients and/or relays that Nostr would essentially cease to work or instantly centralize around a single big entity that would become the central source of all truth and the almighty index of all events. That's why I'm considering these other ways. 

 Understood. I agree it's a can of worms to do it at scale. Maybe for some smaller scale projects it can be a valid choice. 

 Subkeys will be time boxed like X.509 certificates or GPG subkeys have done for centuries.

Nostr won't stop existing but if this upgrade flushes some of the nincompoop devs out of the community that can't handle something this simple then that's a win-win.