Duplicate shares issue and adjusting payouts
Posted: Thu Mar 05, 2015 4:30 am
As you may or may not be aware, the pool recently experienced a bug where shares were credited to users' balances multiple times. While most shares were counted once, certain shares were counted many times over. In fact, there were at least 100 occurrences where the same share was counted at least 3000 times. Since the pool's hashrate calculation is based upon the rate of share submission, this manifested itself in the charts as a large spike in hashrate. It pains me to do this, but I am forced to adjust users' balances to ensure that the pool can remain online.
From my research, there were three times when this error was occurring:
March 2 from 15:15 to 19:30 EST
March 3 from 01:00 to 09:15 EST
March 3 from 16:15 to 16:30 EST
March 4 from 04:15 to 15:30 EST
I have the necessary data in our database to find all the duplicate shares and change users' balances to the exact amounts, but this is not a practical solution. The database query to correct the balances would require multiple days to obtain the new balances, if the queries ever finish at all. I know that our users depend on timely payouts, but running the query would require us to withhold payments potentially indefinitely. Due to this issue, I am implementing a different solution:
Since the March 2 balances were already paid, I will not be changing them. For March 3 and March 4, I will be changing balances in the following way:
If you were not mining during any of the times stated above, then your balances will not change
If you were mining during any of the times stated above, then your earnings of the affected period(s) will be equal to your average rate of earnings throughout the rest of the day multiplied by the duration of the error period plus 15% (not to exceed your original balance).
This is a compromise - it is a higher payout than anyone would have earned had the pool been working properly and higher than any other pool paid its users on those days, and it still allows us to pay all our users promptly and remain in business.
I apologize for the inconvenience, and I think you for continuing to mine with Prohashing. As always, I am always here to answer your questions and comments.
From my research, there were three times when this error was occurring:
March 2 from 15:15 to 19:30 EST
March 3 from 01:00 to 09:15 EST
March 3 from 16:15 to 16:30 EST
March 4 from 04:15 to 15:30 EST
I have the necessary data in our database to find all the duplicate shares and change users' balances to the exact amounts, but this is not a practical solution. The database query to correct the balances would require multiple days to obtain the new balances, if the queries ever finish at all. I know that our users depend on timely payouts, but running the query would require us to withhold payments potentially indefinitely. Due to this issue, I am implementing a different solution:
Since the March 2 balances were already paid, I will not be changing them. For March 3 and March 4, I will be changing balances in the following way:
If you were not mining during any of the times stated above, then your balances will not change
If you were mining during any of the times stated above, then your earnings of the affected period(s) will be equal to your average rate of earnings throughout the rest of the day multiplied by the duration of the error period plus 15% (not to exceed your original balance).
This is a compromise - it is a higher payout than anyone would have earned had the pool been working properly and higher than any other pool paid its users on those days, and it still allows us to pay all our users promptly and remain in business.
I apologize for the inconvenience, and I think you for continuing to mine with Prohashing. As always, I am always here to answer your questions and comments.