Chris to release bugfixes for mining servers

[Steve Sokolowski]

Chris is going to release some bugfixes to the mining servers, which may cause some brief downtime, with additional downtime if the releases fail and a revert is required.

This, and the other releases recently, have been focused on edge cases. In this particular release:

• Bans due to a large number of rejected shares were previously tracked by username, which could have caused the real customer to be banned if someone else submitted rejected shares with his username. Now, bans will be handled per IP address.
• Undefined behavior used to occur when a customer connected, and then attempted to authorize with the "a=" password argument to an algorithm that uses a different share submission protocol. Now, workers that attempt to do that will be disconnected.
• The ability to mine at different difficulties on RandomX has been restored. Because of the way the ethash algorithms work, it will never be possible for different difficulties to be used.
• Refactoring simplified the code in some areas to reduce the likliehood of bugs.
• A case where workers who have not submitted any shares would encounter an exception while checking for the "hashrate doesn't match worker hardware" error.
• Prevented an edge case where customers who authenticate twice or subscribe twice could end up with bad nonces and other mining information.
• Prevented an edge case where a worker could submit a job that was not assigned to it.
• Removed the "difficulty" work refresh setting, which was rarely used and which we determined could cause issues with share credited. The documentation has yet to be updated with this change.
• Resolved a bug where work assigned to "idle" workers could be removed from memory, causing stale shares.
• Resolved a memory leak that caused data about disconnected workers to remain in memory.
• Bans are now handled proportionally, rather than by an absolute number of submitted shares. Once a number of rejected shares has been hit, a check is performed to see what proportion of those shares have been rejected.

In all of the above cases, we did not find any evidence that these issues ever actually occurred. They are simply being released to prevent them from occurring in the future.

[TechElucidation]

Can I suggest that the IP bans be limited to just 1 hour or something?

You do them to discourage abuse, and if the abuser is cut off and can't do it again for an hour, they will get bored and stop. Unless they are really determined, but in that case they will just go get another IP anyways, in which case banning the original IP no longer has an effect.

By limiting the ban to just 1 hour, if somebody else (other than the abuser) happens to use that IP in the future, they would have no idea why they are unable to connect. In the last few weeks I have seen a couple of posts to this effect on the forums.

This would also help in the event of an issue with mining hardware, where somebody may have a bad device or bad mining software, that suddenly starts submitting bad shares and you flag as abuse. By all means block them to protect the pool, but after an hour they should (hopefully) have fixed it, and be allowed back in.

I just feel a permanent ban is pointless (determined abusers will just get a new IP) and has potential to hurt legit users.

[Steve Sokolowski]

The bans are already limited to 5 minutes. They'll just apply to IP addresses now instead of to worker_names.

I think that all of the complaints that Paula received had to do with website bans. A third party program is used to handle website bans right now. There's a ticket for Michael to improve website ban handling, but that ticket is a lower priority than some of the other critical issues, like sanctions compliance, and cost-cutting, and SEO.

Once Miguel starts on Monday, we can hopefully get the website developing at a quicker clip and he can assist in fixing some of these issues.

[Steve Sokolowski]

I looked into the issue of website bans more closely today. It turns out that many of the banned IP addresses are from people who are using VPNs. While there are some improvements that can be made for home addresses, it's not possible to remove VPN addresses that get banned because they end up being re-banned immediately.

There are so many people who use the same VPN IPs that even people who have nothing to do with the pool could have compromised equipment that goes through those addresses.

[Steve Sokolowski]

Today's release failed. There was a problem with RandomX duplicate shares. The error is accurate and the shares are duplicates, and they were being erroneously credited to customers. The fixes revealed this bug.

For now, we reverted and will continue to pay customers who submit these duplicate shares until we are able to determine the cause and release a comprehensive fix for the underlying problem tomorrow.

[Steve Sokolowski]

This release has been completed. Feel free to submit a support ticket if you have any issues.

We have been seeing increases in luck that appear to be related to some of the bugfixes. Over the next 30 days, as the average luck increases, profitability will continue to increase - it has already gone up by 5% on ethash so far, alleviating some of the price declines.