I want them in this weekend (we've all hard that before).  The DDoS and bitcoind patches before that really set my schedule behind, but I think I'm close to getting back on track.

The pool pays transaction fees, not the users.  Transaction fees are currently enabled to speed up payouts while the pool recovers its speed.  Once our speed has recovered I will disable the pool paying txfees and the payouts will be confirmed by the pool if nobody else includes them.

Should be fixed now.  The table was running a replace query to update stats.  It should have wiped the table and rebuilt it on each update to clear out old data.

Update on the payouts:

BTC Guild is keeping the full precision payouts enabled going forward.  We are not going to continue protecting people that have not yet updated their Bitcoin clients.  Either a few people lose money because of their personal mistake, or the pool ends up keeping the money.  This way the burden is shifted to the user and nobody can say I'm holding their subcents hostage.  There is still a 0.01 minimum to request your balance to be paid out.

What issue?  The round has been going on for 55 minutes, and you submitted shares in the current round (some even in the last 10 minutes roughly).

I'm seeing the confirmed rewards on your account right now.

Block 1469 has now been re-allocated.  If your reward should have been lower, it has not changed.  If it should have been higher (or wasn't even included), it has been increased/added.

Error on Round #1469 last night when EU (DE) came up.  My error check code was not enabled for EU (DE) at first in case we finished a round while it was coming online (but before it had any shares).

I have the records for all shares submitted by EU (DE).  Later today (while I'm at work if I have a chance), I will run a new calculation on the round, and I will increase the rewards for anybody who's shares were not counted.  The recalculation will only -increase- rewards for those who were not counted.  Nobody's rewards will decrease as a result of the higher overall shares for the round.

Then you weren't mining on those blocks.  Time spent mining when the servers were going up/down during the DDoS did not get rolled into the blocks when the servers recovered this morning.

Can you clarify what you're talking about?  The blocks are being rewarded as they always have:  120 confirmations, or immediately if you donate 2.5%.

Using generic btcguild.com is fine for now.  Once the new server is up that will be pointing to a fully load balanced server.  Until then it points to US East.

Miner stats for the current round have been added.  Page load time is nearly instant thanks to loading all the information from the local server instead of opening connections to the remote servers.  Stats cache is updated every minute.

I will be restoring most of the My Account functionality over the next few hours, and prettying up the page to its former glory.

Working on the caching code right now.  Stats should be up in the next hour.


UPDATE:  Just had a small disconnect on US East.  This was not an attack.  I ran a bad query for caching the worker stats which locked up the tables.

The servers were completely unstable for the majority of the past 72 hours.  Our record uptime on a server was about 1 hour.  Given we didn't find any blocks during the DDoS, no BTC was "lost" exactly, but it certainly was a lot we weren't able to generate.

The total shares lost were (around) 1.5 million, or one block worth assuming average luck.  Given 72 hours of downtime, "one block" of lost data is preferable to another few hours of downtime.

Unfortunately, the limited ups/downs during the attack did not count towards the round we finished after finally coming back online (Round #1464).

He doesn't know how many licks it takes to get to the tootsie roll center of a tootsie pop.

Current priorities with the pool:
  1) Restore full account settings functionality (email address changing, donation percent changing)
  2) Restore worker stats summary (will be using cached values, updated at 5 minute intervals)
  3) Restore API functionality


All of this will be interweaved with getting the new server online.

We just solved a block, servers are still going strong.  Still hoping to get our new "super server" online tonight with the internal load balancing and behind a far stronger ISP/pipe.

US East is coming back up again.  I'm doing as much work as I can on our new server to get it online ASAP, but I can only do so much before my day job starts becoming affected more than it already has been this last week.

The past shares on US East were lost in the transition.  The script that runs to backup the shares from RAM to the HD once per minute was timing out due to all the servers being offline.  I've modified the script to run separately for each server, so if multiple pools timeout (ie: offline), it will still complete on the servers that are available.

Honestly, there's only four options for fighting a DDOS:
1) Wait it out
2) Pay for bigger pipes and hope they're bigger than what the DDoSer has access to.
3) Pay for an ISP that has perimeter level filters to stop the DDoS at the frontend pipes rather than your personal server.
4) Both 2 and 3 combined.

A DDoS cannot be filtered at the server level, or by adding a firewall in front of your server, no matter what people claim.  Your ISP is only giving your server(s) access to a certain size pipe.  If you fill it, you're essentially offline.  A DDoS can flood the pipe even if you are blacklisting them, because your blacklist will not take effect until its in your pipe.