Quote from: kTimesG on Today at 01:04:01 AM

Quote from: WanderingPhilospher on March 26, 2024, 04:52:02 PM

I was able to solve a 128 bit key using an unmodded version, but I obviously knew where the key was and could place the kangaroos in optimal positions.

128-1 = 127, so really in a 127 bit range, because the program subs start range from key or start range is greater than 0.

What good does it do if you will most likely overflow the 128-bit after just a few jumps, no matter what start distance you begin with?

Quote from: WanderingPhilospher on March 26, 2024, 04:52:02 PM

So I advise everyone to do their own DD and take what ktimes says, with a grain of salt. I believe he is the one who was going to solve #66 with pencil and paper. He’ll always spout this and that, and everyone but him is dumb, but hasn’t provided any insight into anything, other than his owned perceived genius.

I never stated I'm solving 66 with pen and paper, only that 66 is a hashing rate contest that has nothing to do with ECDLP at all.
I believe you were the one thinking we only need something like 2* 2**33 kangaroos or whatever to solve #130 in something like 2**66 steps... when the reality is we need many exabytes of stored data to have a 50% chance for a collision, in that many steps you mentioned.

I had zero overflow during tests.

And for 130, I am using the average case scenario and numbers. No exabytes needed. And it’s obvious you don’t understand the difference between a kangaroo and a stored DP.

You do the math yourself, take a DP, we will say DP 32, and you tell me, in your expert opinion, how much storage space is needed, roughly, for solving 130.

I would reference you to OPs GitHub to read on time/memory tradeoff but you’ve already stated you don’t agree with much of what he has said or programmed.

Anyway, let me know storage space required, avg run case, for 130, using DP32