libsecp256k1 side channel code fix

[Telariust]

How about this eprint.iacr.org/2016/103.pdf
"Speed Optimizations in Bitcoin Key Recovery Attacks"
(disable side channel code -> speed+ )

Ryan do it in last release github.com/ryancdotorg/brainflayer
(also see github.com/llamasoft/secp256k1_fast_unsafe)

good question, is whether ecmultab will be effective on gpu as well as on cpu,
ie (as I understand it) effective memory access vs. real multiplication

[brichard19]

Hi,

Thanks for the suggestion. We are always looking for ways to make the code more efficient.

That being said, the technique outlined in the paper is not applicable here.

For BitCrack, the points need to be in affine coordinates because they are hashed in that form (as per Bitcoin address standard). Going from projective coordinates to affine coordinates requires a field inversion, which negates the benefit of projective coordinates.

And even then, inversions can be batched together such that N inversions only costs 3N multiplications and 1 inversion. When N is large enough, the inversion is practically costs nothing.

Multiplication tables might be a good idea, especially since the shared memory on the GPU isn't being utilized.

Another thing worth looking into is using floats in a 10x26 configuration instead of the int32's we're using now, as most cards are fully pipelined for floating-point.

Thanks