It looks like the DDoS last week is causing lasting problems at BTC Guild.  I've been forwarded 3 different executables by different individuals this week who found trojans on their network, which all point at our pool.  The accounts have been banned, but that only stops them for a few hours.  It looks lik the downtime @ deepbit/slush forced them to move to us, as if we didn't have enough problems with bots already.

I'm working on a dynamic IP/worker correlation that will hard-limit the number of unique IPs a single worker can use.  It will have some allowances so dynamic IP users don't get auto-banned.

If this fix doesn't get them to leave the pool alone, the only option left is imposing a fee.  BTC Guild has been a magnet for botnets since we were the largest 0% fee pool by a large margin for the last 6 months.  A pool cannot scale to tens/hundreds of thousands of CPU miners.  It is simply not possible to maintain enough servers to support them at the current BTC rates, and they are hurting legit users.

In the meantime, I've loaded up some of the old VPS servers we have, and have the loadbalancing split across those servers as well as the PoolServerJ servers.  My personal miners (using cgminer) only had one communication failure overnight, and it's very possible that was a problem on my end.

There is a big difference with SMPPS.  With SMPPS it is laid out ahead of time that your rewards won't be paid out at full rates (delayed/backpay) if the pool has extended bad luck and eats through the buffer it built up from good luck.  You will be waiting on your rewards until the pool has enough good luck to end up positive again.  Pure PPS makes no such arrangements.  Either the pool shuts down when it can't pay out its stated rewards, or it pays it out of its own pocket.

SMPPS is just proportional with capped rewards, unless the owner puts money from their own pocket in during bad luck.  At which point they may as well have been pure PPS to get rid of the fine print.

Ars and Eligius are not PURE PPS.  There is no payout buffer involved with the PPS pool as there is with SMPPS.

And a black past managing DDoS?  The first major DDoSes were in June.  Deepbit was down longer than BTC Guild.  In July we were specifically targetted, and I took my vacation days at my day job to manage the situation as best as ANY pool admin could.  This time?  We've had the most uptime of the big 3.

Not to mention the post was referring to our PPS pool, which has only had downtime when a planned upgrade to the pool server software was done (and that downtime was measurable in seconds).

Looks like the attacks are dying down on all fronts.  This morning the pool was having up/down connectivity for about 50% of the pool [one node was overloaded from direct connections+sticky load balancing].

I don't think any pool op is ready to say its over and things are back up and running like usual, but things are looking much better right now.

My point is they can't handle the botnet, which is why the botnet is currently throwing a temper tantrum with the major pools.  They have nowhere else to mine right now.

Artificially lowering the difficulty is not really effective.  They have to extend the higher difficulty in order to force the next one lower, so it really isn't going to be this massive gain in profitability.

This is just a pissed off botnet, the same one that took us offline in July, and probably the same one that took all 3 major pools down back in June.

The only reason I've been able to stay online (although we have had a few outages when this all started) is that a large potion of the botnet IP addresses were forwarded to our ISP, which may have been what sparked these attacks in the first place.  I had been actively gathering IPs of known infected machines for about 3 days, and let our ISP know that we would be forwarding them a list of infected machines that we would like to get filtered from our servers [I had received emails from the ISP about null'ing our server due to complaints about infected machines pointing at our servers].

A few hours after submitting the list, the attacks started.  This is similar to what happened back in July when I banned a large botnet at the server level, and they DDoS'd us offline for 2 or 3 days.  This time it seems like they're just throwing a fit and trying to take down all 3 major pools.  The small pools can't handle the load of a botnet, and the large ones keep working on kicking them out.

And now all 3 pool servers are down.  I have a few weaker machines I'm bringing up that will proxy connections to our backend.  If they go down I'm out of options until the attackers stop.

I'm referring to the fact that this all happened a few minutes after I posted that I had submitted a giant list of IPs that I had been collecting from the botnet miners the last few days.  Could very easily be the childish mentality of these "hackers":  "Oh yeah, well I'm going to take my ball and go home, but first I'm going to pop your ball."

Maybe I poked the hornet's nest with my IP list this morning...one mining server is now completely offline and can't be accessed.  Moving the load balancing around, sorry for the downtime but it looks like its hitting everybody right now.

Right now merged mining is mostly being put off due to lack of time, a few new business ventures I'm trying to launch by the end of the year.

When it does hit, I'm still working on how I will go about awarding the coins, and how to make it easy to understand when reviewing your rewards.  It will probably just merge any NMC balance changes into the bitcoin round, so when we found a BTC block, it will include a separate column for NMC earned, and namecoins mined during that BTC block will be split using the same percentages.

I don't think so.  Our attacker wasn't malicious, it was just one of the many trojans out there that try to use BTC Guild.  A large # of CPU miners will make a pool unresponsive, there's nothing any pool can do to stop it other than throw more hardware or attempt to filter them out at the ISP level (once they hit your machine they're already straining your servers).

Deepbit seems to be completely offline right now, which points to a deliberate attack rather than just a botnet attempting to mine.

Been fighting off a persistent botnet for the past 48-72 hours.  Things should be getting back to normal now, contacted the ISP with a database over over 500,000 IP addresses that were involved in the attacks.

Grabbed a RIFT timecode for myself and a few friends, very fast and great price .

But I thought SolidCoin 1.0 zombies already concluded that I am also Tycho, Slush, and Satoshi....so....

If I = Tycho = Slush = Satoshi
And Lolcust = ArtForz = BitcoinEXpress = Satoshi....

That means I have 7 million TBX, along with well over 50% of the hashes, right?  I guess need to get some therapy so my alter egos stop hiding things from me.

The last share issue should now be fixed (it should no longer show 24 hours randomly).  The idle miner email issue has also been fixed, you should resume receiving idle emails if something is wrong with your miner.

Just to add a reference point, BTC Guild pushes out between 6,000 and 8,000 LPs depending on the time of day.  Our average time is between 600ms and 1000ms.  It can be even faster if both of our bitcoinds detected the new block simultaneously (our record was 490ms for ~7,500 LPs).  This is with two bitcoind clients, running on dedicated servers.  One is local on the same server as PSJ, one is running on another server in the same datacenter which runs the database.

This may improve even more soon, ArtForz has been looking into an extra optimization in bitcoind's getwork code and merging it with JoelKatz's 4diff patch.

BTC Guild will begin offering merged mining on the PPS pool shortly after its available, assuming all goes well.  The proportional pool will lag a bit behind and possibly never adopt it, depending on how much rewriting it requires on the database/pool server side.

Stalled round has been fixed, sorry for the delay (went to bed thinking we were just in a long round, when I woke up it was obvious that was not the case).  Estimated worker speeds will be back to normal estimates after 15 minutes as well.

This will be fixed this afternoon, it broke when I changed worker stats to a live display.  I'll also be fixing the last share counter so it continues to count (it currently gets stuck after a while).