That's not an error.  Automatic payout pays you the amount you specified.  This keeps your wallet free of bloat from lots of minor decimals worth of change being constantly carried forward with little chance of ever being consumed (commonly referred to as "bag of pennies").  Manual payouts on the other hand send your entire balance, since it lets you leave the pool without any change being "held hostage".

Just note that difficulty control will not allow you to opt-out of variable difficulty entirely.  If you pick very high, that's fine, it won't push the difficulty lower than you requested.  If you put difficulty too low, it will still adjust difficulty up if you are submitting far too many shares per minute.  The default vardiff settings have a 95% confidence that your 24 hour variance will be less than +/- 1%.  It's mostly setting a floor on what your difficulty can go down to.

The following is the projected timeline for upcoming changes.  I will give an "official" warning 3 days prior to the merged mining removal, at which point a server will be identified for users to move to if they wish to continue with merged mining.  These are subject to change, but should be close to what happens.


November 23rd:  PPLNS made available for Stratum.  Configuration to be made available on a per-worker basis under Worker Management.
November 23rd:  Warning for removal of merged mining.
November 25th:  Ability to specify a requested difficulty on Stratum.  This will be done through the website, not the worker password field as originally mentioned.
November 26th:  Removal of merged mining from the default pool servers.
Early December:  Extra statistics page that will show you your current Stratum connection information.  This will display all of your currently connected Stratum sessions, as well as the difficulty each session has been adjusted to.

Disconnect issue should be resolved now.

Mine2/3 server is back up and running now.

The server hosting mine2 and mine3 (getwork), and the webserver locked up sometime during the night.  Exact cause isn't known yet, though it's the first time the actual server has locked up after many months.  It should be coming back online shortly.

That server did not run Stratum, mine1 (getwork), or the database server, so the other mining servers were still running fine during the downtime.

More updates for the coming changes now that I'm back to digging into the Stratum server to allow user switchable payout methods (PPS/PPLNS).

With the coming changes, it will be possible to specify a difficulty on BTC Guild's stratum based servers.  Specifying a difficulty will be done using the worker password field using diff_1, diff_2, diff_4, etc.  The difficulty -must- be a power of 2 (1, 2, 4, 8, 16, 32, etc.) due to how variable difficulty is designed in my implementation.  If you do not use a power of 2, it will use the default vardiff settings.

When a user specifies a difficulty, this will be marked as your minimum difficulty, regardless of how slow submissions come in.  It will also follow different rules for increasing.  Instead of a 12-20 shares per minute target, it will only increase your difficulty if you exceed 30 shares per minute during a 5 minute window [sometimes faster in extreme cases].

These changes are not live yet, this is just a preview of some of the changes I'm trying to squeeze in before the reward halving hits.

BTC Guild, Slush, EclipseMC, OzCoin, I believe are the 4 currently supporting Stratum.  Eclipse also supports GBT.  Hopefully I didn't miss one.

It hasn't ended yet.  I'm just removing a lot of the NMC-specific stats from the default interface until the merged mining opt-in is in place.  Your rewards still accumulate, and you can see the stats on My Account, Earnings History, and Payout History.

I've recommended cgminer for almost a year now.  Great all-in-one solution that gives you a lot of control if you need it, but is also click-and-run for non powerusers compared to poclbm.

PPLNS Outline

I'm currently working on an updated Stratum server which includes the ability for PPLNS to function properly.  I have decided that I will now outline how PPLNS will work on BTC Guild.  This is not set in stone, and some variables can be tweaked depending on community feedback.

Shift-Based PPLNS
Since network difficulty is likely to be reaching into the 10s/100s of Millions once ASICs materialize, the concept of pure Pay per Last N Shares is inefficient when dealt with using raw share data.  Being forced to keep 50-300 million shares in a database for when a block is calculated is highly inefficient both in terms of storage and round processing time.

BTC Guild will be using Shift-based PPLNS.  When submitting shares, they will be bundled into shifts, which means the pool only needs to keep track of how many shares you submitted into a single shift.  The current plan is to have each shift last only 1 hour.  When a block is found, the previous 24 hours worth of shifts will be paid out based on the number of shares they submitted vs total shares submitted during those shifts.  The current shift is not paid for the block, to remove any ability to pool hop into a round when many blocks are found in a short period.

As the network changes and BTC Guild's share of the network speed increases/decreases, this may be adjusted to a longer or shorter range of shifts receiving each payment.  The current target payout range is roughly 20x Difficulty, which means on average a shift will receive 20 block payments (but may be much lower or higher depending on 24-hour luck).  PPLNS is hop proof, but is still subject to pool variance as all non-PPS methods are.


