If your miners are still having problems, please let me know ASAP!  Everything looks perfect from the server side right now (with the exception of payouts temporarily paused).

Payout scripts are paused for a little bit longer (that's where the holdup is stemming from).  They'll be manually run a few times to catch up once I've caught the part that's lagging the system down.

Problem found, and now fixed.  The public servers *should* have remained online.  The private server did require a restart unfortunately.

Website temporarily unavailable in order to debug a script that's eating up a LOT of CPU suddenly.  Should be back up very soon.  The mining servers are still running during this maintenance period.

PPLNS is and has always been 3% with paid orphan blocks, paid transaction fees, and for the last few months, Namecoins.

PPS was 5% from October 2011 until May 2013, then increased to 7.5% with significant warnings for close to a month before it was increased.

Website is back up and running normally.  The pools should not have been affected by it (the apache process was what was lagged).

Just a coincidence that the luck went to hell.  If you look at the block history, you'll a cluster of bad blocks (277522 - 277570).  Multiple 2-hour blocks will generally nuke luck pretty bad.  It's not that any individual block was terrible luck, just that a group of blocks taking ~2.5x longer than normal happened in a row.

BTC Guild has a small project in the works that will end up being beta tested as a multipool project, but it won't be ready for a few more weeks.

Good luck over the last few months would do it ;p.  Average luck has ended up making the pool pay better than 0% PPS for 3 months and counting, not counting NMC.

PPS is the steadiest income, but always comes at the highest fee (since the pool operator is paying for bad luck).  It also requires the largest amount of coins to be held by the pool and in the hot wallet in order to meet obligations, leading to highest (only) chances of bankruptcy and more vulnerable to attack.

PPLNS and DGM both vary from pool to pool depending on the variables they choose.  PPLNS with a "really big N" value offer extremely low per-share variance in comparison to non-PPS methods, but BTC Guild is the only pool using a "massive" N value as far as I know (BTC Guild's N value is currently 17.5 billion).  You will still have daily swings based on pool luck, but higher N values reduce the chances of a share being severely underpaid over not paid at all.

DGM's method of offsetting variance is to change block rewards based on round length, so some rounds (fast ones) pay less than 25 BTC, others (long ones) pay more than 25 BTC.  There are other factors involved.

My personal preference (obviously biased as the owner of BTC Guild) is PPLNS for non-PPS.  At least with BTC Guild's implementation of PPLNS, the exact BTC paid to any share is auditable by the user if they want to take the time.  There are no background calculations based on the timing/frequency of share submissions or block solves like DGM/Score which make the *exact* payout difficult/impossible to audit as an end-user.

You can switch workers between PPS and PPLNS at any time, nothing is lost.

1) Because I prefer users on PPLNS.  It gives them better rewards in many ways, and means I'm not gambling on pool luck, which means the hot wallet can stay much lower than it used to be under pure PPS.
2) Because NMC was added back in a way that requires no extra DB queries or and virtually 0 database load.  A single column was added to the PPLNS table and it was ready, whereas doing NMC under PPS requires a completely separate table and an extra query every time shares are submitted to insert that data into the NMC-PPS table.

NMC is only awarded to workers on the PPLNS system.  PPS does not generate NMC.


Edit:  Well crap, looks like Namecoind is acting up again.  Will update once I can figure out why no new blocks are getting added.
Edit2:  False alarm, I was just looking at the most recently closed shift which had no blocks solved.  NMC has been getting awarded.

Because it probably wasn't a pre-meditated plan to go rogue.  Best odds are their hands got caught in the cookie jar and when enough people tried to withdraw due to the massive rally and they couldn't pay out what they did owe, they faked the billing system hack in order to shrug off their debts.

Luck is based on closed shifts (again, luck is only known once the shift was closed).  Each point of data on the luck graph represents the luck for a shift.  The graph checks for any recently closed shifts every 15 minutes to post to the luck graph, so it can be a little out of date depending on when the last shift closed vs the last time the graph checked to be updated.

A warning to Chinese users who read the forum:

I know many users in China are using proxies to access BTC Guild.  If you have to use a proxy to access BTC Guild - run your own wallet and LOCK YOUR WALLET or your account details might as well be posted in the clear for all to see.

As stated above, the 24 hour earnings at the top is calculated in two ways (depending on payment method):

For PPLNS, it uses the last 24 hours of CLOSED shifts only, since open shifts aren't done getting paid.  Think of it as taking your last 32 hours worth of earnings roughly, and then chopping off the open shifts.  You get a full 24-hour worth of rewards included in the statistic, it's just related to the mining you did slightly earlier.

For PPS, it uses your share submissions over the last 24 hours multiplied by the current PPS rate.  So normally it's dead accurate.  The only time it's off is when the difficulty changes, since it uses the *current* PPS rate.


And you're correct, recent block rewards aren't updating until a subsequent block is found.  This is temporary, and it's due to that bug when the NMC chain was hardforked and random servers stopped updating to the most recent blockchain.  It hasn't repeated itself yet, but I'm wanting to wait another week or two before I turn off the workaround, just to be safe.

Over an infinite period of time, you would expect luck to be infinitely close to neutral regardless of mining speed/pool size.  Since that's not reasonable, you end up with the basic variance.  The smaller the pool, the more wildly it can move for a given time frame.

Think of it like a wave on a graph, steadily moving up and down, centered on the axis (the axis being neutral luck).  For a smaller pool, its stretched out so it spends a lot of time above or below the line, but it steadily moves between the two.  So if you take a given slice (2 weeks), you may end up quite a bit above or below the average line depending on where in the wave that 2 week period landed in.

For a larger pool, that wave is squished, so it fluctuates up/down very rapidly.  But since it's moving between the two so frequently, taking a 2 week slice of that graph will likely average closer to 0 since it never spends too much time away from the axis.

No cost.  This is just another step towards greater stability/performance/redundancy.  There's a lot planned for the rewrite, luckily the bulk of the work (share validation/work generation) is "done".  No need to reinvent that wheel, just slightly rework it to make better use of threading and user prioritization.

He's right, in that *expected* luck should always be neutral, regardless of difficulty.  Expected luck and actual luck are obviously not always going to line up, so you end up with my explanation.

There was a lot of passive aggressive language in the first version, which was not justified.  A side-effect of getting out of the car after a 9 hour drive and looking at the forum & emails less than 10 minutes after pulling in the driveway.  I got two emails over the holidays from people who really deserved to be publicly ridiculed for how absurd their demands/requests were, and some of that frustration leaked into the post.  My post was more intended to be informational rather than a direct response.