Status as of Sunday, July 15, 2018

[Steve Sokolowski]

Good morning!

• We made a significant change last night that deserves a post all by itself. A few days ago, the NewYorkcoin developers contacted us and pointed out that the difficulties they noticed in the block explorer, and on their block explorers, were different than the difficulty that the mining server was reporting. Upon further investigation, I determined that the conversion from getblocktemplate()'s "bits" field to the block's difficulty was incorrect. In some cases, it was exactly right, but in others, the difficulty was slightly higher or slightly lower than getdifficulty, in some cases up to two times higher. The bug was present since 2013, and I was not able to determine why the incorrect code was used.
• I'm not sure what the implications will be because I only spent enough time to confirm that the fix was correct, but decided that instead of researching exactly how far off many coins were, the time would be better spent resolving the "duplicate shares" issue experienced by some SHA-256 miners. In the case that our difficulty was too high, that meant that the pool was incorrectly submitting too few blocks to the networks, reducing profitability for miners. If there were many coins that had difficulties being reported too high, then profitability should increase significantly today.
• In the case that our difficulty was too low, then the pool was submitting lost blocks to the network, which increased our orphan rates. Since we do not yet have a feature to override orphan rate calculations, these coins will be selected for mining less frequently until the orphans fall off the back of the calculations over the next month. Once their orphan rates normalize, they will be more profitable to mine and profitability will increase as these coins come back online.
• The cursory examination I did perform of which coins are most affected indicated that low difficulty coins seemed to be worst hit. These coins are often mined by NiceHash customers, so it's possible that some of the low luck they exhibit could be explained by this incorrect difficulty calculation. We'll put investigation of the "low luck miners" on hold until August, when we will have enough data using the correct code to determine how much of the problem remains.
• Now that this difficulty issue has been resolved, and the incorrect displayed hashrates have been resolved, the next issue to be investigated is the "duplicate share" issue that is being reported by many miners. Originally, I thought that duplicate shares were the result of incorrectly configured miners, but it seems that there is an association with SHA-256 miners mining bitcoins. Affected miners often encounter periods where all shares are rejected, and therefore the miners continue to display that they have "no valid shares yet." There is something wrong with the mining server, and I believe it's related to miners mining bitcoins, then being sent work for a more profitable coin, and then being returned to bitcoins after a block is found for the more profitable coin. The miners seem to restart the same work for bitcoin, which results in duplicate shares.