Nicehash Extra rewards and negative delta

[leomedina01]

Most of time in my Nicehash orders using Prohashing pool, I'm getting some extra rewards and negative delta, sometimes about 20%, sometimes it's low around 5-10%.

I know this is wasting some of hashing power I'm renting,,,so I'm paying for power that in fact is not being used to mine, therefore, most of time, I'm getting loss instead of profit.

I'm using fix worker difficult at 8192.

Do you know any way on how to reduce this?

Thanks.

[Chris Sokolowski]

Thanks for the report. I didn't know about these "bonus shares" until today. Steve and I need to discuss how to address Nicehash's behavior; this may not be a simple fix. I don't have a solution for you right now, but Steve and I will see what we can do to work around the Nicehash limitation.

According to their site:

Some buyers pools are generating lots of work restarts. This is usually a symptom of coins with very low difficulty or multipools which are switching coins very fast and don't have an efficient implementation of coin switching. In some cases this is also a result of some custom private pools. Excessive work restarts drops efficiency on miners, especially on fast ASIC miners with weak controllers. We addressed this issue by rewarding providers (sellers) with extra shares paid by buyers when fast work restarts happens. If you are a seller it is very important for you to monitor the average mid-term hashrate, reported on our website (it is calculated from shares, rewarded to your miner) and the actual earnings, not only the hashrate or accept/reject ratio that is displayed by your miner hardware/software, since in some cases you will be rewarded for more then your miner is showing you in terms of hashrate.

In essence this means that provider is 100% paid for all valid work that his rigs produces (just as using any ordinary pool or multupool) and buyers pays 100% only for valid work that has been submitted to buyers pools (just as would be using it's own rigs).

It's a 100% fair game for sellers and buyers.

This is concerning because if Nicehash works as described, then Nicehash is incorrectly assuming our pool is broken and penalizing cloud mining renters for using our pool.

Our mining server calculates the miner's work restart time and then uses it to select the optimal mix of coins to maximize earnings. For miners that have long work restart times, we will nearly always assign them coins with long restart times, but occasionally we will assign those miners to coins that have profitability so high that even with frequent work restarts (and lots of wasted work) they will still be earning more money overall. We never anticipated that Nicehash would penalize miners in the latter case making them actually earn less money than mining what we consider sub-optimal coins.

We will get back to you soon with what we plan to do about this situation.

[leomedina01]

Thanks for your prompt reply Chris.

In my tests, I could notice that when speed is growing or falling in a short period of time, sometimes the extra rewards (and therefore negative delta) tends to raise up to 20-25%, sometimes not. However, when speed is constant (I mean there's a low variance), it keeps in an acceptable value at 2-5%.

[leomedina01]

Any update on this?

Today, I'm getting a high percentage negative delta, which means that speed in pool is about 8-25% lower than my current speed, and also I'm getting extra rewards. This is making me have losses instead of profit today.

Thanks.

[Chris Sokolowski]

Would you be willing to share at what price you placed your buy order for hashrate? I'm wondering if you are placing a buy order for the profitability we are estimate at the top of the page then losing money because NiceHash rates miners based upon their perfect hashrate (no work restarts) whereas our calculated payout is based upon the average miner with a moderate number of work restarts.

I really appreciate your feedback because that will help us to modify our algorithm and the data we put on our site to be more useful to our users. We can modify our algorithm slightly to reduce the negative delta, but we will never be able to achieve NiceHash's perfect hashrate; you will always have a negative delta with a coin-switching pool.

[leomedina01]

Yeah, but sometimes negative delta is very high, specially when there's speed variance, sometimes not so much, why this happens?

Like now prohashing's profitability is 0.09665 BTC/GHs/day, if I place an order on nicehash paying 0.09 BTC/GHs/day for example, I have loss, so I'm calculating 0.09665 - 8% (which is the average negative delta in my tests)...

....then I get 0.088918 BTC/GHs/day, so this is max price I can go with a nicehash order to in order to have profit

So for example, today I went with an order price @ 0.0805 BTC/GHs/day, it should have some profit, if you compare to 0.088918,,,but it was not profitable, because all of a sudden negative delta increased a lot....yesterday I had profit, but I had to go with an order price @ 0.0785 to have some profit. You know, it's not very easy to have an order taken at this price or lower, sometimes I have to wait more than 5hours to have a simple order taken and completed, because price is very low.

So did you understand my point of view now?

[Chris Sokolowski]

I see what you mean. The problem we have is that the have to balance profitability with work restarts while ensuring fairness for all users, which is very complicated.

The solution to the issue is to reintroduce static work restart times, which would allow you and others to specify the minimum time between each work restart. This would favor giving your miner coins with longer block times, which would reduce NiceHash's delta. The problem with this feature is that if we don't make other changes, then it is not fair to our users.

We distribute the average of all rewards mined among all users. The highest profitability coins tend to have short block times, but when mining those short blocks, you get lower hashrate. We attempt to distribute those short block coins throughout all users so that no one user had to mine them all the time. By specifying a long static work restart time, you are getting the benefits of earning those blocks while not taking the loss of the lower hashrate.

If we introduce static work restart times, we also have to eliminate averaging earnings among all users. That means we couldn't post a pool profitability since each user would have mined different coins and have different profitability. About the best we could do would be to post a chart of profitability versus work restart time. But the far more challenging task would be that we would have to find some way to ensure that users with the same work restart time get the same earnings, and I don't know how we would even begin to do that.

This change would require modification of some of the most basic functions of the pool, and we don't like to modify working code unless there is a very good reason to do so. Every time you change code, you introduce bugs, which causes crashes, losses of users, and headaches for us. I will think more about how much time it would take to implement this change and calculate its benefits then decide whether it is worth it.