Just when power is set 12 for bit 50, it turns out Hop_module 41 is 1 long jump 2 ^ 41 - it's too far and the range of selected points goes far from bit 50. Accordingly, the search time will be much longer. Also, when a large power - DP parity / DPmodule becomes less than 18, which leads to a large amount of data received from the video card and errors occur, wild and tame files grow quickly. Accordingly, it also affects negatively. The optimum size of the DPmodule is 22 - 24 of these values ​​should be selected power. And if DPmodule is large, then fewer selected points will be saved in files and search time will increase. Therefore, it is installed no more than 24.
+ the comparator starts the comparison once every half a minute. Therefore, such a total time.

Compute capability 2.0 and 3.0 Not supported.
This is normal, the program does not make accurate calculations. Set -p 0 or for bits 50 use cpu version.

Your GPU code not compiled , mention in your snap
have u compiled by this command
make gpu=1 ccap=20 all
where ccap setting as per your card ...

Right. First you need to fix possible inaccuracies, then there is no time to do this on Github.
The comparator on python works faster than on c ++, when the file sizes are more than 50MB - have to choose a comparator. In general, the correct way is to do the aggregation of selected points in the sql database on the server. The program should send them as a client. I have no time and knowledge for this   I will soon post it as it is.

Already available https://github.com/alek76-2/vs-kangaroo-hybrid

Why spend electricity on 105 bits , preferably 110 bits.

When rewriting program for CUDA, I don’t share the code.
./vs-kangaroo-hybrid -v 1 -p 8 -gpu -bits 65 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b

@zielar

I noticed that the PubKeys for 155 and 160 are not listed on the first page.

in this tests i found interesting address 1111111111111111111114oLvT2
its shorter than typical P2PKH  1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2
and is not random generated

OpenCL version is known to have such problems. Someone must fix the code. I only use CUDA version.

the program skip private keys in amd rx580 but working fine with nvidia gtx 950m
anyone knows why?

amd rx580 command :
clbitcrack  -c -u -i test18.txt -o out.txt --device 1 --keyspace 2:FF
...

Failed
not find 3,4,5,6,7,9
Help Me

this resul only : 2^0=1 (hex 1)
2^1=2 (hex 2)
2^2=4 (hex 4)
2^3=8 (hex
2^4=16 (hex 10)
2^5=32 (hex 20)
2^6=64 (hex 40)
2^7=128 (hex 80)
2^8=256 (hex 100)
2^9=512 (hex 200)
2^10=1024 (hex 400)
2^11=2048 (hex 800)
?!!
clBitCrack -c -u -i TEST.txt -o out.txt --device 0 --keyspace 0000000000000000000000000000000000000000000000000000000000000001
Result :
1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH 0000000000000000000000000000000000000000000000000000000000000001 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
1cMh228HTCiwS8ZsaakH8A8wze1JR5ZsP 0000000000000000000000000000000000000000000000000000000000000002 02C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5
1JtK9CQw1syfWj1WtFMWomrYdV3W2tWBF9 0000000000000000000000000000000000000000000000000000000000000004 02E493DBF1C10D80F3581E4904930B1404CC6C13900EE0758474FA94ABE8C4CD13
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e 0000000000000000000000000000000000000000000000000000000000000008 022F01E5E15CCA351DAFF3843FB70F3C2F0A1BDD05E5AF888A67784EF3E10A2A01
19p7ktDbdJnmV4YLC7zQ37RsYczMZJmd6q 0000000000000000000000000000000000000000000000000000000000000010 03E60FCE93B59E9EC53011AABC21C23E97B2A31369B87A5AE9C44EE89E2A6DEC0A
no tresult :
0000000000000000000000000000000000000000000000000000000000000003
0000000000000000000000000000000000000000000000000000000000000005
0000000000000000000000000000000000000000000000000000000000000006
0000000000000000000000000000000000000000000000000000000000000007
0000000000000000000000000000000000000000000000000000000000000009
..............
Whay?!!

Good! Is there a security audit of this program? I personally can't read the code, and neither can 99 percent of users. And what if the developer of this program has implemented in the code that the basic keys are repeated. It may be a large range, so users will not notice. Then, at the appropriate time, all addresses created with this program will be emptied. So the base key is a security threat.

If specify the corresponding public key using -sp option, the tool just adds some "unknown" number to the priv key. This is very useful for work delegation.

My question was about start search from the exact priv key. You have base key in your tool, but it is not determined as the exact 256bit number to start, it is determined by the seed. How do you receive the base key from the "-s seed" option as the starting point?

I dumped the p2pkh and the p2pk addresses from the chainstate of a full node and that's about 22mil at the moment...

I published a new release. 1.16.

It is impossible to add to the algorithm a kangaroo so that it does not search by public key, but by address? Suppose this takes longer, but you can search for keys for addresses without an outgoing transaction. Or is the kangaroo algorithm not suitable for this?

I've optimized the code. Hopping speed improved about  50% per core.
with 4 cores I've reached 850000 h/s.
Timing:


 

We have updated the OP with our latest results.  Here is a summary of the results of runs for tests 0 through 49:...