~
D. J. Bernstein wrote a great paper on how we can take advantage of this in the ECDLP context. It turns out, that we can do something like this if we want:
bigNumberA = 2**40
smallNumberB = 2**30
In this example, we can spend a decent amount of time working out and storing data for whatever 2**40 private keys that we wish. Once we have this data prepared, when the public key is revealed, we'd only need 2**30 steps to find the associated private key.
Now, let's revisit the solve times, on a RTX 4090 (just for fun):
Precomputing time: 2**40 steps = 138 seconds
Solving time: 2**30 steps = 0.13 seconds
Maybe this should make people understand why puzzles 71 to 100+ are basically sitting ducks, and can be solved in a matter of minutes (in total).
An interesting idea. And it's actually so simple, and very clever. I sometimes read threads about the puzzle, I even searched for private keys before, until I saw that you can hardly do without large financial costs.
P.S. As for the 71 range, I don't see a bot problem at all if the person who found the key uses Mara so that the transaction doesn't end up in the mempool.