# Would it matter if my miner was hashing random vs incremental values?

I'm working on my miner for my "game" site that's basically a pre-image attack from a hash posted online. You submit a hash input, it's hashed, and your score is the hamming distance (the number of bits that differ) between the two values. If it matters, I'm using Skein-1024 v1.3

My miner up until now has been incrementing a value and hashing it. Increment, hash, increment, hash ad infinium. I wrote it so that when I close the miner, it saves it's current highest value that way when I restart it I won't start back over at 1 and hash all the same inputs again. I can pick up where I left off. This has proven to be some what successful. However, I'm curious if the miner might be more fruitful by generating random numbers instead of incrementing.

It seems to be a hard metric to measure. I know that most hashes will output wildly different values if their inputs are off by only a bit or two, but I feel that by incrementing the value I hash I'm usually only a few bits off. If I randomly generate values I'll probably do fewer hashes (because random number generation is more intensive than a simple num++ increment) but my gut tells me that I'll have a more diverse set of inputs and that it might produce a more diverse set of outputs. I know not to trust my gut without reason about this. I feel crazy just typing it out.

I also know that if I increment I'll never end up hashing the same value twice. Random is capable of that although the odds of generating the exact same 64 bit number twice is slim.

Can I expect different qualities of outputs from my miner by hashing random values instead of an incrementing value?

FULL DISCLOSURE: I am the owner and operator of the site above. There are no ads or even analytics on the page.

• You could use Skein as deterministic random number generator and save the state of the Skein hash. Just joking of course, but this is just to indicate that using a random number generator as input for a hash function will likely mean that you spend a lot of time - maybe even more - for the generation of the random number. You may consider using a (PB)KDF instead of just a hash for the hash calculations (e.g. LiteCoin uses scrypt). – Maarten Bodewes Sep 22 '15 at 16:22
• Hey, I have a new bottom score (559)! Do I get a consolation price? – Maarten Bodewes Sep 22 '15 at 16:26
• @MaartenBodewes No prizes (yet...), but I have debated each user having a highest and lowest score because I think a score of 1024 would be just as impressive (and as difficult) as a score of 0. – Corey Ogburn Sep 22 '15 at 16:28
• @MaartenBodewes, actually I think lower is better and 559 isn't all that great (considering it's the highest listed value)... but congraz :P – SEJPM Sep 22 '15 at 16:53
• @SEJPM Obviously anything above 512 isn't "great" to say the least - half of the values should be the same or lower than that. It was kind of funny to get a score on the other end of the spectrum though. – Maarten Bodewes Sep 22 '15 at 16:56

As you note, however, there are benefits to using the counter. You can easily save state. You know you will never see the same input. If you are generating random 64-bit values, the odds of seeing a colliding input is actually not as small as you would think. You would expect to see a collision after $2^{32}$ inputs.