Our existing function secp256k1_gej_double_nonzero actually supports infinity if only it wouldn't check that the input isn't infinity.
Drop the check, rename it to secp256k1_gej_double, and adapt the tests.
Our existing function secp256k1_gej_double_nonzero actually supports infinity if only it wouldn't check that the input isn't infinity.
Drop the check, rename it to secp256k1_gej_double, and adapt the tests.
ACK 18d36327fddad18ba81af2cf7fe6c8a16952dc22 I looked at the diff and ran tests locally
When I was a child, I sometimes wondered what ∞ + ∞ is.
ACK 18d36327fddad18ba81af2cf7fe6c8a16952dc22
it was funny looking at the history of changes how it ended up this way: The original function was variable time, but only for infinity. Some code needed to double in constant time but never needed an infinity, so it just added a wrapper that verified the input wasn't infinity to be sure it wouldn't be variable time. Then at some point there was an audit to make sure that no constant time functions were calling variable time functions (in ways that might risk accidentally introducing variable timeness in the future), and the variable time function was rewritten in terms of the constant time function. Since constant time doubling supporting infinity wasn't needed, I doubt I ever checked if it worked. :)
it was funny looking at the history of changes how it ended up this way
... and then (I assume) sipa noticed it was a separable patch from the signed-digit multi-comb PR.
post-merge ACK 18d36327fddad18ba81af2cf7fe6c8a16952dc22
lol. so now secp256k1_gej_double_var is just "same as secp256k1_gej_double but early return for infinity"
@elichai Indeed. @peterdettman Yeah, when rebasing the multi-comb stuff on top of the reorganized double_var and double_nonzero, after resolving conflicts, I noticed that I was ending up with two identical functions (double and double_nonzero).