Glad you finally got it to work.

Now that you finally got rid of the server command, you can play around with the grid size numbers for your gpu, up to you.

The MKey/s drop but shouldn't be that much. I have had 1070s that maintain above 200 MKey/s.

I do not know what you mean by multiples of 5...if you are referring to the puzzle, that's because every 5th address in the puzzle has the pubkeys exposed. This program works by only knowing the pubkey. But the program will work for any range, any "multiple".

Hi! Just wonder what is the impact of searching multiple pubkey at once ?
Does the key are search one by one or all at once ?

If you have more than one pubkey in your input file, the program searches one by one. If you don't use the -m option, the program could search for the first pubkey forever.

For continuous range you could divide a_i by 's': a_i/s = a₀/s + i.

If pubkey to 64 was exposed it would have been solved already.

[EDITED]

I must rethink it ;-)

@Jean_Luc, implement please Pollard's RHO code to bitcoin

Maybe you can make a Pollard RHO like Pollard Kangaro without memory cost



This is a link to sources:



Code Sources ready to go - CUDA demonstration using Pollard's Rho  - https://github.com/dghost/factor-cuda

https://github.com/dghost

BSGS and Pollard's rho both cost O(n−−√) operations where n is the order of the group, typically a >250-bit integer as in edwards25519, secp256k1, nistp256, etc. However, BSGS also has O(n−−√) memory cost, so the area*time cost—which is a proxy for euro or joule cost—is O(n) even if we unrealistically assume O(1) random access to memory. In contrast, Pollard's rho costs O(n−−√) time on a machine of constant space and thus O(n−−√) area*time. Pollard's rho can also be naturally parallelized to trade space for time without increasing the overall cost. There are also some small optimizations that apply to Pollard's rho for elliptic curves, but they only change the constant factors a little; it remains O(n−−√)
.
If you knew the secret scalar were in a restricted range [a,b]
, you could use Pollard's kangaroo, which costs O(b−a−−−−√) time on a machine of constant size. The kangaroo method too can be parallelized without increasing overall cost. If, say, b−a≈2100 for your secp256k1 target, then this would be within reach for you while none of the above methods would be feasible. But it would be surprising for anyone to choose a scalar restricted enough that Pollard's kangaroo finds it substantially faster than rho.

I won't implement a rho method for secp256k1. It is not feasible to reach a solution using this method.


Thanks for the reading. I didn't read it yet.
I suppose that when you speak of walk length, you mean the total number of jumps of the walk, not the total traveled distance.
The problem of storing length of walk is that on GPU access to global memory is very slow. I will see if I manage to improve things.

Pollard's method can only search for those addresses where the public key is known. So the answer to your question is Yes.