Quote from: nicehash on November 06, 2016, 07:15:23 PM

Quote from: mrb on November 06, 2016, 01:43:58 AM

I have a question for you: why does 1 of your 2 servers behind equihash.eu.nicehash.com returns a 17 bytes nonce (37.58.117.214) and the other a 5 bytes nonce (5.153.50.217)? Only the latter is supported by silentarmy.

Please revise the official stratum documentation at https://slushpool.com/help/#!/manual/stratum-protocol. There are no such limitations, a nonce can be even larger. The fact that you're receiving different nonce sizes is not related to a particular NiceHash stratum endpoint. It is simply a fact that NiceHash is forwarding work from different hashing power orders, which are working on different target pools. Anyway, 17 bytes nonce is the largest (max) that you'll receive from NiceHash stratum and even at this size you still have 3 bytes for iteration. So there is no reason why not to accept this kind of work. Please fix this as soon as possible, since our users would really love to use your miner and are now not able to do so due to these limitations of your miner.

Thank you and keep up the good work!

I am trying to be conservative/safe. Because the fewer bytes you have to iterate the nonce, the higher the chance is that a fast multi-GPU rig will have 2 GPUs that accidentally work on the same nonce. I am planning to release a significant speedup where an Equihash round might take 20ms or less. With 7 GPUs running 3 Equihash instances, they will exhaust 1% of the 3-byte nonce space in 150 seconds. So there is a ~1% chance that duplicate work is being performed by 2 Equihash instances.

In practice this is not so much a problem because new mining jobs are pushed more frequently than every 150 seconds, but still... this does not give me the absolute confidence of correctness that I like SILENTARMY to have.

Anyway, I pushed a nicehash-compatibilty update to tolerate stratum servers fixing 17 bytes of the nonce: https://github.com/mbevand/silentarmy/commit/0d371a9582159627b11941c14ca6cbc3da359cb1

Perhaps I will eventually permanently address the issue by allowing the last 12 bytes of the nonce to be non-zero...