I've thought about it many times.  It would be so easy, and it would be crazy how much I could do with an exchange that had some integrations with the pool to facilitate fast sells/buys.  After dealing with how to scale these pools, the kind of traffic an exchange would get is nothing.

However, I simply don't know what kind of legal trouble it could cause running an exchange, since I live in the US.  And there is no way I could keep working my day job (which I do enjoy, most the time) while running this pool AND an exchange.

EU (DE) server is now online, and is the default for 'btcguild.com', 'eu.btcguild.com', and the now inaccurate 'uk.btcguild.com'. 

A fix was made to US Central's TCP stack settings, and another fix to NL's MySQL settings which were reset after the restart this morning.  All 6 servers are now running smooth.  The website is experiencing moderate slowdown when a new block is found.  This will hopefully be resolved tomorrow when the US West pool migrates off of the webserver into a Seattle based data center.

As stated before, these are the last pool servers that will be coming online until a completely new setup is prepared and colo'd at a datacenter.  The current goal is to setup two servers, each able to support 5 VM pool servers equivalent to our current servers, with a load balancer in front of them.  One for EU, one for US.  These are also easily expandable by adding another 1U server in the same rack at significantly less cost (per month) than the current setup.

NL was back up a few hours ago (didn't remember to post on this forum from work).  Problem was found and fixed.  EU (DE) and US West (#2-sort of) are being readies for being added as servers this evening.

After these new servers come up, I will not be adding any additional servers.  Leasing new servers is not sustainable and adds a lot of overhead to the My Account/API pages.  After the new US West and DE servers come up, I'm going to begin working on getting setting up a custom server solution with a single high power server, split into multiple sub-server VMs and a load balance VM to balance the connections between them.  I have been putting this off due to the high initial cost, but I can almost afford to get the hardware and begin testing.

Once I have this new setup ready and colo'd at a data center, eventually the pool will shift into "two" servers, US and EU.  They will sync up rounds just like they do now.  Each server will actually be equivalent to 4-6 of the current servers in capacity, and will be able to scale significantly better than the current setup.  This means a single server going down will get caught by the internal load balancer and the work will be redirected to a different VM.

If we hit major performance issues before this new solution is ready, I will be capping registrations until it is ready.  We should be able to handle roughly 3.5 TH/sec before that is needed.

US West and website are back online.  Anti getwork spammer code is now in place on all 5 active servers.  Tomorrow will see the US West server splitting from the web server, and possibly the DE server.

US West is down and the site is having a few errors.  Working on getting it back up ASAP.  New US West server has been provisioned so I'll be working on splitting the site and pool apart tomorrow evening.

This evening I will be adding some additional anti getwork spam layers to pushpool.  There are some IPs which are returning only a small fraction of their getworks, but are requesting more than any other user.  This has been affecting pool performance (idles/RPC errors) recently.

This will not affect most users.  The block will only be on the pushpool port.  If your IP address is blocked from requesting work, a warning and instructions will appear on the website.  Once again, the only users that will see this are either attacking the server, or have something severely wrong with their miners.

24 hour figure is back.  US West was a little shakey earlier, due to changes going in to prepare separating the US West pool from the website (US West has been the "master" server this whole time).

I'm hoping tomorrow or Wednesday will complete the separation of US West from the website, at which point we will have 6 pool servers available:
US West, US Central, US East.  EU (NL1), EU (NL2), EU (DE)

Additionally, this means that pool/website activity on US West will not impact the each other.

NL1 restarted.  bitcoind was acting up and not responding in a timely manner.

The string of tests has been removed.  It was a late night debug for US Central stat sync'ing, making sure the worker values were getting returned properly.

You can also refer to http://www.bitcoincharts.com/bitcoin/ to see a list of transactions not yet included in a block.

Your payments will show up, but they can be slow to get their first confirmation since we do not pay transaction fees (we would've paid more than the pool generated by now).

Stats are now fixed for some people that had problems.  I re-sync'd the worker database after UK was taken down and NL2 was put up.  Some workers were set to hidden and later un-hidden on the main server.  This change did not filter into the slave servers so the stats were not being sent to My Account/API.

Regarding our password security:
  All user submitted data to BTC Guild is run through prepared queries to prevent SQL Injection attacks.  Nobody will be feeding bad data into a form, API query, or general page with GET/POST data that will be able to pull down our database information or modify it.

  User passwords are stored using a hash of the original password, and salted with various miscellaneous user data information, system variables at the time of launch, AND a salt string stored on the server that is inaccessible via an HTTP request or SQL.  The only way to obtain ALL of the salt information used on a password would be ALL of the following:
  1) Getting the full user database pulled down AND
  2) Getting the full code used to prepare a salt for the password AND
  3) Accessing the shell to obtain the local system file which contains additional salt data

The shell is IP Blocking SSH and SQL connections from any IP address that is not mine, adding yet another hurdle an attacker would have to somehow bypass to obtain before they could begin attempting to reverse engineer passwords from the stored hashes.

Fixed US Central's last share time.  It wasn't running ntpd to keep time's sync'd up regularly.

If you used the same (or similar) username and the same password on BTC Guild as you do on MtGox, change it immediately.  The leak at MtGox already has many people proving the hashed passwords in the database can be brute forced into their original plaintext.

UK server replaced by NL2 server.  btcguild.com, uk.btcguild.com and the old eu.btcguild.com are now all pointed at NL2 to get the load off of US Central/NL1.

Backup EU server is coming online in the next few hours.

UK server has been temporarily taken offline.  DNS will route you to the NL server if you were pointed at the UK server (assuming your computer and/or upstream DNS servers don't keep the old IP cached for too long).  You all probably saw some errors crop up in your miners pointed at the other servers.  This was due to removing the sync code with the UK server, which required a pushpool restart on each server.

Just to make sure, your worker name being used is (for example): Faraday_GPU1.  And how long is your password?  It seems to have trouble try adding some garbage to the end of it if it's short.  The pool doesn't check worker passwords, but some clients have a problem connecting with short/blank passwords.

The 24 hour number is calculated by taking the average shares it took for each block solve that was done in the last 24h.  So if the block's solve time was within 24 hours, it's share count is included to determine the 24h luck figure.  So it's not exactly 24h, since a block may have been solved 23h 59m ago, but it was started an hour before that.  However, this number gives a representation that is fair in my opinion.  The comparison is to the current difficulty to determine if we were ahead or behind the average.  It is our luck relative to difficulty, not our luck relative to overall network block production in the last 24 hours.

BTC Guild was formed on May 9, 2011.  Just celebrated our 1 month anniversary last week

The percentages are related to the average shares per block in the past 24 hours/since difficulty change.  Red numbers = bad luck, we're taking longer than average.  Green = good luck, we're solving faster than average.