-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Index assignment #38
Comments
To be clear I think @jesseposner is talking about the secret share indices? In our library API we allow BYO share indices (any non-zero secp256k1 scalar) but in our product we use some ordering decided by the coordinator with short indices. I don't have a strong opinion for the spec. The cost of indices being "custom" is that it complicates the data structures a little bit.
Do you have any protocol in mind that would actually benefit from a party having a fixed share index? In theory the only thing I can see is that if you shares are at the same index you can homomorphically add them together to produce share of the sum of the two values they were shares of. I don't really see how that can be useful in the Bitcoin context but it might be! |
Yes, thanks for clarifying.
The situation I'm imagining is something like this: Let's say Alice, Bob, and Carol perform a DKG and are assigned indices 1,2,3. I can infer the indices from the ordering of their long-term identity keys, so I don't have to maintain additional state that assigns indices to identity keys. But now let's say Dave is added at index 4, so we have Alice, Bob, Carol, and Dave, which is mapped to 1,2, 3 and 4. Dave is assigned index 4, which had nothing to do with his identity key, so we can no longer infer share indices from identity keys, but instead need to maintain state that assigns indices to identity keys. However, if indices are derived deterministically from identity keys, then the participants don't need additional state that assigns the indices to the identity keys. Instead, they can derive the index directly from a participants identity key, regardless of whether they were added during or after the DKG. |
On the signer side they need the state of their secret share anyway as state. On the coordinator they are storing the nonces for each signer. It don't see why it's super helpful to get rid of this state in either case. Of course the less state the better but here I'm not sure the data structure/specification complexity cost is worth it. |
From the BIP
It's not explicit in the BIP whether the indices are assigned from this ordering. We've discussed this here (siv2r/bip-frost-signing#5 (comment)) so I believe it is, but it might be worth making this explicit, because the index assignment is going to affect whatever signing protocol is compatible with ChillDKG. After the DKG, the indices will either need to be extracted from SessionParams and persisted for use for signing protocols, or the ordering of the keys in SessionParams will need to be persisted so the indices can be derived from them.
In addition, I think I prefer indices derived from long-term identity keys rather than from ordering because I believe that will make it easier to work with dynamic secret sharing protocols in which participants can be added and removed. If indices are derived from ordering, then if a participant is added or removed, the ordering can no longer be used, and instead the indices need to be maintained as a map to the long-term identity keys (or some other identity for each participant). Whereas with derivation from identity keys, the index distribution is stateless and doesn't depend on an ordering or a map.
The text was updated successfully, but these errors were encountered: