Search content
Sort by
Showing 8 of 8 results by werty98
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Maybe these random-like numbers came from hashing operations? For example: n-th key = truncate(SHA256(f((n-1)-th key))). It will be still hopeless if the process involves a strong passphrase though.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
The first 20 addresses were spent in the same block with the puzzle transaction, surely by the author. Would the author be a miner? This also raises the question whether someone else rather than the author did cash out 
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
long time lurker; not much of a poster...
Nice work!
Unlike mining, this challenge won't get harder. If 1 BTC = 1,000,000 USD, which address will be cracked up to?
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
BTW, whoever created this challenge will be able to manipulate BTC price, won't she/he?
I am not sure exactly what you mean. I do see a scenario where the creator of the challenge could possibly cause a panic sell off. Is that what you are talking about?The creator still has the private keys so they can spend the rewards at any time. So, they could claim a bunch of the rewards thus simulating a weakness in the Bitcoin crypto? This could possibly cause a panic sell off if the market believed it?
Yeah, that's what I meant
Anyway, as Einstein said, investors' behavior is the only thing in this universe that does not follow any physics law.
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).
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Unlike hash operations, elliptic curve operations have unpredictable machine cycle count.
I would expect a single point addition operation (P3 = P1 + P2) to have a very predictable machine cycle count. It should be something like:x3 = λ2+a1λ−a2−x1−x2
y3 = −a1x3−a3−λx3+λx1−y1
λ = (y2−y1) / (x2−x1)
From: https://crypto.stanford.edu/pbc/notes/elliptic/explicit.html
I did use that EC point increment method, otherwise the program would be 20x slower. Those multiplications/divisions are modulus but not conventional integer operators; they don't have predictable machine cycle count.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Your results are from CPU or GPU?
What's your performance?
I was involved in the challenge and earned some BTC. I speedhacked the code in the mealtime at work straight after I saw the puzzle back in January 2015 and started it on some server remotely. The first version could do about 100,000 keys/s using a CPU. After some improvements I boosted the rate to 700,000 keys/s on a single computer. Later I ran it on many computers and checked million of keys/s. Luckly I could recycle the code later in the August 2015 puzzle at https://bitcointalk.org/index.php?topic=1144807.0What's your performance?
I had no time to learn how to code on a GPU.
I've tried my first version using openssl and got about 25,000 keys/s (single-thread). You seem to use something other than openssl.
Unlike hash operations, elliptic curve operations have unpredictable machine cycle count. Thus, speed-up on SIMD processors (e.g. GPUs) won't be great.
BTW, whoever created this challenge will be able to manipulate BTC price, won't she/he?