-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we make the hostseckey the cryptographic seed? #28
Comments
seems a bit unnecessary indeed. I thought for a moment that this has the advantage that we can in principle have multiple hostpubkeys for a single seed, but that's actually just unnecessary complexity. I'm not sure what you mean by "this fits BIP32 better". Isn't the host key pair just |
I can imagine that it fits the current model of multisigs in (hardware) wallets better, where each participant derives the key pair for the multisig using some BIP32 derivation path (see, e.g. some of the descriptor examples with explicit BIP32 derivation paths in https://github.com/bitcoin/bips/blob/master/bip-0383.mediawiki). If wallets want to use the same method for DKG, they could derive a secret key using BIP32 and use it as DKG "seed". And then it's a bit more natural that the corresponding derived pubkey is actually the host pubkey. |
Now that I think about this again, my conclusion is that this is more of a naming question for the API than a derivation question What's currently caller-facing is a secret "seed" and a "host public key". That's a bit unnatural. If we call one thing "a public key", then there should be a corresponding secret key in the API. If we want to fix this (and I think we want to), then we have the following options:
|
Currently, we derive everything from the seed, including the hostseckey. We could instead let the user pass the hostseckey and then, if we need randomness for the VSS, derive it from the hostseckey.
Advantages:
Disadvantage:
The text was updated successfully, but these errors were encountered: