Quote from: mcdouglasx on Today at 04:58:12 PM

Quote from: Bram24732 on Today at 04:06:32 PM

Quote from: newsecurity1986 on Today at 02:57:22 PM

Quote from: Bram24732 on Today at 02:39:21 PM

I think your sentence kinda contradicts itself though, or did I misunderstand ?
They are using probabilities of prefix occurrences to predict where other prefixes are.

no, you're the one who's wrong. According to the latest mcd script, what I see is that they're scanning everything, leaving the least unlikely places for later. This is mathematically true. In 256, it's unlikely to find 2 "aa"s, so in a 256 block, when they find "aa", they skip the rest of the block and leave it for later. This makes a lot of sense theoretically. However, in practice, both methods work the same, so they're equally efficient. Neither breaks any laws, neither is better.

Yep, 100% agree. Neither is better.
Isn’t “skipping for later” predicting that it’s statistically not there ? I mean they don’t do all the range stop and start for pleasure, they do it because they think it makes you go faster. This is where I disagree.
And also, it does not make sense “theoretically” - theoretically every event is independent and having 2 “aa” has zero impact on the odds of finding a 3rd one in the next key.

How foolish this man is, he says that by temporarily avoiding the less likely ranges, I'm predicting that it's not there... lol.

The idea behind temporarily avoiding certain ranges is not to predict that the key won't be there. It is a strategy based on probabilistic heuristics. In other words, by identifying that a hash shares the expected prefix, i you infer that, statistically, it is uncommon to find multiple matches in that block. Therefore, i skip the complete exploration of that range to prioritize where, on average, the target is more likely to be found.

This ordering optimization only attempts to reduce the number of checks and the overall search time; at no point is the skipped block discarded. It is processed later in a separate phase, ensuring that the search remains exhaustive and no possibility is overlooked. That is, although a block is “initially avoided”. this does not equate to predicting that the target is not there...it simply optimizes the exploration sequence based on the statistical rarity of prefix matches.

I wouldn't want to mock you, but you're making it too easy.

Not sure you read right.

Quote from: Bram24732 on Today at 04:06:32 PM

Isn’t “skipping for later” predicting that it’s statistically not there ?

That's exactly what you described. Leaving "less likely" ranges for later because you think it's less likely to be there.
The script that you sent shows that it does not change anything, both methods are equally fast on average.