search

Chia-Network / bls-signatures

BLS signatures in C++, using the blst library for BLS12-381
Apache License 2.0
295 stars 211 forks source link

Multiple questions about the future of this library #17

Closed codablock closed 5 years ago

codablock commented 5 years ago

I've already requested access to the Keybase group as I initially wanted to discuss this there. As I don't have access yet, I'll post this here.

I've got multiple questions about future plans for this library. I'm especially interested as I know that this library was initially intended for Chia.

  1. Are there plans to support any other curves, for example the BN254 curve for cases were performance is more important than the security level?
  2. Are there plans to support the non-reversed version of BLS12-381? I understand why you chose to swap G1 and G2, but there are cases were this is actually increasing space usage (when more non-aggregated signatures are used than public keys)
  3. Are there plans to support M-of-N schemes based on Shamir's Secret Sharing? I already implemented the primitives (polynomial evaluation and Lagrange interpolation) into the Chia BLS library, if you're interested I can create a PR.
  4. I understand that for Chia, you plan to solely use the secure version of aggregation and verification. However, the way it is implemented in the library forces everyone else to use it as well or at least carry the overhead of the aggregation info even though it is not needed in some cases (e.g. when proof of possession is implicitly guaranteed). Would you consider splitting the current version of BLSSignature into BLSSignature + BLSSecureSignature, where BLSSignature would not contain any aggregation info and only perform classical/simple verification? I can do this refactoring if you want and create a PR.
codablock commented 5 years ago

Regarding 1. and 2., if this is not planned, are you open to have others add support for these?

mariano54 commented 5 years ago
  1. No, there are no plans to support other curves, since the plan is to use BLS12-381 for the Chia blockchain. Open to other people adding support, and adding this support shouldn't be too difficult.
  2. No. I'm also open to someone implementing this, but it will require larger changes (probably abstracting away g1 and g2).
  3. Yes, that is the next feature we're working on. We're looking into doing Joint-Feldman but still thinking about DKG tradeoffs.
  4. We already have this function, it's called AggregateSimple. To support this feature, we just have to expose thus function publicly in BLS.hpp, and make sure the AggregationInfo is set correctly. This should also be relatively simple.
mariano54 commented 5 years ago

For number 4, the AggregationInfo would just be set to the aggregate public key, and thus keep the aggregation opaque and indistinguishable from a normal signature, making AggregationInfo easy to generate on the verifying side.

codablock commented 5 years ago
  1. Depending on which curve and library (we're also evaluating https://github.com/herumi/bls) we decide on, I might be able to provide this
  2. Same as 1., and I already tried to simply swap g1 and g2 back which worked as expected.
  3. Is this feature only planned or already started? I can provide a PR with the polynomial primitives today if you're interested.
  4. This is what I did for experiments already. I might create a PR for this as well.
mariano54 commented 5 years ago

Great, yeah PRs are welcome. For threshold signatures, we are already working on this, so we don't need a PR.

codablock commented 5 years ago

FYI, as we need threshold sigs already now and I already had this implemented: https://github.com/codablock/bls-signatures/commit/b69d4fa1bd79813f7ffdabe00d1bac5fc680ba4f (but not creating a PR)