h= password argument added, r= password argument removed
Posted: Sun May 15, 2016 2:13 am
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.
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.