Should we make the hostseckey the cryptographic seed?

[real-or-random]

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:

• This fits BIP32 better, which produces "keys" (and not seeds). The BIP32 derived key pair will just be the host key pair.
• Fewer derivations.

Disadvantage:

• This fits BIP32 better. People may start doing public derivation, or receive coins under their BIP32 host public key. (But wallets already know how to deal with this in other multisig scenarios, e.g., wallets use different derivation paths for single sig and multisig)

[jonasnick]

def hostseckey(seed: bytes) -> bytes:
    return prf(seed, "chilldkg hostseckey")

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 (seed, int(seed)*G), no BIP 32 required?

[real-or-random]

I'm not sure what you mean by "this fits BIP32 better". Isn't the host key pair just (seed, int(seed)*G), no BIP 32 required?

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.

[real-or-random]

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:

• Simply rename "seed" to "secret key". This gets the abstract "syntax" of the scheme right, but it's a bit counter-intuitive to people who assume that the terms secret key and public key always refer to some pair (x, xG). (Which is true in basically every scheme used in Bitcoin.)
• Change the API to expect a "secret key" instead of a "seed", and change derivation so it's the actual dlog of the hostpubkey (#42) This seems just better, so we should do this.