Remove feature(i128_type)
The `i128_type` feature was recently stabilized in Rust, so this is unnecessary now for nightly users. In fact, in a few days there should be a new Rust beta (`1.26`) containing stable support for `i128_type`, meaning that (for Zcash) we can switch to the beta compiler for all future Rust development, and even switch to the stable compiler in six weeks when that's released.
Release of pairing 0.14.0.
This release makes some changes in response to an audit of this library, as well as some obversations about the API that I made. Some names were changed (`divn` -> `shr`, `muln` -> `shl`) and `add_nocarry`/`sub_noborrow` no longer return anything (as their names would suggest.) Some potentially misleading comments are fixed as well.
The release also applies `rustfmt` and new lints from `clippy` to the codebase, enforced by the CI on a more recent version of the Nightly compiler.
Thanks go to @jasondavies for his contributions to this release.
Expose arithmetic
This exposes `adc`/`sbb`/`mac_with_carry` from this library for downstream use, as long as a `expose-arith` feature is enabled. We need this downstream to avoid code duplication.
This also bumps to `0.13.2`.
Release of 0.13.1
This release features the following changes:
* The `byteorder` version is now set to `1` as conventional.
* The `CurveAffine`/`CurveProjective` traits now enforce that the scalar field of the `Engine` is the same scalar field for the curves.
* `Engine` is now `'static` and `Clone` to avoid problems with lifetime quirks and auto-derives.
* The scalar field of `Engine` is now guaranteed to be `SqrtField` which helps downstream abstractions.
In this PR I will be updating the `clippy` version and fixing any linting problems that show up. The builder should be using the newest nightly/stable versions of Rust also.
Enforce that Fr of Engine is the scalar for curve points
In bellman, I want to write:
```rust
pub struct Point<C: CurveProjective>(pub C);
impl<C: CurveProjective> Copy for Point<C> { }
impl<C: CurveProjective> Clone for Point<C> {
fn clone(&self) -> Point<C> {
*self
}
}
impl<C: CurveProjective> Group<C::Engine> for Point<C> {
fn group_zero() -> Self {
Point(C::zero())
}
fn group_mul_assign(&mut self, by: &C::Scalar) {
self.0.mul_assign(by.into_repr());
}
fn group_add_assign(&mut self, other: &Self) {
self.0.add_assign(&other.0);
}
fn group_sub_assign(&mut self, other: &Self) {
self.0.sub_assign(&other.0);
}
}
```
However, this doesn't typecheck because the compiler cannot know that the `Engine`'s `Fr` type (as dictated by the `Group` trait) is the same as the `Scalar` type of the `CurveProjective` point. This can be solved with a where bound over the trait (for now), but it is generally a good idea for this to be constrained in `pairing`.
Add "scale_by_cofactor".
Add a function for Affine types that multiplies point by the cofactor of the
group. If the points are in the group, they'll thus end up in the
correct subgroup.
note: this patch is already being tested with previous unittests.
note: this patch raises warning for unused functions and consts.
RELIC interop
Closes#2
RELIC has changed the G2 generator to match ours: https://github.com/relic-toolkit/relic/commit/25aafecbecba237a786aa8881719b4a95eecefbc
RELIC will not have the same serialization as us.
One last difference is that RELIC conjugates the pairing result to account for the negative curve parameter. It doesn't matter for BLS curves but it's strictly more correct.
Introduce stable arithmetic to avoid nightly/unstable features for some platforms
This PR allows the user to opt-out of the "u128-support" feature so that they can use the stable compiler and avoid the unstable `i128_type` feature in the Rust compiler. (Pass `--no-default-features` to opt out.)
This roughly triples the cost of everything in my experience, but it's necessary on some platforms (`arm-linux-androideabi`) which Rust/LLVM doesn't compile 128-bit integers for correctly yet.
**Before this can be merged the CI needs to test against this being enabled or disabled.**
s/is_in_correct_subgroup/is_in_correct_subgroup_assuming_on_curve/
I added a new method`is_in_correct_subgroup_assuming_on_curve` and added the method `is_in_correct_subgroup` for the `CurveAffine` trait.
Group encoding negative test vectors
Closes#10
Also simplifies the encoding code, which has the side-effect of being useful for testing. Also adds more descriptive error reporting throughout the API. Also ensures use of Debug/Display are consistent with standard expectations.
Various improvements to project structure and implementation
This makes wNAF/multiexp more modularized and abstract (for use later in remodeling groth) and starts moving other things around.
Also, good chance to start working on buildbot.
bmerge