Andreas Fackler

I agree it would be good to make it compatible. Not sure if anyone is working on this repository right now, though.

One remaining example is the local variable `g` in `SecretKey::decrypt`. It should be zeroed, too, and we should check the code for further issues like that.

(Not sure if anyone's working on this repository currently.) Maybe the [DKG implementation in HBBFT](https://github.com/poanetwork/hbbft/blob/master/src/sync_key_gen.rs) (which uses `threshold_crypto`) can serve as an example.

I like the idea, but do you think it would be feasible to implement that as a separate crate, i.e. have a `threshold_crypto_c` crate that depends on `threshold_crypto` and exposes...

Great! I won't be able to work on it any time soon, but I'd be happy to help with the review.

Actually, let's keep this open until such a crate exists. It would be really great to have FFI bindings.

Thank you for pointing out those issues, @burdges! Yes, we're open to accepting a blind signing PR in principle, if those questions are resolved.

I'd say that's no reason to exclude blind signatures from this crate, is it? It's rather about using them correctly. We should probably add some warning to the docs about...

That's weird. I can't reproduce that locally; also, the "pr" build passed, and only the "push" one failed. For some reason, the latter called ``` rustup toolchain install ${RUST_NEXT} ```...

Maybe you just need to rebase? The `no_leak_in_release_builds` branch seems to have an outdated `.travis.yml`.