Can you be more specific please? Which provider is blocking this new ip (178.79.183.97)? I tried to find it on some blacklists and everything looks clear for me, but maybe I'm missing something...

Last days were very hard for me and I was doing my best to recover pool to normal operation as fast as possible. During those very long nights I had many thoughs if this is the end of the pool; people will leave it because it isn't working realiably soo long. Now I see hashrate is slowly rising back to normal, which is the best satisfaction for all my work. Thank you a lot for your support!

Philj: I'm working on it right now. If I don't asleep with my head on keyboard, it will be later today (UTC).

If you have shares rejected _after_ block broadcast, then try restarting your miner. Some miners have bug that they don't reconnect to new LP URL given from server once they're already connected somewhere else. So maybe you're accepting jobs from different backend than you're submitting to...

Boyd: I'm working on it. Most probably today, but you never know; I didn't expect that DDoS issues as well...

All connection issues should be fixed. If your miner still don't work, please restart it to let it use actual DNS records.

Remember: There's checkbox on profile page, it displays namecoin settings.

Worst? Definitely not :-D There were already rounds with CDF over 99%

I'm sorry for that error message, it was huge miscommunication from side of ddos prevention company.

Although attack seems to be gone, there are still some minor issues making connection less stable, which will be here for few hours.

However this should not affect mining hashrate so much, at least with miner which support long polling and NTime rolling (poclbm, GUIMiner with poclbm core, cgminer). Thanks to this, mining isn't stopped on share submitting latency.

User bars aren't a problem; problem is that pool is calculating hashrate using current round only, which is insanely inaccurate on round start. So I need to rework hashrate calculations to make userbars useful...

Pool rounds #8393-#8396 has been recalculated using proportional (share based) mechanism to don't beat those miners who failed to connect on the end of rounds.

It isn't first time today why it seems solved .

Please restart your miners; DNS changed again and some miners don't resolve them once again during operation.

Lol, I personally understand it wasn't a real question. However I'm considering this in real life, because attackers are using those information.

actually whitelisting isn't necessary, normal traffic is passing thu also, but whitelisted IP don't need to pass filter.

Now is adding new IPs to whitelist not possible as I exported that whitelist to ddos mitigation company, sorry.

Actually it's very hard to find time when I'm completely off the Internet. And thanks to one of the first attack to the pool, which was during my holiday, I'm not telling my plans to anybody anymore.

I had only 30min nap while waiting on system upgrade.

Lot of miners disconnected and also hashrate on website is inaccurate for 30 minutes since last problems. But things are going better.

that first DDoS IP ending with .109 is still a little overloaded. If you see many connection issues, you may try few miner restarts to connect miners to another IP from DNS balancing.

But yes, things are going to stabilize a little, at least for now.