Skip to content
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

Plans for pairing and #76

afck opened this issue Apr 26, 2019 · 3 comments


Copy link

commented Apr 26, 2019

There are several projects that use pairing and would like to contribute to it. They will probably start collaborating on a fork, but I think everyone would also be happy to contribute upstream instead.

Will the librustzcash changes be merged back into the pairing repo eventually, or is that deprecated? Will the new version be published on

Would you be open to merging the functionality mentioned in that issue? (Most of the pairing users' feature requests seem to overlap a lot.)
Or is it better for POA, Filecoin, MaidSafe and others to work on a separate fork for now?


This comment has been minimized.

Copy link

commented Apr 30, 2019

Yes, the intention is to merge all the changes from this repository back up into the original repositories, as their refactoring in #41 completes. We created Git subtrees in this repository primarily because the refactor requires changing all the crates in parallel, and it is much easier to do this in a single workspace.

We also want to be publishing crates even while the primary development is happening here. The main blocker on that is the fact that we depend on a GitHub repository for BLAKE2b. Once RustCrypto/hashes#78 is merged and released, we can replace this dependency and start publishing crates again 🙂


This comment has been minimized.

Copy link

commented May 1, 2019

To answer your last question:

  • rand update is planned already in #60 and I want to do this soon.
  • Hashing to the curve is something I'd like to see an API included for in pairing, but an implementation would likely not go into pairing itself, but into curve-specific crates like bls12_381.
  • Serde support: seems reasonable but we'd probably want to merge something later on, as we couldn't promise compatibility across the refactor.

This comment has been minimized.

Copy link

commented May 2, 2019

Thank you for the detailed answer! I guess it's best to keep the Filecoin fork separate for now, and backport the changes after the refactoring is done.

@afck afck closed this May 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.