x11 difficulty issue fixed

[Steve Sokolowski]

The x11 difficulty issue has been resolved. It turns out that I placed the code to set the variable difficulty in the wrong location when I rewrote it to allow for per-algorithm difficulty settings. The purpose of the original change was to allow us to configure the server so that scrypt difficulty defaults and limits are no longer 2^16 times those of x11, since the number of D3s flooding the market has dramatically and ridiculously pushed x11 hashrate up much faster than scrypt hashrate is going up.

I apologize for the problem. We plan to release a fix later this afternoon after Constance departs for the evening, so that we don't interrupt her training. In the meantime, you can work around this problem by setting a static difficulty for x11 miners using the "d=" password argument.

[meinerkey]

ok, what is your 'recommended, best practice setting' then for difficulty for a D3 Steve? Providing simple best practice recommendations is a good idea, for both you guys and us miners. Thank you as always!

[DrIsk]

Thanks Steve.

Any compensation coming to those of us who had x11 hashpower connected yesterday? Not sure about others, but my x11 miners were put in a state where they were not failing over to backup pools but were also unable to submit shares to prohashing. When I finally noticed what was happening I forced a pool reprioritization myself to get them back producing, but for several hours leading up to this my miners were basically dead.

[Steve Sokolowski]

The rule for difficulty, as with other password arguments, is that if you don't know what to do, then don't try to set an argument for it. In most cases, the computer can figure out the best settings for your miner better than you can.

As to compensation, no money was actually lost. All that happened was that the difficulty was set higher than normal, and difficulty doesn't affect profitability. If you had found a share with the high difficulty, then you would have made an enormous amount of money. There was indeed more variance, which resulted in some people finding a share and earning a lot, and some people finding no shares and earning nothing - but nobody was cheated.

[AppleMiner]

As to compensation, no money was actually lost. All that happened was that the difficulty was set higher than normal, and difficulty doesn't affect profitability.

My D3s went from finding 250+ shares every 2 hours to 1 and stayed there.
And they never kicked over to a failover pool, just held hostage not working.
If miners were connected and not able to record shares then it seems like the higher difficulty affected profits somehow.

[Steve Sokolowski]

As to compensation, no money was actually lost. All that happened was that the difficulty was set higher than normal, and difficulty doesn't affect profitability.

My D3s went from finding 250+ shares every 2 hours to 1 and stayed there.
And they never kicked over to a failover pool, just held hostage not working.
If miners were connected and not able to record shares then it seems like the higher difficulty affected profits somehow.

It is possible that some specific mining software might not have been able to interpret the difficulty assignment correctly, that's true. There is probably some software that simply stopped hashing instead of continuing to mine at the requested difficulty, which would be poor design on their part. However, we're certain that we sent valid work to miners, and that shares submitted with the right difficulty were accepted.

[DrIsk]

My D3's were sent a difficulty so high that they could not actually produce a share in a reasonable amount of time and caused alerting to fire on my monitoring systems. (Accepted share values stopped increasing for hours.) I would say that behavior looks like broken to an end user, regardless of what is actually happening.

This seems a good reason to continue to use the d= password argument in perpetuity to avoid an issue like this impacting my hardware in the future.

Thanks for addressing it so quickly Steve.