Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Speed is important, but if you haven't noticed the combinations are much smaller if you only change the bits in the key, and not randomly generate all possible private keys and their addresses) on a Python script, you can easily get to 50 +-, and 68 is possible, but it will take more time to check, say, 30 bits (mutations in the key), so good speed can be achieved in low-level programming languages, and these are C, C++ and similar languages 
If I knew C or C++, I would have rewritten it from Python to it for better speed, but I don't have such knowledge! The most I can do is rewrite it to node.js, but it won't give any increase)
If I knew C or C++, I would have rewritten it from Python to it for better speed, but I don't have such knowledge! The most I can do is rewrite it to node.js, but it won't give any increase)
The only thing you would get knowledge of is learning C and C++.
Other than this, there's something else you'd learn: that converting private keys to hashes is around 100 to 1000 times slower than converting sequential private keys to hashes. Do you understand how the discrete logarithm works for an elliptic curve? Or generally, for a group?
I'm not gonna say it loud what this means for your idea. You can do the math.
Don't you think that you are contradicting yourself?
private keys to hashes is around 100 to 1000 times slower than converting sequential private keys to hashes - these are the same operations ...
The method I proposed works great! And I understand perfectly well that for large ranges you need speed or faith in randomness! Maybe someone will find my idea attractive and implement it, thereby speeding up finding solutions to puzzles!
Those are not the same operations.
Computing addr(pkey)…addr(pkey + n) is way faster than computing addr(pkey1)….addr(pkeyN).
If you don’t understand why, have a look at how vanity search works for instance.