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`.