FROZEN

[icqpepe]

HUNT: Speed: 5.75 GKeys/s | Time: 0d 02h 30m
TAMEs: 3775M (93.0% — FROZEN) | 100% WILDs hunting
Checks: 8656M | T-W: 33401 | W-W: 0 | FP: 38516 | Dup: 7974 | 957.5K/s
BSGS [4 thr]: 25348 pending, 6582 processed, 0 dropped

Maxed TAMES = FROZEN?

[icqpepe]

./psckangaroo -gpu 01 -dp 12 -range 134 -ramlimit 64 -checkpoint 0 -concurrent 1 -pubkey 030ce63a31eeef25a84841377bc27d540f8fbce05504a8997f88711948180b8530 -start 4000000000000000000000000000000000

It should have found this real fast; 4000000000000000000000000000000d2c

address: 1Dzr3qjJjZ56VEru84WexXDCrhWBXeZ6as
public key: 030ce63a31eeef25a84841377bc27d540f8fbce05504a8997f88711948180b8530

it never found it after scanning for an hour. unlike previous solved puzzles it found fast.

[pscamillo]

FROZEN is normal — it means the TAME table reached 93% capacity and now 100% of GPU power goes to WILDs. Working as intended. (I also replied to your PM about this.)

About the solve time: Kangaroo's expected time depends on the range size, not the key's position within the range. Your key ...0d2c is near the start, but that doesn't help — Kangaroo doesn't search sequentially, it uses random walks.

The math:

• -range 134 means the search space is 2^134 keys
• Expected operations: ~1.15 × √(2^134) = ~2^67 ≈ 1.7 × 10^20
• At your 5.75 GK/s: ~940 years expected

Puzzle 70 solved fast because its range is 2^69 → √(2^69) = 2^34.5 ≈ 23 billion ops → a few seconds. Puzzle 135 is 2^32 times harder than Puzzle 70 — not slightly harder, billions of times harder.

Also: your BSGS queue had 25K pending — that means DP=12 is generating collisions faster than BSGS can resolve. Recommend DP=16:

./psckangaroo -gpu 01 -dp 16 -range 134 \
  -pubkey 02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16 \
  -start 4000000000000000000000000000000000 \
  -ramlimit 100 -concurrent 1 -wwbuffer 5 -checkpoint 4

Every kangaroo hop is a lottery ticket — but 2^67 is a LOT of tickets.

[icqpepe]

Ok. Even though we put a starting point, Kangaroo will still randomly do the entire range? For example, #135 START:END; is 4000000000000000000000000000000000 : 7fffffffffffffffffffffffffffffffff and if I start at 7000000000000000000000000000000000 it will search the entire 134 range?

[pscamillo]

The -start parameter sets the beginning of the range, not where the kangaroos start walking.

The search space is always: start to start + 2^range - 1

For Puzzle 135:

• -start 4000000000000000000000000000000000 -range 134
• Searches: 0x4000...0000 to 0x7FFF...FFFF

If you change start to 7000000000000000000000000000000000, you'd be searching a different range: 0x7000...0000 to 0xAFFF...FFFF — which is NOT where the Puzzle 135 key is.

The kangaroos don't search sequentially from start to end. TAMEs start from random positions within the range, WILDs start from random positions offset by the target public key. They do random jumps and collide probabilistically. There's no concept of "starting closer to the key" — every point in the range has equal probability of being reached at any moment.

Always use the exact start/range from the puzzle definition. For Puzzle 135:

-start 4000000000000000000000000000000000 -range 134

[pscamillo]

Important update: Please pull the latest code (v59b). We found and fixed a bug where concurrent mode was not storing TAMEs when DP≥14. Your run with 25K BSGS pending was processing false positives against an empty table.

git pull
make clean && make

Then restart fresh (delete old checkpoint — it has 0 TAMEs):

rm wild_checkpoint.dat
./psckangaroo -gpu 01 -dp 16 -range 134 \
  -pubkey 02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16 \
  -start 4000000000000000000000000000000000 \
  -ramlimit 100 -concurrent 1 -wwbuffer 5 -checkpoint 4

