...
i would suggest pool testing on smaller coins where difficulty is not so much, for example: DGB or LCC with just 300M diff.
Just remember that testing in low diff does not test the requirements of the code to properly handle the 64 bit math needed to handle current blocks.i would suggest pool testing on smaller coins where difficulty is not so much, for example: DGB or LCC with just 300M diff.
This was a common problem with proxy writers a number of years ago, where their code did not handle, in all steps of the process, more than 32 bits of data.
e.g. the MANY lost blocks (over 20) on slush, in Dec-2015, were caused by this.
Part of my pool testing of miners, as suggested by organofcorti back when the slush issue happened, is to make sure miners are submitting shares higher than 32 bits within the realms of expected probability.
It's a much lower target than a full block, so occurs WAY more often than a block of course, and thus easy for a pool to detect.
It's not a be all and end all test, but certainly closer to knowing your code does work for bitcoin blocks.
Be wary of armchair experts ...
