Index assignment

[jesseposner]

From the BIP

All participants and the coordinator in a session must be given an identical SessionParams tuple. In particular, the host public keys must be in the same order. This will make sure that honest participants agree on the order as part of the session, which is useful if the order carries an implicit meaning in the application (e.g., if the first t participants are the primary participants for signing and the others are fallback participants). If there is no canonical order of the participants in the application, the caller can sort the list of host public keys with the KeySort algorithm specified in BIP327 to abstract away from the order.

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.

[LLFourn]

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.

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.

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!

[jesseposner]

To be clear I think @jesseposner is talking about the secret share indices?

Yes, thanks for clarifying.

Do you have any protocol in mind that would actually benefit from a party having a fixed share index?

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.

[LLFourn]

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.