Algorithms: share generation sub-section

[siv2r]

What should be the contents of the "Share Generation" subsection of the "Algorithms" section?

I am considering the following options:

• Option 1: Assume existence of $t\text{-of-}n$ shares & ~aggregate~ shared pubkey
  • Simply mention bip dkg & frost rfc that users can use to generate their shares and agg pubkey.
• Option 2: Include a spec for trusted dealer key generation
  • Rewrite SSS or VSS (mentioned in frost rfc) in our notations
    • The advantage I see with this is that we can clearly define:
      • tags for coeff generation
      • output type for agg pubkey (XonlyPubkey)
  • Mention bip dkg as an alternative if the implementers don’t prefer trusted keygen

@jonasnick @jesseposner Suggestions?

I am leaning towards option 2 (with VSS) because it provides wholeness to the specification. If you believe SSS or VSS are standard protocols, we can choose option 1.

[jonasnick]

So the output of BIP DKG is currently for each signer:

• the signer's secret share
• the shared public key (in compressed format, not xonly)
• all individual signer "public keys" for partial signature verification (compressed, not xonly)

Maybe we'll change it just output a polynomial, but then we'll add a helper function to compute the triple. We don't plan to support trusted dealers in BIP DKG.

I think it's up to you if you want to add trusted dealing to the BIP. You could start without it and then add it later. IIRC the FROST RFC + its appendix are sufficient to produce the same output as BIP DKG with a trusted dealer. Maybe it's easier for users if they can implement trusted dealing + FROST from just reading a BIP and without having to additionally understand the RFC. Also trusted dealing with VSS doesn't have test vectors in the RFC as far as I can see.

On the other hand, you can make use of the modularity of the FROST signing BIP and either add it to the appendix or let someone specify trusted dealing separately.

[real-or-random]

I think it's up to you if you want to add trusted dealing to the BIP. You could start without it and then add it later.

Indeed. The most pragmatic option is to start with option 1, and postpone this discussion. You want something like option 1 in any case to be generic and compatible to, e.g., BIP DKG. So I think you want to specify an interface in the form of a mathematical condition that the inputs need to fulfill to be compatible with signing. (Keeping in mind that functional compatibility doesn't mean that a key generation method is secure.) We did the same in the ROAST paper, see Definition 2.5 in https://eprint.iacr.org/2022/550.pdf.

With that interface in the document, you can specify signing properly. And then, if all of this is done, you can still see if you want to add a description of a trusted dealer, e.g., in an appendix as in the Internet Draft. I assume your thoughts will be clearer by then.

[siv2r]

Thanks for the suggestions! I'll go with option 1 for now.