Oddbean

Pretty sure I agree that FROST is closer to the mark in what @fiatjaf is looking for, but specifically the signing algorithm and not the keygen algorithm. FROST (and Pedersen DKG before it) were advancing the state of the art by allowing for no central party (or aggregator/dealer) to be in possession of the whole private key at any time, either in key generation, or in signing. Here I guess you want to reset back to the earlier SSS basic idea of having the central party know the key in advance, then construct the individual shares such that they sum to the pre-existing key x, instead of following FROST's KeyGen to generate the shares. But the "massive caveats" I mentioned in the other post still apply; it seems unlikely you'd want to allow the possibility to collude to take your full key.

No, I don't want to reconstruct the key, I just want these providers to construct signatures, which apparently FROST can do safely -- I don't get why you can't do that with MuSig2 (wait, I guess it just doesn't work because MuSig2 has the "distributed key generation" step built in). So I, as a user, don't have to do any cryptography or hold any keys during my daily life as a Nostr user, I can just instruct clients to fetch signatures from a server somewhere, and that server will coordinate with the 3 entities that hold my key shards to get a signature, then return the signature to the clients and, boom, I have a signed event.

Re : "No, I don't want to reconstruct the key", I don't really understand; I didn't use the word 'reconstruct' in that. "I just want these providers to construct sigs safely which apparently FROST can do". But the point that's at issue here is you want them to do that with *your* key. FROST and MuSig both allow multiple parties to collaborate to create signatures safely, with the main difference being that the former allows it for t of n and not only n of n. *Neither* provide for the key to come from some central party. As for distributed key gen, yes they both do it, they have to; but they do it in radically different mathematical ways (because of the t of n requirement for a start). And retrofitting them to allow you to start with a key "x" and then split it up and give it to them probably can work, but my caveat point is, if you care that they can collude to take the whole key, between them, then that's not great.** In FROST's case, it happens to be polynomial evaluations that you share, but it's still designed so that t of those shares (in a t of n scheme) are enough to reconstruct your signing key. **In any such collaborative signing scheme, by definition, the key can be reconstructed by the authorised threshold t, because they can share their nonce contributions and extract the private key using the nonce. This isn't usually discussed, but here we have an external party that'd prefer not to be attacked by the group, so to speak.