Significant increase in scrypt profitability
Posted: Fri Jul 09, 2021 3:22 pm
Thanks to reports from several customers, we discovered a major flaw that unnecessarily lowered scrypt profitability. The reported profitability is accurate, but actual amounts earned by customers were often lower due to suboptimal shares.
The cause of the problem is CPU-saving code that was added in 2017, before we parallelized the system. The code only calculates work to be sent to miners the first time a miner is assigned after a new block arrives for a coin. That worked well for years, but when merge-mined coins started to dominate scrypt profitability, the code would not recalculate the work in the case that miners were assigned to digibyte because a new block arrived, then a new dogecoin block arrived, and then the digibyte block was found and it was time to go back to litecoins. For the remaining time until the next litecoin block occurred, customers would be mining the current litecoin block along with the dogecoin block that was current when at the time of the litecoin block's arrival.
We temporarily resolved the issue by simply recalculating every single job and tested it by restarting the mining servers. There does not seem to be a significant increase in CPU load, so for now, we'll leave the code as-is until we can implement future performance enhancements that don't rely on that inaccurate assumption.
The average number of suboptimal shares due to dogecoin stales declined from 16% to 5% for scrypt - although the actual number of shares reported as suboptimal may appear higher in the dashboard because other merge-mined coins may still be stale. The profitability increase is around 8% for scrypt, and 1% for SHA-256.
The cause of the problem is CPU-saving code that was added in 2017, before we parallelized the system. The code only calculates work to be sent to miners the first time a miner is assigned after a new block arrives for a coin. That worked well for years, but when merge-mined coins started to dominate scrypt profitability, the code would not recalculate the work in the case that miners were assigned to digibyte because a new block arrived, then a new dogecoin block arrived, and then the digibyte block was found and it was time to go back to litecoins. For the remaining time until the next litecoin block occurred, customers would be mining the current litecoin block along with the dogecoin block that was current when at the time of the litecoin block's arrival.
We temporarily resolved the issue by simply recalculating every single job and tested it by restarting the mining servers. There does not seem to be a significant increase in CPU load, so for now, we'll leave the code as-is until we can implement future performance enhancements that don't rely on that inaccurate assumption.
The average number of suboptimal shares due to dogecoin stales declined from 16% to 5% for scrypt - although the actual number of shares reported as suboptimal may appear higher in the dashboard because other merge-mined coins may still be stale. The profitability increase is around 8% for scrypt, and 1% for SHA-256.