It says "And if you drop it like its hot in the first 2 days you get extra SWAG, first day pays out 3600 SWAG per block, day two pays out 2700 SWAG per block and day three pays 900 SWAG per block. "
But all blocks are 450 already ... ??
For now, I leaving again. No value add for committed launch miners!
The server wasn't the problem. We were sitting at 20% cpu usage, and all other pools had no issues during the time.
The issue was to do with the coin's starting diff of 0.03. There were over 1000 blocks every few minutes trying to be submitted to the coin daemon. The bitcoin coindaemon cannot account for this, and ends up freezing up completely. This caused lots of blocks never to be submitted. In this type of situation, there was only two ways you could of mined this coin at the start. 1. Solo mining, or a 2. small pool.
Regardless, we had to wait for the developer to force the diff up to 0.06 before the coin daemon would even start to respond properly. Once it started to respond blocks started being accepted as normal, however it was still too fast for stratum/mysql and the daemon. A common stratum issue arose where the blocks and shares were submitted out of order. In fact, the daemon decided to randomly drop a block every so often too, yet still end up submitting in to the blocks table. This compounded the issue with false blocks in the table, causing MPOS's crons not to execute properly. In essence - the entire database was corrupted.
I spent a good few hours repairing in in real time while miners continued to mine the coin. When I went in to #mpos for a bit of advice, I met other pool admins that were mining SWAG at the start with the exact same issues with the database. Now again, this is caused by the low starting diff of the coin, compounded by the high amount of miners at the start wanting to mine it. The coin itself is fine - just new coins should always start at a difficulty level of higher than 1.0.
I am disappointed by some of the comments people posted on this forum. You guys are worse than grannies in a sewing circle when you get together.. the rumours run wild with little regard to logical thinking.
Binaryclock/dedicatedpool has never lost a database, and has always been able to recover from issues. ALWAYS. Don't be so quick to toss us out the window next time. You should know this by now.
Anyways, I hope this helps explain things.
Now that the original rush of low diff is out of the way, it's time to concentrate on the coin itself. If any pool operators had database corruption from the low diff 0.03 starting, please contact me
admin@dedicatedpool.com or on IRC #dedicatedpool.com. I will be more than willing to help you repair your database with what I've learned from my night repairing mine.
TL;DR - coin had a low diff 0.03 starting - daemon/mpos/stratum couldn't keep up with rate of blocks submitted. database corruption - but was fixed. New coins should always have a 1.0 diff starting. But now that's out of the way, lets move forward and mine this baby.http://dedicatedpool.comRyan, dedicatedpool.com support/admin
admin@dedicatedpool.com / IRC on freenode #dedicatedpool
http://dedicatedpool.com/images/l.png
