McD, ktimesg and Bram, you all are arguing over doing the same thing in different ways lol.

McD has changed the way his script, or at least his thought process of how the script should work, versus his initial draft.

There could be the possibility that a 10 matching h160 is right next to another one, but of all the data I have sifted through, it never has happened. It's easy to run a decent sized range, say 2^48, where on average, you would find, 256 10 leading h160 matches, but none of them will be right beside each other. Or you can sift through Bram's PoWs and you will find, none of them are right beside each other either.

So there is nothing wrong with what McD is suggesting. You find x amount prefix, pad it by y amount on both sides (+/-) and keep on trucking until z amount of range is filled up. If key is not found, you shrink all of your previously stored padded ranges by x amount, and search again. The key would eventually be found, just as if you did large range searches, randomly or sequentially, throughout the whole range. Brute forcing an entire range says the magic key will be found on avg, at or around 50% of total range keys searched. That's an average, could be at 1% or 99.99%. The last 2 keys were found between 51-57% via large range searches, selected randomly. There is no way of knowing which is better/faster, as it depends on which key was found and padded, close to the actual key we are searching for.

For me, I would and have tweaked the way McD script/plan works. Instead of just finding random prefixes 100% of the time, you swap over to filling the gaps, with 100% of keys. So if one padded range ends with 0x...12345, then I brute force keys starting at 0x...12346 to however large a range size you want to chew up. I have the padded ranges and the complete search ranges marked differently in the db, so if I need to shrink the padded ranges, I will only shrink those and not the 100% searched ranges.

Now, for what Bibli is doing, I am not 100% sure. I know he finds a prefix and with some calculations, makes a jump and searches for the next. But in this manner you could skip over the actual key. But I am not sure how you would go back and check the gaps you skipped unless you tracked start and end ranges and jump sizes, and then go back in and have to manually fill in those gaps if key isn't found. My issue with this, is you could find a 14 h160 match in 0xF range and spend a lot of time in that range when the actual key could be in the 0x8 range. But I do not know all of the ends and outs of his plan/thought process so I can't speak on it 100%.