It is possible to reduce a little bit the complexity of the classic kangaroo algorithm by spreading the starting kangaroo in a non uniform maner.
Roughly speaking, if the private key lies in certain areas it will be found faster. As a counterpart if it lies in certain other areas it will be found slower.
But in average, considering the whole range, the compexity is well reduced.
It you read and understand carefully the reference in the gitbub page, you will find the trick

I don't think so, unless someone proove me he has the needed power and is ready to beat the world record 

Yes but we don't have it, so brute force and 2^65 itérations for 50% of success, 2^64 for 25% etc...

With a H100 (PCIe)

Kangaroo v2.2
Start:200000000000000000000000000000000
Stop :3FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 0
Range width: 2^129
Jump Avg distance: 2^64.01
Number of kangaroos: 2^21.83
Suggested DP: 40
Expected operations: 2^65.62
Expected RAM: 1985.4MB
DP size: 40 [0xffffffffff000000]
GPU: GPU #0 NVIDIA H100 PCIe (114x0 cores) Grid(228x128) (292.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^21.83 kangaroos [23.3s]
[5113.99 MK/s][GPU 5113.99 MK/s][Count 2^34.26][Dead 0][06s (Avg 352.678y)][2.0/4.0MB]

You can find the cotation of the hypervisors we use for scientific calculation there (page 12 of my presentation):
https://indico.esrf.fr/event/93/contributions/559/

I checked on #125 with a RTX 4500 and a A100 (the H100 is not yet available).
The needed time evolve linearly with the number of board and you have to multiply by sqrt(32) for #130
So ~1 year to solve #130 with ~1000 RTX 4500 using this program with the required mods.

Kangaroo v2.2
Start:10000000000000000000000000000000
Stop :1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 0
Range width: 2^124
Jump Avg distance: 2^62.04
Number of kangaroos: 2^20.81
Suggested DP: 38
Expected operations: 2^63.10
Expected RAM: 1387.8MB
DP size: 38 [0xfffffffffc000000]
GPU: GPU #0 NVIDIA RTX A4500 (56x0 cores) Grid(112x128) (147.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^20.81 kangaroos [9.9s]
[1514.20 MK/s][GPU 1514.20 MK/s][Count 2^34.77][Dead 0][22s (Avg 207.606y)][2.0/4.0MB]


Kangaroo v2.2
Start:10000000000000000000000000000000
Stop :1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 0
Range width: 2^124
Jump Avg distance: 2^62.04
Number of kangaroos: 2^21.75
Suggested DP: 37
Expected operations: 2^63.10
Expected RAM: 2760.3MB
DP size: 37 [0xfffffffff8000000]
GPU: GPU #0 NVIDIA A100-PCIE-40GB (108x0 cores) Grid(216x128) (277.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^21.75 kangaroos [22.7s]
[3824.79 MK/s][GPU 3824.79 MK/s][Count 2^33.84][Dead 0][06s (Avg 82.0929y)][2.0/4.0MB]

I'll try tomorow with a H100 (if free) just to see the performance.
At my job we have only gpu dedicated to scientific calculus which may be less adapted to integer calculus than a 4090.

In any case it will require a large number of boards and considerable amout of time to get the BTC 

After quick look at kangaroo code, looks like there is 3-bits of 128-bit value used for something. So, it actually really 125-bit max. I can be wrong and I think only JLP can answer 100%.
[/quote]

Hello,
Yes you are right. The GPU code should also be modified to return good distances.
Do not try to solve this puzzle, it will take years using a rendering farm !

Yes, if you specify manually the same seed, the calculation will be the same.

Theoretically it is not possible. The system gets entropy from keyboard inputs, disk usage, network, etc... Then it computes secure hashes from that inputs to generate random number.

There is no way with VanitySearch to specify a priv key range.

Note that with VanitySearch, the generation of the base key (if no seed specified) is done through secure RNG of the system:
CryptGenRandom() for windows and /dev/urandom for linux.

The final private key reconstruction is explained in the README for the simple case https://github.com/JeanLucPons/VanitySearch#how-it-works
This is what is done at the line 323 of main.cpp. Then you find the 5 other cases for symmetry and endomorphism.
The information of which case (out of the 6) has matched during the search is not in the partial key file, the reconstruction just test the 6 cases until one match.
For the reconstruction of a BECH32 address, you simply compute a BECH32 address from the final private key, this is what is done the CHECK_ADDR() macro at line 238 of main.cpp.

Note: The secret private key passed through the command line for reconstruction is stored in e.

I tried your file and for me it is ok...

I'm sorry but I didn't manage to reproduce the issue.
It is the same if you try to reduce the grid size ?

The base key is the key used for starting calculation from. This key is transformed (translation,symmetry and endomorphism) until the target prefix is reached. This base key is generated randomly or from a pass phrase.
There is no way to set it manually to a specific value.

In fact a parallel kangaroo program that look for a single key creates several pubkeys from this key (by simply translating it). So this is a multi key search but this does not decrease the probability to solve this single key. It just allows a simple parallelization.

Usually, for a multi target attack, the first key has no benefit but the following keys can gain from the previous calculation.
If you want to search a pubkey with a x starting with 32 leading F (between n and p), you will have to perform ~2^128 group operations.

The wsplit option works also for normal mode. It is a very useful option to avoid large hashtable in RAM which decrease performance.
If you plan to have a large master workfile (>100GB), you can use partitioned workfiles for speeding up the merge process.
https://github.com/JeanLucPons/Kangaroo#how-to-deal-with-work-files

At the beginning of the process, the speed was the same ?
Avoid to have too large hashtable in RAM even if you have enough RAM on your system, it is preferable to use -wsplit and merge workfile offline.

Could you try to run cuda-memcheck with your input address file ?

Hello,

Could you try to run cuda-memcheck.exe. I didn't manage to reproduce this issue. It may end with "Error: process didn't terminate successfully" but this does not prevent the program to run, this error happens in the exit function...