Short-term solutions

We think we have some possible short-term solutions to the problems facing the pool.

Chris is going to write an auto-restart program to restart the mining server after it gets a certain amount behind. That will prevent him from having to be notified and restarting it manually, possibly losing time.

Second, we figured out a way to limit the system's usage fairly. We aren't sure why the solution we put in place to restrict share frequency on Tuesday stopped working well, but we are going to charge more for lower difficulty shares. High-difficulty shares will cost the same 5%, but very low difficulty shares, like 1024 for scrypt or 0.1 for x11, will cost more, perhaps as much as 10%. This is fair because it charges people who use the system the most the most money. It will encourage people to switch their miners to a higher difficulty to pay less fees.

Raising your difficulty doesn't lower profitability, so miners won't make any less profit if they raise their difficulties.

In the meantime, we are continuing work on a permanent solution that will increase capacity, which we plan to release on August 6.

Steve Sokolowski wrote: Chris is going to write an auto-restart program to restart the mining server after it gets a certain amount behind. That will prevent him from having to be notified and restarting it manually, possibly losing time.

This means we lose all shares that are delayed when the server gets restarted?
If yes, then the maximum delay should be as low as possible (without triggering a reload when the server gets a small 1-2min spike).

No, Chris will correct the balances.

I think I also just stumbled upon something that made a big difference. I was able to sacrifice a little bit of performance from the slowest miners to reduce database operator CPU load. Let's see whether this keeps things going for now.

The higher fee on lower diff is an increase on smaller miners (I thought you didn't like republicans)

that doesn't seem fair, considering if I don't set my d= and let the pool set it for me, my typical range is 256,512,1024

If this is only a short term solution, I can understand. But long term it would be nice if you could handle more shares at lower diff.

GregoryGHarding wrote:except this will negatively impact miners with hardware that simply cant handle higher difficulty

quoted from another topic. i would strongly suggest thinking over my proposal for limiting workers to s golden number, and showing pool dead to workers over that number.
this fee proposal seems to be a reverse robinhood approach, will stop high hash miners from using low diff, but cost low hash miners the ability to profit.

mrgoldy wrote:The higher fee on lower diff is an increase on smaller miners (I thought you didn't like republicans)

that doesn't seem fair, considering if I don't set my d= and let the pool set it for me, my typical range is 256,512,1024

If this is only a short term solution, I can understand. But long term it would be nice if you could handle more shares at lower diff.

I second this. Short term (very) I could understand. I know the big miners and renters are where the income comes from, but people like myself who are just starting to get our own rigs and have small hashes are going to be hurt if it stays in place too long. I rent miners a lot, but I'm just getting my own as well and 512 is a pretty common difficulty range for many many low speed miners.

*bonks MrGoldy over the head_"Don't encourage more politics"