Threshold sig will need a polynomial evaluation function so the interpolate and evaluate logic was merged under a new Polynomial struct that holds the coefficients of a polynomial.
The first implementation used const generics, i.e. a Polynomial<const N: usize, T> had a compile-time parameter: the order of the polynomial. This meant that the coefficients were stored in a [T; N + 1] array. Even though this provided nice compile-time size bounds, it is too static for our usecases. For example, when generating a ring signature, we don't know the ring's size beforehand, and even if we did, it probably changes with every call. That means, however, that the code would have to be recompiled with the known ring size as a constant at every call, which is nonsensical. Even for threshold signatures, with participants entering/leaving the network, the static size bounds would have to be recompiled. So we are rolling with dynamic Vec<T> types instead.
Description
Threshold sig will need a polynomial evaluation function so the
interpolateandevaluatelogic was merged under a newPolynomialstruct that holds the coefficients of a polynomial.The first implementation used const generics, i.e. a
Polynomial<const N: usize, T>had a compile-time parameter: the order of the polynomial. This meant that the coefficients were stored in a[T; N + 1]array. Even though this provided nice compile-time size bounds, it is too static for our usecases. For example, when generating a ring signature, we don't know the ring's size beforehand, and even if we did, it probably changes with every call. That means, however, that the code would have to be recompiled with the known ring size as a constant at every call, which is nonsensical. Even for threshold signatures, with participants entering/leaving the network, the static size bounds would have to be recompiled. So we are rolling with dynamicVec<T>types instead.Aims to close #46