Topic: Elitehash Gincoin PPS Pools - 103% (Read 483 times)
Payout rate increased to 103%, and it's been a few weeks since the last payout delay.
Payouts have been stable now for some time, hoping to keep it that way!
I'm sorry for the recent delays in payouts, perhaps the pool should strive to maintain a bigger buffer in case of problems at exchanges.
Payout rate still creeping up, and just added a new server at Singapore!
Paying 102% now. Delays of up to 12 hours in the payments can be expected, it's still better than anywhere else 
Payout rate has been increased to 100.5%
Someone who controls over 40 GH/s (isn't that alarming!?) seems to be joining the pool for short periods of time, only to notice I can't pay them right away when the demand for pool reserves suddenly increases 10x. Then they go back to F2Pool paying 4% fees. How about adding those rigs a couple GH/s per day?
Someone who controls over 40 GH/s (isn't that alarming!?) seems to be joining the pool for short periods of time, only to notice I can't pay them right away when the demand for pool reserves suddenly increases 10x. Then they go back to F2Pool paying 4% fees. How about adding those rigs a couple GH/s per day?
Turned out the different servers had been attempting to use the same inputs occasionally. I scanned the wallets for transactions with negative amount of confirmations, compiled a list & send them and then zapped away the failed ones. Then I realized that because I had cloned the wallets at some point, a big portion of the resends were actually duplicate! Sent over 230 GIN. I won't be counting who was paid double here, of course compellingly honest people can step up, noticing that the same amount got paid twice
These kind of double spends can't happen anymore as I changed the code so that each server pays on schedule, evenly spaced each hour.
After I finally come up with the code for creating a full payout history for each user, complete with txids, this double payout could in principle be counted. But hitting miners with negative balances retroactively like that just annoys people and they can easily change addresses. I'll probably just skip the duplicate payments then, while compiling the history.
These kind of double spends can't happen anymore as I changed the code so that each server pays on schedule, evenly spaced each hour.
After I finally come up with the code for creating a full payout history for each user, complete with txids, this double payout could in principle be counted. But hitting miners with negative balances retroactively like that just annoys people and they can easily change addresses. I'll probably just skip the duplicate payments then, while compiling the history.
The pool has been above 33% at times, and that's already too big for any single pool! Obviously the payout rate can't go back to 97% in this situation, and really the reserves needed with ~2k GIN being paid daily are quite enormous. I'm trying to control the situation by slowly adjusting the payout rate, with the triangle in there pointing up/down stating the overall direction it's going - the rate might be adjusted multiple times per day in small steps, while the direction has changed perhaps once per week.
In case anyone's wondering, the earnings table shows actual past earnings, not future projected earnings. I've seen a lot of miners make this mistaken assumption.
In case anyone's wondering, the earnings table shows actual past earnings, not future projected earnings. I've seen a lot of miners make this mistaken assumption.
There is a new US2 server, which should be used instead of US1 because it's faster.
Page load times are still bogging down because of the slow Scaleway server at EU. Optimizing the code will fix that, the unoptimized code runs just fine on real SSD drives but I guess it's harder to transfer it to a real server than to just optimize the code. I guess I should thank Scaleway because this performance issue would have gone unnoticed without their slow drives.
EDIT: The Scaleway server is gone, good riddance! Load times still have some room for improvement by optimizing the code, but just having proper hardware made it noticeably faster.
Page load times are still bogging down because of the slow Scaleway server at EU. Optimizing the code will fix that, the unoptimized code runs just fine on real SSD drives but I guess it's harder to transfer it to a real server than to just optimize the code. I guess I should thank Scaleway because this performance issue would have gone unnoticed without their slow drives.
EDIT: The Scaleway server is gone, good riddance! Load times still have some room for improvement by optimizing the code, but just having proper hardware made it noticeably faster.
http://gin.elitehash.net
This is the lowest paying PPS pool we have on Elitehash. The pool had such a hashrate spike recently, there was no other choice to prevent bankruptcy with the reserves we have. The lowest payout rate was 90%, but currently it's back up to93.7% 94% 93.2%. Hopefully we can reach 97% after getting some more reserves. I've heard it's not so rosy on the bigger pools either, thanks NiceHash! And BTW NiceHash is not supported at Elitehash.
Pool is offline until new stratum server is deployed!
This is the lowest paying PPS pool we have on Elitehash. The pool had such a hashrate spike recently, there was no other choice to prevent bankruptcy with the reserves we have. The lowest payout rate was 90%, but currently it's back up to
Pool is offline until new stratum server is deployed!
Jump to: