Oddbean

I remember thinking "I don't know if that's possible" but also thinking "does that question make sense"? If i use some xor/whatever to make 3 shards, don't I still have the original secret key. If that doesn't matter, and you just want the others to attest, or something, then just use their own keys? I guess I just don't get your point. Obviously both N of N and M of N collaborative control of newly generated keys is well understood (albeit a bit complicated!).

The point is that I have my own secret key that I generated, but it's annoying and unsafe to paste it in Nostr apps everywhere -- and we want people to use multiple apps for multiple tasks, all with the same identity. So the solution is to have the NIP-46 bunker thing that keeps listening for requests to sign coming from authorized apps. But I don't want to run such a bunker daemon, I have no idea of how to do it, it's annoying blablabla; therefore I want to delegate that task to some third-party to run this daemon for me. But I don't want to give this third-party my key, it would be much better if I could split my key in 3 once, give 1 shard to a different provider and trust that they won't collude to recreate my key -- but then they cooperate to sign stuff on my behalf and is as if it was me who signed it.

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.

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.