Fixed the bug where hidden workers would show up under Worker Summary if that had submitted a share in the current round.

Fixed.


I was hoping pool speed would drop to very slow growth over the next week (seems like total network speed is stagnant right now), but that isn't the case.  Adding on two temporary servers this evening to hold us off until the new server is delivered, setup, and mailed out to a colo facility.

Difficulty increase of 50% a few days ago = We should be mining approximately 33% fewer coins per day.  Luck = Average shares per block / Current Difficulty.  We are still currently "lucky" because we are solving blocks faster than average at this difficulty.

Added pool performance charts similar to what is seen on Slush.  The pool speed chart is a real eye opener to how much the pool has grown in the less than 2 months since it opened.

http://www.btcguild.com/pool_charts.php

Individual user charts will be coming tomorrow to show average BTC/speed per day.

Idle Miner warning emails are back up finally.  A huge backlog of emails just went out to a lot of people who probably aren't active anymore, but they're back!

PM me if you receive them in error (ie:  Your worker has submitted shares recently but the email said they haven't in 1000+ minutes).

Just did some renaming and they didn't alphabetize themselves... was your alphabetizing a one time deal or should renames and new workers put themselves in the correct order?
[/quote]

It pulls them on an alphabetical sort on the My Account page.  Adding the sort to My Workers page now.

3 updates so far this morning:
1) Account workers alphabetized.
2) Getwork spammer detection script optimized (very quickly fixed NL1's issues).
3) Failed login timer - If your IP address has been failing logins, it will begin to enforce a timeout window before accepting new login credentials.  This timer grows exponentially after the third failed login.  It is entirely IP based, not account based, so a brute force attempt cannot circumvent the timer by successfully logging into a known account.

If you're seeing blocks showing as None, you weren't mining.  This entire situation did not have a single share submission lost.  Nobody is mining for free.  If you were donating 2.5%+ when the 24 NOT REAL BLOCKS were showing up in the list, and requested a payout, your confirmed rewards on My Account are negative, but you will still see normal block rewards in the list which show that you're paying back the amounts that you should have never received in the first place.

This has since been fixed.  It was an error in toggling the switch identifying that the block calculation script was running, it got hung up in communicating with one of the servers.  Script ran multiple times on the same block, and ended up multiplying the rewards for Block 997 by 25 (if you went to the details it would show 25 sets of rewards per user ID, each being a full block worth of rewards).

The missing blocks were allocated and the bogus rewards from the 24 copies of 997 were removed.

Problem fixed, cause identified.  One of the changes I made in preparation to moving the web server off the pool backfired.  When the new block script got lagged, new copies were running before the first copy toggled the switch to show that a calculation was already being run.

Block 997's duplicated rewards have been removed.  If you have a negative balance because you cashed out during the error (which should only be possible if you were a 2.5% donator), you can either take the money and run, or be honest and just wait for it to go back to positive.

I also fixed 989's "half reward x2" display.

I'm ordering a PowerEdge server this weekend.  The current goal is that this one server will be able to replace all 3 US servers, and add on capacity equivalent to two more servers.  It will be a load balanced server, meaning you point at one URL and it points your connection to one of five internal pushpool servers automatically.  Similar server will be sent to the EU after the first one is in place.

If the pool becomes saturated before its ready, I will close registrations until we're ready.

It's a big sync issue I've been having with spreading these servers out.  There won't be any new servers for a few weeks, so the idle emails will be back soon.

Block calculation script (cron task that loads a page on the webserver to check for new blocks) stopped working last night due to modifying the .htaccess to force the use of https on the website.  The script didn't follow the https redirect, so it wasn't being run.  All the shares/block info are fine, and the backlog of blocks is being caught up.

There will be two sets of these VMs eventually, one for US and one for EU.  It's not as resistant as the current setup (6 servers spread across 6 different ISPs/physical locations), but it will be more user friendly, more efficient, and cost me about 1/5th what I pay right now, while having more capacity and easier expansion.  It will speed up user stat retrieval and block synchronization dramatically as well.  And as said by Carnth, an individual VM could either go down from a crash, or be taken down for an update, and miners would never know.

US West is getting extremely lagged right now due to another set of back to back (3x blocks in 5 minutes) calculations which have a very hard time running with the pool being run on the same MySQL DB.  Will be working on getting the pool split from the web server this afternoon.

I know last night, BTC Guild alone found 8 blocks in a 1 hour period, start to finish (9 if you count the one that finished at the start of the hour).  That was at ~2.3 TH/sec.  I know a few other pools had some similar luck overnight.

I'd wait a while before I start claiming a massive jump in overall network speed, considering that 1 hour alone for BTC Guild was equivalent to what would take 4 hours on average.

Yes, the DE server is with Hetzner.

The main bottlenecks for the pool are actually the TCP stack overhead in dealing with pushpool<->bitcoind traffic, as well as bitcoind which has some performance issues when getworks/second start to get very high.  New server will be running Dual Quad Xeon's, 16 or 32 GB of RAM, split into a 7 server VM system.  5x pool servers, 1 MySQL server, and one front-end load balance server to manage the internal communications.

We had a huge streak last night.  8 blocks within 1 hour.  Completely skewed our luck for the next 24H.  On the bright side, it brought our luck this difficulty back positive, which is the number that "really matters" in my eyes.

Website and US West were lagging badly because we found 5 blocks in about 10 minutes.  Sync'ing shares across the 6 servers, scanning the US West pool server DB for block info, running the calculations, then pushing them into the DB (while all of it is being read from API requests/users freshing block lists/my account) can cause some drastic slowdowns when the blocks are being found in rapid succession.

This is why I'm going to be spending my day tomorrow splitting the US West (pool) from the website server.

To date, only a few accounts at BTC Guild have had funds taken from them.  In all cases it was an MtGox user.  So far every case has fallen into one of three scenarios.

1) Email was shared between BTC Guild and MtGox and the email shared the MtGox password, which was used to reset the BTC Guild password.
2) The password was the same with the number '1' either added to or taken off the password.
3) The password was the exact same between the two sites.


I've had a notice placed on the site within minutes of the leaked database, and the payout lock feature would have prevented every single one of them from happening if users turned it on.  This is why the Payout Lock bugs you to be enabled until you explicitly decide to hide the warnings.