Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
I get the same performance as you, but EC_POINT_add isn't the slowest step, it's the call to EC_POINT_point2oct.
Do you know why EC_POINT_point2oct is slow? I called EC_POINT_get_affine_coordinates_GFp instead, but they seem to do the same thing. If EC_POINT_add stores the point in Cartesian coordination (X-Y), will extracting the public key be a trivial task?
Guys with brute force we won't go anywhere.
How precise is this formula?
How precise is this formula?
I think all of us know that brute force is not viable for sure, but it is fun to estimate how long it will take to break the 51st, 52nd, ... addresses.
That division isn't the conventional division. It has perfect precision (http://www.johannes-bauer.com/compsci/ecc/#anchor07).
Well we wont get 5 TH/s or anything close for sure, but if we were able to generate 100 million keys per second we would break the #51 in about 3.5 months... And I believe it will be very hard to get to 100 million / s even with GPU.
Yes of course we can try it for the fun, but it wont be much fun when you get home and your GPU is burning plus your electricity bill
But of course if your formula brings down the range of keys to generate then we can have some chance.
So, basically I was wrong because we have to calculate λ to add the two points.
If you find the right formula can you post the results for each address so we know exactly what ranges we can count with?