[icqpepe]

The -start parameter sets the beginning of the range, not where the kangaroos start walking.

The search space is always: start to start + 2^range - 1

For Puzzle 135:

• -start 4000000000000000000000000000000000 -range 134
• Searches: 0x4000...0000 to 0x7FFF...FFFF

If you change start to 7000000000000000000000000000000000, you'd be searching a different range: 0x7000...0000 to 0xAFFF...FFFF — which is NOT where the Puzzle 135 key is.

The kangaroos don't search sequentially from start to end. TAMEs start from random positions within the range, WILDs start from random positions offset by the target public key. They do random jumps and collide probabilistically. There's no concept of "starting closer to the key" — every point in the range has equal probability of being reached at any moment.

Always use the exact start/range from the puzzle definition. For Puzzle 135:

-start 4000000000000000000000000000000000 -range 134

I wasnt looking for no concept of starting closer to the key. I was just wondering could it be more targeted within a specific range parameter instead of the entire range. "The kangaroos don't search sequentially from start to end." But it does always start within the range and not exceed the max(end) range point?

[pscamillo]

Yes, correct — kangaroos always stay within the defined range. TAMEs start at random positions between start and start + 2^range - 1, and their jumps wrap around within that range. They never exceed the boundaries.

You can't target a sub-range to speed things up though — the algorithm's math requires the full range to maintain collision probability. If you shrink the range, you'd be assuming the key is in that sub-range, and if it's not, you'd never find it.

Think of it like this: the range defines the haystack. The kangaroos randomly bounce around inside that haystack. You can't make the haystack smaller unless you know something about where the needle is — and for Puzzle 135, we don't.

[icqpepe]

You can't target a sub-range to speed things up though — the algorithm's math requires the full range to maintain collision probability. If you shrink the range, you'd be assuming the key is in that sub-range, and if it's not, you'd never find it.

Think of it like this: the range defines the haystack. The kangaroos randomly bounce around inside that haystack. You can't make the haystack smaller unless you know something about where the needle is — and for Puzzle 135, we don't.

"you'd never find it" - But wouldn't the search stop after covering all possibilities or just an endless search repeating itself?

I would rather search 1000 smaller hay stacks with 1000 - 10,000 workers than 1 ginormous hay stack with 1-10,000 workers. To me, that covers more search area. Its like building a house with a 3-5 man crew. I would rather the framers, roofers, electricians, plumbers, ect.... with each crew having 3-8 workers.

This would be an optional option for those who think they may have a clue or an idea of the specific area to search but don't know the exact location.

Instead of searching the entire 50 United States, you can shorten the search if you know what State, City/Town, Street.... For example, I know its in Austin, Texas of the United States of America. The search is then narrowed down to a specific street address in Austin, Texas. Lets say the public key is the street name, subdivision name, or maybe the street number. Then we know to look for this exact public key in Austin, Texas USA.

[pscamillo]

I understand the intuition, but Kangaroo works fundamentally differently from brute force — and splitting the range actually makes it slower, not faster.

Why splitting hurts:

Kangaroo's expected operations = ~1.15 × √(range size)

• 1 range of 2^134: √(2^134) = 2^67 operations
• 1000 ranges of 2^124 each: 1000 × √(2^124) = 1000 × 2^62 = 2^72 operations

That's 32× slower for the same total coverage. The square root is the key — Kangaroo gets its power from searching one large range, not many small ones.

Your house-building analogy actually proves the opposite:
Imagine you need to find one specific nail in a warehouse. Kangaroo is like having two teams start from opposite ends and meeting in the middle — you only need to search √N, not N. If you divide the warehouse into 1000 rooms and search each one independently, you lose the "meeting in the middle" advantage and end up searching all N nails.

If you "know" the sub-range:
If you genuinely have information narrowing the key to a smaller range, yes, you can set -start and -range accordingly and it will be faster. But for Puzzle 135, no one has that information — the key is uniformly random in the full 134-bit range.

Bottom line: Kangaroo is already the optimal algorithm for this problem. The only ways to go faster are more GPUs or better luck.