* WIP constant-time implementation of the ec-divisors library
* Fix misc logic errors in poly.rs
* Remove accidentally committed test statements
* Fix ConstantTimeEq for CoefficientIndex
* Correct the iterations formula
x**3 / (0 y + x**1) would prior be considered indivisible with iterations = 0.
It is divisible however. The amount of iterations should be the amount of
coefficients within the numerator *excluding the coefficient for y**0 x**0*.
* Poly PartialEq, conditional_select_poly which checks poly structure equivalence
If the first passed argument is smaller than the latter, it's padded to the
necessary length.
Also adds code to trim the remainder as the remainder is the value modulo, so
it's very important it remains concise and workable.
* Fix the line function
It selected the case if both were identity before selecting the case if either
were identity, the latter overwriting the former.
* Final fixes re: ct_get
1) Our quotient structure does need to be of size equal to the numerator
entirely to prevent out-of-bounds reads on it
2) We need to get from yx_coefficients if of length >=, so if the length is 1
we can read y_pow=1 from it. If y_pow=0, and its length is 0 so it has no
inner Vecs, we need to fall back with the guard y_pow != 0.
* Add a trim algorithm to lib.rs to prevent Polys from becoming unbearably gigantic
Our Poly algorithm is incredibly leaky. While it presumably should be improved,
we can take advantage of our known structure while constructing divisors (and
the small modulus) to simply trim out the zero coefficients leaked. This
maintains Polys in a manageable size.
* Move constant-time scalar mul gadget divisor creation from dkg to ec-divisors
Anyone creating a divisor for the scalar mul gadget should use constant time
code, so this code should at least be in the EC gadgets crate It's of
non-trivial complexity to deal with otherwise.
* Remove unsafe, cache timing attacks from ec-divisors
contracts was smashed out of ethereum-serai. Both have now been smashed into
individual crates.
Creates a TODO directory with left-over test code yet to be moved.
The router will now match the top-level transfer so it isn't used as the
justification for the InInstruction it's handling. This allows the theoretical
case where a top-level transfer occurs (to any entity) and an internal call
performs a transfer to Serai.
Also uses a JoinSet for fetching transactions' top-level transfers in the ERC20
crate. This does add a dependency on tokio yet improves performance, and it's
scoped under serai-processor (which is always presumed to be tokio-based).
While we could instead import futures for join_all,
https://github.com/smol-rs/futures-lite/issues/6 summarizes why that wouldn't
be a good idea. While we could prefer async-executor over tokio's JoinSet,
JoinSet doesn't share the same issues as FuturesUnordered. That means our
question is solely if we want the async-executor executor or the tokio
executor, when we've already established the Serai processor is always presumed
to be tokio-based.
Moves the coordinator loop out of serai-bitcoin-processor, completing it.
Fixes a potential race condition in the message-queue regarding multiple
sockets sending messages at once.
I don't love this. I wanted to simply add this function to `processor/key-gen`,
but then anyone who wants a view key needs to pull in Bulletproofs which is a
mess of code. They'd also be subject to an AGPL licensed library.
This is so small it should be a primitive elsewhere, yet there is no primitives
library eligible. Maybe serai-client since that has the code to make
transactions to Serai (and will have this as a dependency)? Except then the
processor has to import serai-client when this rewrite removed it as a
dependency.
The main benefit is whatever scheduler is in use, we now have a single API to
receive TXs to sign (which is of value to the TX signer crate we'll inevitably
build).
