It's better because your identity remains in the main key. In any other scheme, your identity changes when you rotate keys, including BIP32 derived keys.
How is this better than “simply” having a “master” key pair (like Bip32 “xpub” and “xprv”) that generates disposable pubkeys for use in any client? (where the “xpub” is actually exposed for anyone to verify the “ownership” of generated pubkeys)
AFAF : nostr:npub16v82nr4xt62nlydtj0mtxr49r6enc5r0sl2f7cq2zwdw7q92j5gs8meqha
Discussion
I see you've been fully Frosted. Welcome.
I like Frost, but I need it to work with encryptions.
You mean in the context of encryption decoupled from signing?
Ideally, decryption should not be decoupled from signing. I know FROST doesn't support it. But we need to figure out something that does support. That will be better than decoupling.
Sounds like a tall mathematical order. Maybe (big Maybe) something like Paillier threshold encryption running alongside Frost. But Paillier won't work for an nsec so you'd need a Paillier key pair as an "aux" keypair. And this Paillier setup would be encrypting an AES key on top of that, since using Paillier itself for encryption of long messages won't work. So then you'd be juggling Frost shards and Paillier shards, and in the case of the Paillier shards they'd be shards of an AES key.
Basically the user would need to request from the client another keypair if they wanted to start using NIP44 DMs.
With a good UX it could be abstracted away like how this nstart thing abstracts away all the Frost complexity. Like the whole thing can be behind a single "Do it" button.
Disclaimer: that all could be very wrong. My team looked into Pallier for some contest gamification stuff a while back, it's good for voting on contest entries and stuff, but getting blurry in the memory.
Goodness me, all solved with Frost2x already. Those guys are trolling-ly good.
Not if the “xpub” is made public … and added to events, and clients know to use it?
Requires a NIP for clients to “adopt”… but any other solution also would.
I’m too dumb to know the nuances here… but seems Bip32 is already authored and in use … ready to be adapted for Nostr use?
It will be impossible to get all clients to know how to use it. And if a few don't code it, we will never get enough adoption to completely switch into it.
The beauty of Frost is that all clients already support it. Because everything is solved in the key sharding/signing app. Everything else remains the same.
Yup, Frost is the most elegant backwards-compatible way.
First, that's circular logic. Saying we're not going to implement it because other people might not implement it is just silly.
Second, using a seed and xpub does not require all clients to change their code. In fact, you could do this today with standalone tools and absolutely no code changes (example below).
Third, using an xpub would provide all the features with **less complexity**, backward compatibility, and you get a seed phrase for your identity.
Example that you could do today: Using standalone tools, generate an identity keypair and then generate sub-keys for each client. Each client gets its own unique key. Put the xpub, path, and a link to the identity npub in the profile for each client. Those who support programatically verifying the link can do so and all other clients can verify the link in the same way they do now: post a note with each authorized key on the identity account.
Imposters can claim they're sub-accounts of someone else, but the xpub won't check out and there won't be any note on the identity account saying that's a legit sub-account.
While this doesn't require any code changes, obviously it would be a better UX to have the software verify the link, auto-follow sub-accounts, and so on.
You can also choose to have multiple personalities that are linked. Maybe you use one sub-account to talk politics, one to talk about your mad ping pong skills, and another to talk about gardening. There could even be an indicator in the profile to indicate that following this sub account should not follow all the others automatically. The possibilities are only limited by our imagination.
Also … wouldn’t sharded keys required user to have TWO clients to sign events? Maybe xpub solution is better cause it would not…?
nostr:npub16v82nr4xt62nlydtj0mtxr49r6enc5r0sl2f7cq2zwdw7q92j5gs8meqha , I may be calling on you for consult …
https://guggero.github.io/cryptography-toolkit/#!/hd-wallet
☝️ Fantastic tool. I used it a lot when I was writing tools to do these key derivations (just to confirm I fully understand the process). That'll let you do everything except use a xpub to generate more addresses.
A quick search turns up https://github.com/swan-bitcoin/xpub-tool to do that.
Use these tools to understand the concepts and then you'll be all set to implement it in your language of choice (or better yet, find a library that has already done so).