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.