We need a strong random search repo .. coz i think searching in ranges is useless (including random range search).. pure random search is the only way .. the only thing that "might" beat extreme randomness is randomness itself .. think about it, you might open a random search bat file to search for the easiest puzzle and find it immediately .. or you can open it and it keeps running for centuries without luck .. but at least you know you could get lucky with randomness ..on the other hand, searching in ranges GUARANTEES you'll stay stuck for a long while especially if the puzzle prv key turns out to be located way far in the range .. i tried keyhunt for cpu but it's too slow .. also tried random bitcrack search but i hate the fact that it creates sample points to start searching from .. it's exactly like random range search not a pure random one .. could not find any software that utilizes gpu for absolute random search
For GPU, it would be slower than normal search. Example, a sequential search for keyhunt will be much faster than a random search. I have modified keyhunt and vansearch to do random search, but it's still somewhat sequential. If you have 1 million threads on a GPU each one has to rekey, well key 1 is random and then starts going sequential until last thread sets it's random key, and then the whole process starts over. I will dig up old files (at some point) and look at the code again. Granted the 1 millionth key takes less than 5 seconds, but during those 5 seconds, the other keys are in sequential mode.
But at the same time, if you are searching random ranges, you have the same chance of finding the key immediately. And that's what most pools are designed to do; create all ranges in the 64 bit range, and assign those randomly.
Yeah thanks for pointing that out .. i overlooked the price you must pay for absolute randomness .. Rotor-cuda for example shows it very clearly when you run it with a setting of rekeying every 1b key .. counter shows a drop in speed of over 100m key/s during rekey before it climbs back up again after rekey is done ..imagine the rekey after every single key .. overhead would be devastating .. so i guess we have to stick to random ranges after all
Show Posts
