Bitcoin Forum

I am forking Kangaroo 256 based on my own ideas and understanding of what I consider most optimal.

I will update the project in my free time as I have other ongoing commitments.

To clarify, I am not against Kangaroo; I just believe that something more is needed to push forward future puzzles. However, I will strive to make it efficient.

I have started with some modifications, and you can begin testing them.

The usage remains the same: .

This post is self-moderated because these are my own ideas, and I do not need criticisms without tangible arguments. Respectful criticisms will not be censored.

I have only tested it with the CPU version as I do not have a GPU, but contributions are welcome.

https://github.com/Mcdouglas-X/KANGAROO-256-CUSTOM
 (https://github.com/Mcdouglas-X/KANGAROO-256-CUSTOM)

Could you explain your ideas?

Retrieving ideas from the code is a tedious operation.  ;)

Hi Bro. Can you implement multy pubkey support?

ps thank you fo automatic DP selection ,JLP don share info how  to select his "UFO secret" right.

the main idea is to achieve higher precision in success rates by properly selecting the Dp and jumps according to the range, ensuring it is sufficiently random for each range without being too random to stray off the path.


The only case I see feasible for searching for multiple public keys in Kangaroo would be if they were all connected to a single point by means of random additions and subtractions to the target.
In this case I would only do an additional addition or subtraction to obtain the private key.

How do YOU determine the "best" DP? It was already in the original code based on x y and z. How do you plan on determining the "best" (properly selecting according to the range)? And how will you know if a random is "too random"? These comments do not make much sense to me, so, please explain.

The multi pub, via additions, is done with each jump. Think about it.

If you add multiple pubs, then you are slowing down the jumps / machine speed. Cobras has been told this many times, there really are no advantages for multi pub. Meaning, if you add 1,000 pubs to the search, to search at once, then your program speed is slowed down by 1,000. I have a GPU program that can check 1,024 pubs, at once. There was no speed up in time solved.

Maybe be useful 

https://bitcointalk.org/index.php?topic=1306983.msg64710806#msg64710806

Selecting the optimal DP might involve a combination of testing and tuning based on statistical analysis or heuristics that allow predicting success at different ranges. Too high a DP might be overly accurate but inefficient, while too low a DP might be fast but inaccurate.

As for the randomness in the jumps, it is necessary to avoid predictable patterns, but too much randomness can result in significant deviations that negatively affect performance.
As for what I mean by "too random", I mean finding a balance in randomness so that it is enough to avoid predictable patterns but not so much as to move away from the target points within larger ranges.

According to Chaos Theory, sensitivity to initial conditions affects probability, so an inappropriate configuration may seem the best option at low ranges, but this does not mean that it is the best for the puzzle 135, 140...


You are right, it would not be efficient to focus on searches for multiple public keys.

Just some feedback, I have built and run the software with cuda 86. It does seem to run with the gpu but it does not find the match on the smaller challenges (50, 55, 60) the CPU seems to come back with the match reliably.

50

• SolveKeyCPU Thread 14: 1024 kangaroos
• Done: Total time 01s  

55

• SolveKeyCPU Thread 13: 1024 kangaroos
• [65.43 MK/s][GPU 0.00 MK/s][Count 2^28.96][Dead 2][08s (Avg 06s)][282.3/321.7MB]
• Done: Total time 08s

60

• SolveKeyCPU Thread 09: 1024 kangaroos
• [61.55 MK/s][GPU 0.00 MK/s][Count 2^30.94][Dead 1][34s (Avg 25s)][1.1/1.2GB] MB]
• Done: Total time 36s

I will have a bit of a look around when I get some more time.

Thanks for sharing your logs. I'm working on improving it to achieve a 50% higher success rate and optimizing it. Once I get my hands on a GPU, I'll start working on porting it to the GPU version.