Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
That's why I don't see the point of accelerating the DP lookup via RAM or bloom filters. They don't really help much, maybe just for educational purposes on very low-end puzzles.
The only issue is that finding DPs will be slow for high puzzles, so the database grows pretty slow. But for example, with a DP of 32, puzzles up to 192 bits are manageable with at most 2**64 entries. For Puzzle 135 and a DP of 32, only around 2**35 entries of storage are needed, which is 32 billion entries. This can fit on a single SSD.
You're talking about another hypothetical script that has nothing to do with this one. But okay. Maybe the author of this script will go in that direction. Then we'll talk about those details.
