Is there a solution to NicheHash's negative deltas issue?

First of all: Prohashing is the most beautiful pool I have ever seen. The help section, the stats section, the functionality, everything. Congrats.

However, NiceHash still has this huge negative delta problem even when I follow the suggestion to use password parameters.

[Archived image unavailable: http://6.t.imgbox.com/6DmSt1Ku.jpg]

Does anyone know current parameters that work best?

Thank you for the kind words. It means a lot to us.

The h=parameter is specifically designed to deal with NiceHash's penalty, and that is what you will want to change. I would try increasing h= to at least h=5, and possibly going slightly higher depending on the results. Some of our other users have told me that above h=10 there is no further improvement in the NiceHash penalty (but profitability declines), but I can't confirm this. You'll have to experiment with h= to find the best balance between profitability and the NiceHash penalty.

knnknn wrote:First of all: Prohashing is the most beautiful pool I have ever seen. The help section, the stats section, the functionality, everything. Congrats.

However, NiceHash still has this huge negative delta problem even when I follow the suggestion to use password parameters.

[Archived image unavailable: http://6.t.imgbox.com/6DmSt1Ku.jpg]

Does anyone know current parameters that work best?

On Friday, I plan to add a new password argument to never refresh when a merge mined block becomes stale, even if the pool computes that it is profitable to do so.

I think that this new feature will help with NiceHash's delta. It will result in the loss of some revenue from merge mining, perhaps about 2% of total earnings for miners who use it, but if we can reduce NiceHash's delta by 10%, that would be a huge win.

h=6 also gives me -25% Delta loss

What a pity.

knnknn wrote:h=6 also gives me -25% Delta loss

What a pity.

We'll have to see whether this new password argument that prevents work restarts for merge mined coins helps at all. Check back later in the week!

knnknn wrote:h=6 also gives me -25% Delta loss

What a pity.

Great news! This new feature is planned for release tonight. You can use "g=off."

Chris will post a tweet when the release has occurred, and you can try it out. Happy mining!

Steve Sokolowski wrote:

knnknn wrote:You can use "g=off."

Should I additionally use the h= or d= parameter?

Unfortunately, a bug showed up in the release tonight and I had to revert, so g=off is still not available until Steve gets a chance to debug the code today.

To answer your question about h= and d=, I am not sure how using g=off will affect h= since we can't figure out NiceHash calculates its penalty. In the best case scenario, g=off will prevent the penalty from occurring, and you won't have to use h=. In what I think is more likely, g=off will reduce the NiceHash penalty significantly but you will still need a h= parameter to get the NiceHash penalty low enough to make mining profitable.

d= should not affect NiceHash at all; a higher difficulty is intended to conserve bandwidth. I think NiceHash requires a share difficulty of at least 4096, but we have our pool configured to start at 4096 and automatically increase if necessary so you shouldn't need the d= parameter.

Chris Sokolowski wrote: so g=off is still not available until Steve gets a chance to debug the code today.

The g parameter is mentioned now in the help section. Is it ready to use?

knnknn wrote:

Chris Sokolowski wrote: so g=off is still not available until Steve gets a chance to debug the code today.

The g parameter is mentioned now in the help section. Is it ready to use?

No. We left the new website so as not to create two more website restarts, but the mining server is still using the old version. When Chris gets up in three hours, he plans to release the mining server, which I fixed this morning, right away.