A large DDoS has just started hitting all the BTC Guild servers.  Will update as more is known.

If you have more than 2 confirmations (the block itself + one more), the only way it's going stale is if there is a hardfork or 51% attack.

To be fair, I'm pretty sure there's only one PPS pool (50BTC).  All the others are different payment methods, with an optional PPS method at a higher fee.

Something that hasn't been requested (that I can remember), but certainly something that should've been available:  You can now restore the share counters for workers that have been reset.  This can be good for short period testing, allowing you to reset your stats at any time to check for acceptance rates, then restore your overall statistics once you're done.  This is also helpful if you're looking to audit your paid shares, since previously the only way to get the full stats (without being affected by resets) would be through the API.

By default, the stratum proxy listens for your miners on port 8332.  You can change this using '-gp <port>'.

Run it with '-o <server> -p <port>'.  On Windows, this means either launching the proxy via command line with those arguments, or creating a shortcut and adding those arguments to the target.

No gold in stock.  Currently shipping the textured red ones (they have a really cool shine effect due to the circular texture), and then blue once those run out.

You just had to go clicking buttons, didn't you!  Now look what you've done.  Time to sell more Block Erupters (now 0.15 BTC shipping included) to make up for this.

Part of unknown is definitely the 100TH project which left BTC Guild to start solo mining in the last week.  They're not on your list.  They told me they were going to be tagging coinbases, but apparently something broke because I can't find any.

Another item that got kicked to the side for a while has finally been checked off the To-Do list.  PPLNS Earnings History now has a CSV export available on the settings page.  This means you now have a CSV export available for all earnings and payout data.

A few more minor changes happening to the UI related to how really large numbers can screw up the formatting on the dashboard.

If you have more than 10,000,000 accepted shares on a worker, it will now be divided by 1,000 and a 'k' appended.  If you have more than 100,000 of a certain reject type, the same thing will happen.  In order to make these numbers easier to parse, they now have commas added once these amounts are reached (example: 5,903k accepted).

Not exactly, but the "time spent with bad luck" will increase.  If a pool does not keep up with the network growth, they will (on average) have longer rounds.  Similarly, if a pool would have a round that takes 7 times difficulty to complete, it will last even longer as their share of the network decreases between each difficulty.  But the flip side is, the smaller your pool is compared to the network, the higher your potential luck can be in a given time frame, which is what offsets that bad luck.  It's all a matter of variance.

Similar to what I mentioned earlier talking with organofcorti:  Bad luck is defined as a long period without blocks.  That means at any given time, you're probably more likely to be experiencing bad luck rather than good luck.  Good luck comes in very short bursts since they're defined as many blocks in a less than normal amount of time.  Those bursts make up for that extended period of bad luck.

The other issue is network growth is outpacing most pools, so they're losing overall network share.  BTC Guild actually lost a bit of network share recently now that MegaBigPower went solo.  The smaller your share of the network, the worse bad luck feels since the time it takes to solve a block that takes 5-9x difficulty worth of shares is much longer when you're only 5-6% of the network.

Whoops.  All numbers are in GH/s :p

Done.  This was something I started on a while ago and never finished.  All numbers on the site are now in GH/s.  On the worker table, a worker under 1 GH/s will be measured in GH/s with 3 decimals (so you'll get MH/s rounded to the nearest MH).

100% line means payouts/block solves were exactly what you'd expect given the number of shares.  You'll never see exactly 100% for a single data point since currently each block is paid out to ~2.5 billion shares, which is not an exact multiple of difficulty.  However, the average should always trend towards 100% by the end of a difficulty period.  Only early in a difficulty will you see big swings.

Example:  Current difficulty is 148,819,200.  To be exactly at expectation, a shift would need 2,500,000,000 / 148,819,200 = 16.79 blocks.  Since you can't find a fractional block, a "neutral" shift would either be 16 blocks (slightly under expectation) or 17 blocks (slightly above). 

The last freshly minted Bitcoin won't be anywhere near 2040.  I believe ~2040 is when the subsidy drops below a full coin per block.  "2140" is the date where the subsidy actually becomes 0 because it would be a fraction of a satoshi.  The difficulty adjustment keeps the halving events *roughly* 4 years apart.  Obviously early on in the life of Bitcoin these events will happen more frequently because difficulty adjustments are a backwards-looking adjustment rather than forward-looking adjustment.  Exponential growth is not sustainable, and the previous posters were correct.  GPU -> ASIC is basically the same as CPU -> GPU was.  Actually, what we're seeing today isn't even close to the jumps we saw from CPU->GPU in terms of percentage growth when GPU mining first started.

The first time GPU mining was introduced is the first and only time in Bitcoin's history where the limit on a difficulty increase (+300% in a single adjustment) was ever hit.

It's something most other pools have had for the better part of the year .  Yes, it does dramatically reduce traffic, since most users don't bother to change their own difficulty.  Probably less than 10% of overall users, and less than 50% of the top 100 users on any given pool (the ones who benefit the most) actually adjust their difficulty pool side, so vardiff massively reduces overall traffic to the pool.

X-axis is actually not scaled to blocks solved.  Y-axis is the luck (% of payout vs expectation), X-axis is shift ID (roughly time since shifts are normally the same length).

Okay, after playing with it, I went with a log scale on the graph .