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.
For a good hash function, like Skein, diversity of inputs has no impact on diversity of outputs. So, if you have no information about the space of possible pre-images (e.g., it is not a human generated password, it is a completely random input from your prospective), then the expected number of attempts before retrieving the pre-image is the same in either case. Should also be the same number of attempts to find an input with a specific hamming-weight from the input.

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.