I’ll clarify then. Of course your method works, you’re checking all keys eventually.
I’m saying there is no speed boost doing it this way instead of doing it in sequence, only drawbacks because of gap management.Those drawbacks are also minimal if the ranges are big enough, but then you’re only adding complexity to the brute force process for no good reason.
My point is not that it is necessarily better, but that it is the most efficient probabilistic search for brute force in the "
homemade" context, because you are trying your luck with the few resources you might have, based on probabilistic expectation. In your "
pool" context, a "
full random" search is the best option, because it is the easiest way to deal with the problem.
However, in the context of someone who only has a single GPU, a search like this would be better than yours, as they could spend years searching within just a few sub-ranges.
In other words, the optimal strategy depends directly on the resources available and the time horizon at hand.
Nope, still not. Even with a single GPU the odds of both methods are EXACTLY the same. You have 1/(2**67 - nbKeysAlreadyChecked) chance for every key you check, no matter the order. Trying to use probabilities in arbitrary defined ranges does not improve odds because just like with a coin flip, each event is independent.