Gregory Maxwell

I'll rebase when 794 is merged.

Okay, then this doesn't need to be rebased. Unsurprisingly, no gross performance loss, FWIW: Before: ecdsa_verify: min 54.9us / avg 54.9us / max 54.9us ecdh: min 65.6us / avg 65.7us...

Yep. I didn't intend to change their infinity-handling-ness beyond making them less wrong. (for the second function too, making those handle infinities would be non-trivial)

@jonasnick What non-gej-outputting function are you thinking of?

Rebased and added a comment that secp256k1_ecmult_odd_multiples_table's a argument cannot be infinity.

Your branch needs a patch along the lines of ```diff diff --git a/src/group_impl.h b/src/group_impl.h index 950b51d..b8ed209 100644 --- a/src/group_impl.h +++ b/src/group_impl.h @@ -197,6 +197,8 @@ static void secp256k1_ge_set_all_gej_var(secp256k1_ge *r, const...

I switched this to sipa's rebase.

The only reservation I have about the volatile trick is that there is a long history of compilers emitting broken code in the presence of volatile because almost nothing uses...

fun(int x) volatile int tmp1 = x; int tmp2 = tmp1; then use tmp2. So there is only one read from tmp1 and it can make a register copy of...

It's a good requirement. You should not be shipping split out libsecp256k1. The software is not released, the API is highly unstable, etc. We will release when it's ready for...