h= password argument added, r= password argument removed

[Chris Sokolowski]

Today, we released a new version of the mining server. We have removed the "r=" password argument and introduced the "h=" password argument. The change comes after we analyzed our earnings and discovered that static work restart times were causing both miners and us to lose money.

Instead of using a static work restart time, the new "h=" password argument specifies the minimum network difficulty of coins that will be assigned to that miner. In general, there is a correlation between high network difficulty and long block times, so specifying a higher minimum network difficulty will result in fewer work restarts. However, since you would be limiting the selection of coins you can mine, you will also have a lower profitability. You can look at the coin status table on the charts page to see current network difficulties and which coins would be excluded for a given h value. The "r=" password argument has been deprecated and will be ignored if it is still in your password.

The "h=" parameter is designed for cloud mining services like NiceHash, who disproportionately penalize miners for work restarts. If you have a miner directly connected to the pool or your cloud mining service does not penalize you for work restarts, then I recommend against using the "h=" password argument since the automatic work restart time will do the best job of limiting which coins you mine to maximize profitability.

This change was prompted by the discovery that inaccurate static work restart times were causing everyone to lose money. On Prohashing, we use work restart times and block times to estimate hashrates that miners would generate mining each coin, which allows us to maximize earnings when distributing pool hashrate among many coins. However, static work restart times throw a wrench into the coin assignment formula we use.

Given the same work and the same hardware, the lower the work restart time, the higher a miner's hashrate. If a miner chooses a static work restart time less than his actual work restart time, that miner is calculated to have a higher hashrate than they actually do. We limit the amount of hashrate we assign to each coin network, so this miner will "take up space" on a coin network without contributing shares. As a result, the miner will make less money due to submitting fewer shares, and other users will make less money due to being assigned less profitable coins.

If a miner chooses a static work restart time greater than his actual work restart time, that miner is calculated to have a lower hashrate than they actually do. This miner will be assigned lower profitability coins and earn less money. Other miners on the pool will have a higher work restart bonus, causing them to earn more money than they are contributing in hashrate and causing us, the pool owners, to lose money.

As you can see, whether the static work restart time is too high or too low, someone other than the miner loses money. I will be monitoring the effects of this change over the next few days. If you have any questions, please feel free to reply to this post.

[gaanthony]

Hum. Two days ago profit looked great with all the changes. Today it appears to have tanked with the latest changes with the restart time changes. I've been holding out for improvements and have been using dynamic difficulty with my Titans. Will give it another day to see before I start testing against other pools again. I also realize LTC jumped to a high two days ago so I have to weigh that in.