The initial (and any follow up) searching for matching 160s, is easy. The collection of and the use of. It is automatic once a partial h160 match is found. Automatic as in setting the padding and entering that range into the db. There is no sparse searching in any space.

You do your db setup up front, with, range / x = y subranges. I let the found partial matches set my initial ranges. And now, I can bounce around with random or gap, each, starting at x and checking to y. This is a test that should be ran lol. ranges ending with ..000000 + whatever search size, or random endings, other than ...0000. I am sure it would all come out in the wash, but would be interesting to test.

Also, my setup allows the easy "do not check, highly unlikely ranges". For example, ranges starting with the same character, 3 or 4 or 5 (whatever filter you want to apply); meaning a range like 0x2222xxxxxxxxxxx - 0x2223xxxxxxxxxxx would not be checked (if your filter said not to check 4+ same characters in a row). I know people will argue over that as well, but to me, that is a range easy to omit in the initial search. Always easy to remove it and allow it to be checked if the other 99.5% keys did not find the winning key. And my setup allows for CPUs to get into the mix; no, they aren't searching as much as the GPUs, but if you have thousands of cores available, why would you not use them, right? Every key searched helps, regardless of the equipment used

But let's be real, it all comes down to firepower. On average, those with the most, will find the key first. Unless someone is really really lucky lol.

ktimesg, did you see the partial match found late last night/early this morn: 19vkiEajfhu8gnX5QUJZReqALvkTncJtgu

Not gonna lie, I had to do a double take because of that 8. I knew an 8 was close after the u lol.