FYI, the "Add https://github.com/herumi/xxx libs for BLS support" currently contains a patch that adds a few function to the libs. This patch will vanish when/if herumi/bls#13 gets merged.

Maybe I'm being paranoid, but has anyone reviewed the security of these libraries? They seem to be written almost entirely by one person from a Japanese university, I don't get the feeling that they've been widely reviewed.

The reason we took these libraries are that DFINITY uses them for their DKG. Another reason is that it already supports JavaScript (WebAssembly based) and many other languages.

But I must agree with you, review is a big problem with these libraries. They seem to be not very well reviewed and are extremely hard to understand. They also contain a lot of stuff that we don't need, making it even harder to review them.

I'm already looking into alternative libraries tbh, e.g. https://github.com/Chia-Network/bls-signatures. What I've seen so far seems to be very clean and easy to understand code. Problem is, that this library does not implement everything that we need (e.g. Shamir's Secret Sharing). It's also unclear if a JavaScript version will be possible and it is limited to the BLS12-381 curve in reversed mode. It's not 100% clear yet which curves we'll use in the end (it might even be that we need multiple curves for different use-cases).

Force pushed a new version. The BLS wrappers now support the herumi libraries and the Chia BLS library. Herumi can be configured with 2 different curves for now (you have to manually change a few #if). Chia only support BLS12-381 in reversed (g1 and g2 swapped) mode.

I'm in contact with the Chia developer to figure out if we can change the library to better fit our needs. We especially need to be able to perform aggregation/verification without the overhead of the secure AggregationInfo. We might also need to swap g1 and g2 back as we actually have downsides because of this (we have more signatures than public keys on-chain). If BLS12-381 turns out to be too slow (and it's really slow...), we might also need to add support for BN curves to Chia, which the developer is open for contributions.

For now, all the changes I needed to do to Chia are in https://github.com/codablock/bls-signatures/tree/dash and I'm trying to PR as much as possible into upstream.

@UdjinM6 If you compile this on mac, it will automatically use the Chia library as it was too much effort to cross-compile the herumi libraries.

FYI, if you run benchmarks with Chia, it will be much slower than the herumi version. This is due to the overhead of the AggregationInfo bookkeeping.

Updated the herumi libs to latest upstream, which removed most of dash.patch :)

As mentioned earlier in Slack, I had to add this patch UdjinM6@c2ef94f (and #2325) for chia_bls to be successfully compiled/staged/linked on macos.

Updated Chia libs to latest version, including some refactoring that is not merged yet in the Chia lib. With this, Chia can compete in the benchmarks with the Herumi libs.

Also, build should be fixed on all platforms now...waiting for Travis to confirm this.

The refactoring that were necessary in the Chia libs to be considered as a viable alternative to the other libraries have been merged in the mean time.

As of now, I prefer to go with Chia libraries as the base for all BLS related things in Dash. It is based on the BLS12-381 curve with reversed G1 and G2 (to make public keys smaller than signatures, as signatures can be aggregated on-chain while public keys can't). Performance however is an issue with this curve, as it is multiple times slower than BN254 (which was used before in all my tests and benchmarks). Current tests with large LLMQs however show that the performance is still acceptable.

I'll also be able to improve performance a bit by not using forced distinct messages anymore, as I've initially written in https://github.com/dashpay/dips/blob/master/dip-0006/bls_signature_scheme.md. Instead, I'll use secure aggregation as described in https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html and implemented in the Chia library.
DIPs and supporting documents will be updated after I've modified the BLS wrappers and LLMQ implementation.

Signatures created from keys which are the result of the DKG will not need secure aggregation, as the rogue public key attack is not possible there (keys are verified as part of the DKG protocol).

Force pushed a new version. It removes support for the herumi libs and is now solely based on Chia's library.

Would be good if we could merge this in in the next days. It does not touch anything critical and only adds new code. My next PR will then change DIP3 to use BLS keys for the operator key, which will then allow us to start rolling out 12.4 on testnet. The BLS operator keys will then be the basis for LLMQs, which we can merge in a few days/weeks later, but in a disabled state for testnet/mainnet.

Thanks for the code-style fixes. I squashed UdjinM6@f8d920e directly into the original commits.

Regarding src/crypto, I added it there because I did not consider that crypto only contains low-level stuff. Would you be ok with adding a sub-folder in src just for bls stuff?