-
Notifications
You must be signed in to change notification settings - Fork 36
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
Should we make k
a generic parameter?
#9
Comments
I think @pyrros mentioned, regarding
|
Just to reiterate: Indeed, it would be great if we could indeed support different parameters concurrently (i.e nodes A,B,C produce signatures for [k_0,m_0,f], but node D attempts to aggregate for [k_1,m_1,f]). It might be possible for f to vary as well, but it's less of a priority. |
Wouldn't this be defined at the node level, hence a parameter set in the library. Seems much simpler than allowing the library itself to support multiple |
Indeed, we don't need to make the library explicitly aware of multiple values. But we would like the library to avoid hardcoding/embedding the k/m values to sigs and certs. That is, we want to be able to handle sigs/certs being created under one set of k/m parameters and evaluated (i.e verified/aggregated) under another. |
An aggregate signature requires individual signatures over
k
different indices.Should we make
k
a generic parameter? We seemed to remember (but couldn't find) that we wanted to support multiple settings ofk
. What is the best way to achieve that?The text was updated successfully, but these errors were encountered: