closerHash returns a hash; after scanning all 3 input hashes.
Then the returned hash is only used to compare to ipHash again.
It could be faster to return a boolean hash1IsCloserOrSame(reference, hash0, hash1) and thus avoid the extra hash comparison.
Another option would be to compute distance (reference, hash) only, and store winningDistance along with winningHash
That way for each step you only need one distance computation instead of 2, hash0 being winningHash computed over and over.
Edit: The following is not true after a closer look. I left the comment anyway
Also, in dense regions, 15 tickets are computed 15 times each, while only the last IP can get them.
At the expense of more complex logic, several hash and comparisons could be avoided (unsure of the global perf gain vs code complexity)
Sorry if you already benchmarked these and there is no significant gain.
Thanks for the nice algorithm!
Maybe a slight improvement:
https://github.com/n-y-z-o/nyzoVerifier/blob/adaf536b22a0b3448433cb69fb406811c599fdba/src/main/java/co/nyzo/verifier/NewVerifierQueueManager.java#L242
closerHash returns a hash; after scanning all 3 input hashes. Then the returned hash is only used to compare to ipHash again. It could be faster to return a boolean hash1IsCloserOrSame(reference, hash0, hash1) and thus avoid the extra hash comparison.
Another option would be to compute distance (reference, hash) only, and store winningDistance along with winningHash That way for each step you only need one distance computation instead of 2, hash0 being winningHash computed over and over.
Edit: The following is not true after a closer look. I left the comment anyway
Sorry if you already benchmarked these and there is no significant gain.