Big name bikeshedding PR

[real-or-random]

Best reviewed commit-by-commit.

[real-or-random]

Other potential renames include:

* shared pubkey -> group pubkey (matches FROST RFC draft). I don't have a strong opinion on this. Maybe very light preference for "shared".

The advantage of "shared" is that it expresses that everyone has a share of it. But that's also the disadvantage: It can be confused with shares from VSS etc, because we have so many sharings (additive sharing, Shamir sharing, Shamir sharing of the final secret etc...) "group pubkey" is not bad. What about "threshold pubkey"? That's similar in spirit, I think.

We could also use "aggregate", but I'd rather reserve this for multisignatures with key aggregation.

* signer pubkey:

  * doesn't have a short name in the FROST RFC. At one point it's called `PK_i: the public key for the i-th participant`.
  * is called `pubshare` in Jesse/Siv's signing BIP
  * is called "individual pubkey" in BIP MuSig
* share:

  * called secshare in Jesse/Siv's signing BIP
  * "Signer secret key share" `sk_i` in the FROST RFC

I prefer "secret key"/"public key" over "secret share"/"public share". It's simply more common and then also easier to handle implementors?

(If we don't use "share" here, this will also be an argument against "shared" pubkey).

And "Individual" is a good addition in case there's risk of confusion with the shared/group/threshold pubkey. Being consistent with BIP MuSig is a good idea.

[nickfarrow]

We currently have joint public key (referred as this only once in FROST paper) but I like group public key or shared public key more. Perhaps one minor reason to favour group is that the word "share" is absolutely everywhere (at least in our code).

+1 for secret share or secret key share.

Edit: Agree with @real-or-random except I do prefer secret share over secret key since they are actual shares!

[real-or-random]

We currently have joint public key (referred as this only once in FROST paper) but I like group public key or shared public key more. Perhaps one minor reason to favour group is that the word "share" is absolutely everywhere (at least in our code).

Hehe, "joint public key" is also nice. What do you think about "threshold public key"?

---

except I do prefer secret share over secret key since they are actual shares!

Yeah, indeed. I think my preference for "secret key" is that people will know that this is what they can use for signing. But that can be a disadvantage. If the only purpose of this thing is to participate in a FROST session for this group, then "share" may be a good idea, to clarify that you should not use this thing like a private key. Now that I'm writing this, I like "share".

But we should probably be consistent with the public part, i.e., we should take either the pair secret share/public share, or the pair secret key/(individual) public key.

[real-or-random]

Just had a call with @jonasnick. We settled on the following terms for now.

• "participant"
  • it's a DKG, not a signature scheme
  • the output of the DKG is currently to be used with FROST, but this may change in the future
• "secret share/public share"
  • "individual" is then implied and optional
  • this also differentiates them from host secret keys / host public keys
  • this emphasizes that you should not single-sign using these secrets
• threshold public key
  • we think it's natural in this setting
  • "group public key" is also okay, but "threshold" is a bit more precise

I'll probably implement this in a later PR.

[real-or-random]

Fixed and marked-resolved some of these. I'll take care of the rest when going over the chilldkg code or when doing further renames.