Per Worker / Stratum Only
PPLNS will be an option you can set on any individual worker, and can be toggled on the fly through the web interface.  These will only affect workers that utilize the Stratum server.


Transparency/Statistics
When PPLNS is enabled, you will be able to click a details link on the Block History page.  This page will show you the shifts paid by a block, including your contribution/payment for each of those shifts.  You will also be able to view a Shift History page, which will identify your share statistics and payment for every shift.  Your total PPLNS earnings will also be included as a special row on the Earnings History page, so you have a comprehensive listing of all BTC earned with BTC Guild.

Detailed shift information will be presented similar to how the old Proportional Payouts were shown, for those that remember that from last year.


Why PPLNS and not XXPPS/DGM/???
Those that frequented IRC in the past might remember that I stuck with proportional for a long time (and attempted anti-hop measures to stay proportional) for a very simple reason.  Proportional payout methods were easy for users to understand.  It's the same reason I ended up moving to PPS.  Score-based methods and DGM are difficult for a user to audit their own reward payments, because the value of a share changes based on factors/timing that they can't see.

Shift-based PPLNS is very similar to proportional, in that a detailed view of reward calculations can be seen and understood by the user, and checked for accuracy.  It's also easy to correct manually if something happens that shouldn't have (like a shift not being closed when it should have been).

Everybody has their preferred flavor of payment method.  I decided on PPLNS because it's easy to audit/correct, fits well with a mixed PPS/PPLNS pool, and offers a hop-proof payout method for users that don't mind variance with a lower fee.

3 major changes happening this month, just wanting to include it on the forums so people can ask questions (since they can't on the website notice):

1) Reward halving at the end of November.  The site has been updated to account for different rewards per block and will flip over to the new PPS rates within a couple minutes of the change.
2) Merged mining removal.  The primary pools will no longer offer merged mining.  Those wishing to continue merged mining will be able to opt in by using a new server [this will be announced 72 hours before it is disabled on the current pool servers].
3) PPLNS.  I am working on adding in a toggle to workers where you can move them between PPS and PPLNS when using the Stratum servers.  My goal is to release this roughly in-line with merged mining removal/reward halving.

PPLNS will be offered at a reduced fee, and can be switched on/off through the website.  I need to get a lot of work done to make the statistics tracking of PPLNS as transparent as possible, and keep the "instant update" feel that PPS currently offers.  The current plan is PPLNS will be 3% fee, and WILL pay for orphaned blocks (similar to Deepbit's proportional system), removing the need to wait for confirmations before payments are available.

One of the getwork pools died, it is being restarted.  People keep putting massive load on getwork pool servers, and I'm not going to make more of them when a much better alternative exists.

UPDATE: The dead server is back online.

After the 44 minutes, did all of the previously accepted shares show up at once?

Was it just the speed that wasn't updating?  The reports sound like regular stats were still showing up (share accepts/rejects).  Were they new workers, renamed worker, or old workers?

What servers are you using to connect?  I'm not able to recreate the problem.

All of the displays on the website and API are now updated to support changes to the block rewards (~Nov 29th before this occurs).  If you're noticing any odd numbers, please report them to me in an email with your  username so I can view it myself to find the problem if there is one.

I'm starting to deploy some site-wide changes to the pool to prepare for the reduced block rewards.  You may see brief periods of your rewards looking funny, but these should generally only last 30-60 seconds as I tweak the pages to get the calculations to display properly.

This is only true if you're using the Stratum proxy on slush's pool.  For other pools you will need to run the proxy with the arguments '-o <hostname> -p <port>', ie:  -o btcguild.com -p 8332

Old workers will still be available and still work because the server caches them.  Similarly, BAD worker logins are cached.  You obviously renamed your worker but tried to connect before renaming it, causing it to get added to the bad worker list.  The server caches bad logins to prevent somebody from flooding the server with bad logins and forcing constant MySQL lookups to bog the server down.  Old mining software used to reconnect with no delay when a connection failed, which resulted in flooding the pool server -and- database server due to the worker lookups.

If you were using the DE Stratum server (which can be connected to by ANY stratum supporting client by just pointing them at de.btcguild.com), this problem would only persist for about a minute before the bad worker cache was cleared.  I don't recall how often the getwork pool clears its worker cache.  At this point the getwork pool is barely supported, and simply left online while people upgrade to stratum mining clients.

Either way, this only occurs because you were trying to connect to the pool using invalid credentials initially, THEN renamed the worker later, leaving the old name in the bad worker cache.