Open chelseakomlo opened 3 years ago
I assume that i
simply goes from 1
to n
, and that the dealer will use id_i
to evaluate the polynomial in order to obtain the private key. Is this correct?
Regarding the hash function, should I go with HStar
? This hash function produces a Scalar
, which is 256 bits long.
This also brings up the decision of how long the identifiers should be. To me, 64 (or perhaps 32) bit identifiers seem like a reasonable choice between the length of the identifier and the chance of a collision. Also, the participants' identifiers are used in the evaluation of the polynomial in Shamir's Secret Sharing, where they are cast to u64
and then used to produce a Scalar
again. https://github.com/ZcashFoundation/redjubjub/blob/f7c153575b342663169fe8615ca827007aba626e/src/frost.rs#L290
Currently, we are using u8
for the identifiers in order to limit the number of participants.
Regarding the hash function, should I go with
HStar
? This hash function produces aScalar
, which is 256 bits long.This also brings up the decision of how long the identifiers should be. To me, 64 (or perhaps 32) bit identifiers seem like a reasonable choice between the length of the identifier and the chance of a collision. Also, the participants' identifiers are used in the evaluation of the polynomial in Shamir's Secret Sharing, where they are cast to
u64
and then used to produce aScalar
again.Currently, we are using
u8
for the identifiers in order to limit the number of participants.
I think we can go with u64's with the handy conversion to jubjub::Scalar, this implies that the ParticipantId
s will be u64's in all the message types.
@oxarbitrage
We want a more robust but deterministic mechanism for generating participant identifiers for FROST. For the trusted dealer variant, we can generate participant identifiers as follows:
Where
s
is the secret chosen by the dealer during Key Generation.