Many of our constructed input / output types need to be unique sets. For example:
keygen outputs include a list of public key shares with unique participant IDs
auxinfo outputs include a list of public aux info with unique participant IDs
Note that the uniqueness property is on the PIDs, not the data itself. Theoretically, it's possible and legal for two parties to randomly select e.g. identical public key shares (although it's incredibly unlikely). On the flip side, if we have a dozen unique pieces of data but they all belong to the same PID, we have a problem.
Currently, these are typed as Vec<_>s and upon construction, we check that the uniqueness properties hold. An alternate approach could define a UniqueSet<T> type that checks the appropriate uniqueness property and maybe can be constructed easily from any iterable.
Completion criteria
If appropriate, this can be broken into multiple issues
[ ] Design a useful API for these types, considering the currently limited set of use cases and how to make it relatively misuse resistant for the user
[ ] Implement and incorporate into input types
[ ] Determine whether there are other scenarios where we might use the unique set type.
Many of our constructed input / output types need to be unique sets. For example:
Note that the uniqueness property is on the PIDs, not the data itself. Theoretically, it's possible and legal for two parties to randomly select e.g. identical public key shares (although it's incredibly unlikely). On the flip side, if we have a dozen unique pieces of data but they all belong to the same PID, we have a problem.
Currently, these are typed as
Vec<_>s and upon construction, we check that the uniqueness properties hold. An alternate approach could define aUniqueSet<T>type that checks the appropriate uniqueness property and maybe can be constructed easily from any iterable.Completion criteria
If appropriate, this can be broken into multiple issues