Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
WanderingPhilospher
on 19/03/2024, 14:25:37 UTC
Lol, yeah, I do not think you understand the Kangaroo algo.

It's all laid out for you in various readings/papers.

I never said 9 billion kangaroos. Do you understand the algo? When I say "find" x amount of tames and wilds, it is referring to the points/distances found by each type of kangaroo. You store tame and wild points (Based on DP used) and distances, that are generated from the tame and wild kangaroos, hopping all around.
2^66.05 - 2^32 (DP size that I stated) = 2^34.05 stored DPs. 2^33.05 tames and 2^33.05 wilds. 2^33.05 = 8,892,857,981; so roughly 9 billion points and distances stored (tames and wilds) to solve, on average. Could be a little higher, could be a little lower. So no, I was not "kidding". And yes, my times are based on math, and the space complexity is what I said, roughly 9 billion points & distances per tame and wild, to solve. I can't give you exact amount of GBs required because each Kangaroo program stores points differently, different amount of bytes and different formats, binary vs plain text. One would need to calculate it based on their DP and how the points/distances are stored.

But yes, you could set out 2 kangaroos, 1 tame, and 1 wild, and eventually solve, in many many years, or you could get lucky and solve within minutes, hours, days.

I doubt whoever solved 120/125, if they used the kangaroo algo, set a DP of less than 28. They would have an enormous amount of DP overhead, that JLP explains well in his github:
Code:
DP overhead according to the range size (N), DP mask size (dpBit) and number of kangaroos running in paralell (nbKangaroo).

110 and 115 were both solved with DP 25. I know that during the 115 run, the grid sizes for the GPUs were choked down and another part of the code was reduced, to prevent a massive DP overhead. And when finally solved, I do believe total DPs stored (points w distances) was a smidge over the expected total of 2^33.55
So your estimated times include the DP overhead?
Because I did a lot of simulations on lower puzzles to get min/avg/max jumps and stored footprints, and, as you can guess, when the DP criteria kicks in, storage goes down, number of jumps until a collision goes up. And there's a lot of ways to improve either space or time, but not both.

So it is not fair to still call the time complexity anywhere near O(sqrt(n)) when you're using 2*sqrt(sqrt(n)) stored items instead of the average 2*sqrt(n).

Steps until a collision can range between expected average / 10, and 3 * the expected average.

And JLP kangaroo is not some godly reference, I did not use it at all, for one I don't even agree with the way jumps and hashmap keys are used, but that's another story.

No one says you need to have 50/50 tames and kangs. And no one says you even need to store the entire traveled distance. There are various techniques.

Ok, it's obvious you do not even understand DP overhead, or what the overhead even means. Overhead does not mean/equal the space/time tradeoff; it seems you keep going back to time and storage or both.

Code:
So your estimated times include the DP overhead
Overhead doesn't equate to time.

And yes, there are 2398749327984 ways to skin a cat or use a Kangaroo.

You did a lot of simulations eh? I've ran thousands, probably tens of thousands, of tests and benchmarks when creating my own modified version of Kangaroo. The solve times I posted above, are accurate, for the version I use, and probably the same for the GPU publicly available ones as well.