The OVH that had the issue was only in the EU, and it was not an insider.  It was a very targeted attack and a 0-day flaw/exploit aimed at their password reset system not having enough entropy.  I was on OVH for the EU servers when it happened, but I was able to catch the attacks before anything was broken into, and immediately moved off OVH in the EU.  The OVH servers I have in the US are not registered under an email that is public, nor is it even registered in my name to eliminate social engineering attempts, so the same flaw could not affect them.

However, as I mentioned earlier, I'm planning to expand some of the servers I already have in colocation soon after discussing it with some of the staff related to DDoS activity.  The problem with colocated hardware is you can't easily move to a new server when an attack happens.  Leased dedicated servers can just be dropped/added fairly painlessly.  However, after discussing the colocation with both technical and sales staff, my current setup in Chicago is going to be expanded to move all US based pool servers into that facility.

Core systems for BTC Guild (database, hot wallet, and website) are all hosted on hardware that I own and have placed into colocation.  Only the pool servers themselves are run outside of that, with the exception of Cloudflare acting as a large external proxy in front of the website.

New features [PPLNS CSV export]/namecoin updates are temporarily on hold.  I'm going to be spending the rest of this week working on new database optimizations, as well as implementing some methods to help the future transition to a new database server.  Working on expanding the current US-based colocation early next month to improve the reliability and general speed of all pool servers + database server.  I will try to post updates in advance if anything is expected to cause the frontend to become unavailable.

Two updates:

1) There was a brief restart on all Stratum servers just now.  Total downtime should have been under 30 seconds per server.
2) A new domain has been registered and is being setup for API calls.  More info to come once it's ready.


As always when a server is restarted (or crashes), make sure your miners didn't get stuck!  They may be on a backup pool and not moving back, or in some cases [especially older stratum proxies] they don't recognize the disconnect at all and end up in limbo til they are restarted.

Still checking my order page daily waiting to see something other than Processing .

I can guarantee DNS caching will give you headaches for the rest of your days.  It may not even be DNS servers, but local home routers which are caching the DNS beyond the TTL.  To this day, I have just come to accept that DNS voodoo will leave some people stranded and there's nothing you can do to make it work for everyone.

Lots of small changes going on with the frontend to reduce the impact of the attacks to the website.  You may have seen some failed login attempts, blank pages, etc., during the last hour.  Going to let things settle down for a while and watch how it works out.


If you created an API application that is distributed to many users without the ability to modify the API URL, please contact me for instructions on how the API will be changed.  The old API address will continue to work, but I would like to have you update to a URL that will be accessible even when the website is in attack mode.

Sorry that the site keeps entering attack mode.  The person who is trying to break into accounts has tried millions of passwords by now, constantly changing IPs.  Recently it looks like he has now figured out how to get past Cloudflare's browser verification from attack mode.  Meanwhile, there's another person who is doing nothing but slamming the website with index.php requests in order to slow down the site.

I'm working on moving the API to a different domain name which won't enter the 'under attack mode' today.  Users who designed their own API grabbers will be able to quickly change the URL and access the API just fine.  Users who downloaded someone else's app will have to request that the app maker update it once the new URL is available.

Payout History and PPS Earnings History are now available as CSV Exports at the bottom of your Settings page.  PPLNS CSV History will be available shortly.

As I stated in the beginning, NMC support is not even close to a priority.  For now automatic payouts will continue to be the only method to withdraw in order to avoid heavily fragmenting the wallet.  Namecoin's code is ancient and lacks a significant number of optimizations that have been added to Bitcoin over the last two years.  You will likely never see amounts under 0.01 NMC available for payout.  NMC's transaction fees are higher than BTC for sending small amounts.

24 hours of testing isn't even close to enough, especially when evaluating a smaller pool (which Deepbit would be classified as these days).  It takes -months- for variance to level out on a small pool, and you can end up way ahead or way behind at any point in time.

Cloudflare under attack mode is being turned on.  Additionally, the web server is about to be restarted, so the frontend will not be accessible for 1-2 minutes.


EDIT:  Back online.  Under attack mode still enabled for a little while longer, so some API programs that haven't been whitelisted will not be able to update stats (generally happens when it's a phone app and you're on a cell network IP).

Working on the auto-CSV generator now.  Expecting that tomorrow your Settings page will have CSV download options for Payouts, PPS Earnings, and PPLNS Earnings.

The larger pool would split those bonus rewards (tx fees) with more people.  There *shouldn't* be a difference in how much you make based on pool size assuming uptime and fees are the same.  The exception is that a smaller pool can screw you on variance before big difficulty changes.  On the flip side, you can end up WAY ahead of what you should before those big changes on a smaller pool.  In the long run these shortfalls/big wins should even out, and you can never know which side you'll be on until it has already happened.

No instructions are needed.  All BTC Guild servers participate in merged mining.  If you want to view NMC rewards, the option is in the Settings page.

I'm planning to add a CSV export to PPLNS stats shortly.  As of right now the full history of all shifts is still part of the database, but only 300 (was 200) shifts are loaded.  You can still scroll back to the detail view of any shift when you click 'View Details'.  In the future I will likely perform some kind of consolidation in order to compact the size of the PPLNS history database table.

The pool is finding roughly 1 in 3 NMC blocks.  That is what is expected when the pool's hash rate is roughly 1/3rd that of the NMC network.  There is no bug in the assignment of NMC either, I can clearly see that 97% of NMC block rewards have been assigned to miners.  My only thought is maybe BitMinter only allocates NMC to miners that have NMC wallets set?

BTC Guild's implementation of MM does sacrifice NMC rewards in order to keep BTC efficiency completely untouched.  However, that would only be ~10% of a difference, not 75-80%.

I assume you're referring to pools that don't pay out a block until 100/120 confirmations.  This is because blocks are unspendable for 100 confirmations by protocol, and for 120 confirmations by standard bitcoin-qt/bitcoind clients.  It means the blockchain must have at minimum 100 new blocks which build on that blockchain (thus confirming the block 100+ times) before the pool is able to spend those coins.

Since some pools do not pay orphan blocks, they generally use the 100/120 confirmation period to ensure they never accidentally pay out an orphaned block.

As many of you have seen, the site has mostly been in the Cloudflare 'Under Attack' mode since yesterday.  I was away from my main computer and did not want to have the site performance suffer.  Many API users should have still been able to access the API from their home/office, but phone based applications probably had issues.

The site is back in normal operation today.  I'm continuing to log and blacklist the attacker, which is helping keep the site from having the performance loss we've seen in the past.


Users of BTC Guild:  Please take this time to consider if your username/password combination has been used on any other site.  This brute forcer is NOT using a random guess.  It is absolutely comparing against a HUGE database of leaked username/password credentials from other websites.  99.9% of the attempts don't match a BTC Guild username at all, and luckily BTC Guild's error message doesn't give insight to whether or not a username guess was valid [bad username gives the same error as bad username+password]. 

However, if your password is repeated on a site that leaked their database at some point, your account is at risk.  Just as an example:
The brute forcer made over 4,000 attempts for usernames between 'ketan9binny' and 'KingCid'.  Each one had very specific username/password combinations.  Some common usernames [kevin for example] had multiple attempts with different passwords, indicating they are comparing against multiple leaked databases.

Getwork is still alive, but very unsupported.  Unless a lot of people are complaining, the getwork servers are left on auto pilot and not monitored for performance decreases.



You can not delete an account.  Simply abandon it and it will eventually get pruned into an inactive database.  However, the earnings and payout history related to an account will never be removed in order to have proper accounting records of outgoing payments.

Pretty much the only option for ASIC mining is cgminer or bfgminer.