Status as of Thursday, July 12, 2018
Posted: Thu Jul 12, 2018 9:31 am
Good morning! The list of bugfixes continues, as we continue devote all of our effort this week into improving stability and resolving issues.
- A few customers reported that their hashrates in the "live coin status" were lower than those reported by their miners. After some investigation, I determined that the problem is an error in calculating hashrates in the mining server. The mining server computes hashrates by creating twelve buckets of ten minute intervals of shares. After two hours elapses, it starts pushing the oldest buckets of shares off the back of a queue. However, I found that the order of operations was incorrect. The start time for the hashrate calculations would be taken first, and then the queue would be modified, and then the calculations would actually be performed. That means that the number of shares submitted over 120 minutes would be divided by a time interval of 130 minutes, resulting in the displayed hashrate being 8% lower than expected. No money was lost as a result of this bug, as it is solely a display issue. Many of the new Equihash x9 mini miners are most noticeable with this problem. The issue will be resolved in the next mining server release.
- There were two ERC20 token issues that have been resolved. First, some customers were double-paid because etherscan.io's API does not respond quickly in some circumstances. These customers have been notified by a message and will be expected to mine back their negative balances. Since the negative balances covered, at most, one day's payouts, almost all of those affected probably failed to notice that anything was even wrong because they had already mined back the debt before Chris made the corrections.
- Second, some tokens were lost because there is no way to check if a contract is invalid. Several customers wasted almost 15,000 Golem tokens by inputting invalid contract addresses into their payout addresses. Chris adjusted balances to penalize these customers, because they were responsible for wasting their own money by entering invalid addresses. Customers who entered valid payout addresses are not affected.
- I discovered that there are some incorrectly configured miners that subscribe to receive mining jobs, but never send their username or password to the mining server, therefore wasting CPU power for no purpose. The next release will improve performance by starting a 15s countdown timer that requires a miner to authenticate when they connect. If they have not connected, the miners will be disconnected, and if these misconfigured miners continue to reconnect, eventually those attempts will add up and they will be banned.
- I discovered another problem with the ban implementation - it was only functioning on port 3333. Now, all ports are covered, further improving performance by banning misconfigured miners that continually authorize with invalid usernames or password arguments.
- Some coins currently are in error because they have "invalid coinbase addresses." I discovered that the problem results from the mining server never retrying to validate the coinbase address of a coin after initially failing to do so, like during a network connectivity issue. NewYorkcoin is currently affected by this issue and cannot be made to leave error status until the mining server is restarted. Once the next release occurs, invalid coinbase addresses will be retried periodically to see if a one-off connectivity issue caused the problem, and if so, then the error will be removed.
- Today, I'm going to try to get a better handle on how often miners are paid in litecoins because their intended payout coins go into error. We've never had time to gather statistics into this and I want to see if this issue is a widespread problem or not.