There is no crashing.  There's all zeroes in the last 3 shifts (currently) because we haven't found any blocks since those 3 shifts closed.

I'm working on a more long term luck history graph which will hopefully ease the tension a little.  The luck has been trending negative for a while now, but in the big picture it is still quite close to neutral.  Only issue I'm running into right now is due to the way PPLNS handles share recording, it doesn't directly link to a difficulty like it did with PPS.  It's making it a little more difficult to create an accurate chart.

After a lot of log browsing, I have found a possible cause for the below average block solves in the last ~36 hours.  One Stratum server was moved to 0.8.2 as an attempt to combat the huge bitcoind latencies that have been plagueing pools lately due to a large amount of spam/dust transactions being generated.  For some reason, this server has occasionally been crashing when submitting a block to bitcoind.  It was not easy to identify when the crash hit due to the fact that the server was still submitting blocks (and solving them).  I've downgraded the server back to 0.8.1 now that we have a patch from sipa that dramatically speeds up the bitcoind process of creating a new block of transactions.

This was not the sole reason for the last ~36 hours, but it is likely a contributing factor.

There was an error in one of the warning messages last night, telling users that they had been automatically banned from Stratum for being suspected of running a botnet.  I was doing account clean-up, removing previously banned accounts.  As a result, I cleared out the array that held a list of accounts that should be receiving the warning whenever they log in, and it was activating on all users temporarily.

If you received a message about being banned from Stratum in the last 24-hours, do not worry.  Your account was not banned [your miners would be unable to connect if that was the case].


This message mostly appeared on pages where a warning message should appear, such as changing your wallet/email where it would notify you that an email has been sent to confirm the change.

Where are you finding 1.014 TX fees?  That looks like a normal wallet sending coins.  When you send coins, the remainder goes to a change address.  What you were doing was basically just following the change addresses.  The fees on each TX were 0.0005, which is the standard TX fee for coins without high priority (low confirmation count).




Thank you for posting a link to that patch slush.  I had been seeing a lot of similar issues lately (though I wasn't getting the orphan rates, since my pool servers stop accepting/submitting shares when they already see a new block, even if no work has been provided yet).  Was using some workarounds the p2pool guys have used, but it still required a lot of monitoring and bitcoind restarts.

A small patch has been applied to BTC Guild's bitcoin servers to reduce the latency when a new block is found on the network.  This should bring stale share rates down considerably, especially on Stratum servers where bitcoind latency is the primary cause of stale shares.

50BTC doesn't include appropriate fees on payouts to their miners.  As a result, they generally are only included in blocks mined by 50BTC because other nodes won't even relay them.  This is why it doesn't show up on blockchain.info - normal nodes will simply not relay the payout because it is considered spam due to lack of fees for the size/inputs.  As far as I'm aware, 50BTC's nodes do put payouts to miners as a priority so once 50BTC does find a block it should be confirmed.

EU Stratum servers had a brief restart to get a performance fix in place.  The EU servers don't have quite the CPU power of the US servers, so hopefully this fix will reduce the stale rates and speed up reconnects.

PPLNS stats show exactly that.  We had two really good days earlier this week, and now we've had about 30 hours of garbage (with a few shifts not so bad).

2 of the 3 US Stratum servers had a brief outage due to datacenter connectivity.  Everything appears to be working normally again.  If you're still having problems, please let me know.

Just curious to see what the status of orders are:

1) The people claiming they've received Batch 2 Avalons - When did you place your orders?

2) Are there still a lot of people with order status: Processing?  My order has been on that since February 18th when I ordered it, curious how far back the orders go with that same status.

That already has the fee taken.  The PPS Rate displayed on the site is the amount you will get paid for every valid share if you decide to mine on PPS.

Most pools (from my observations, note this may be very outdated now that pools have vardiff) display miner hash rates as either a 15 minute or 1 hour average.  Some use slightly different windows.  BTC Guild for example uses a variable window based on available data, starting with just 2 minutes worth of shares, and extending up to a full hour [and then the graphs page can give you 4-hour average hash rates].

However, hourly variance *shouldn't* mean much to a miner.  Most pools have vardiff configured in a way the leads to a ~1% +/- variance on the miner's share submissions over the course of a day assuming you're mining at a point where vardiff is needed.  In comparison, most GPU miners are seeing only ~6 shares per minute from a 420 MH/s GPU, which is a ~2% +/- miner variance in 24 hours.

Obviously you're still at the mercy of pool variance for non-PPS mining as well.

If you're looking at 24 hour earnings, your earnings will show *much* lower initially due to how PPLNS works.  For the first 10 shifts, your earnings are not "finalized" yet.  This means that you basically have 6 hours where your earnings are significantly lower.  This is offset by the fact that when you turn off your miners, you will still be getting paid for almost 6 hours of work as your last shifts continue to receive payments.

As a result of this time-delay function (which is the reason PPLNS is not hoppable), the 24-hour earnings statistic only includes earnings from roughly 30 hours ago to 6 hours ago (the most recent 24 hours worth of completed shifts).  However, you are correct that luck did move back to negative about 7 hours ago.  That's just how it works.  Yesterday we had almost 20 hours straight of 10-60% above PPS earnings.

Stratum should be immune to this unless the pool is attempting to let two workers run at different difficulties over a single connection.  By default, Stratum defines difficulty per-connection, along with a unique extranonce per connection.  This would make it impossible to shift shares between different difficulty workers unless the pool is doing something very stupid.

Getwork is the only method I believe *could* have this flaw by default, however I think there are only a handful of pools which offer multiple difficulties over getwork.  Similar to the Stratum situation, all the pool would have to do is add a number to the coinbase to represent the difficulty the work is supposed to meet.

Autopayouts under 0.1 are now enabled again, sorry for the inconvenience.



mergedmining.btcguild.com:8332 is the only server which provides NMC [as seen on the Pool Stats page].  The balance accumulates as PPS with a 5% fee.

Just an aside:  Blockchain.info is almost always accurate on BTC Guild's blocks since we always use the same payout address and have a coinbase message.  I'm not sure which they're looking for (or both), but as a result I can't think of a block reported as BTC Guild that came from another source.  Their 24 hour chart is not "inaccurate", BTC Guild really has been floating in the 47-49% of blocks for the last 24 hours most of the day due to extremely good luck (look at our PPLNS stats, the last 15 closed shifts have ended up paying 10-60% above PPS).

The reason blockorigin.pfoe.be is always linked and people told not to rely on blockchain.info is that a 24 hour chart is so heavily influenced by luck that it means very little.  If pool A has good luck, they will show up big.  If pool A has good luck while B and C have bad luck, pool A looks HUGE.  If blockchain.info would fix their 48-hour/4-day charts (they only marginally increase the span, nowhere near 2 days/4 days), and perhaps defaulted to the 4-day chart, it wouldn't be quite so annoying.

BTC Guild has only barely gone above 40% during any 2016 block period, never hitting 41% as best I can tell [it may have, but if so it was very brief even on a 2-week average].  We've slowly been moving downward after the recent changes to PPS fees and forcing getwork users to PPLNS, which was the reason those changes were made in the first place.

Or for those who prefer pictures: http://blockorigin.pfoe.be/chart.php 

Actually, ASICMINER has about 5 TH/s missing from BTC Guild as of this morning.  Not sure if they're having problems, or perhaps are selling older blades where newer ones are expected to run faster/more efficient.  What you see on blockchain.info is basically nothing more than "which pools got lucky".  BTC Guild has shrunk about 15% in the last 12 hours, yet due to good luck (~40% above expectations) it makes it look like we've grown dramatically instead.

http://blockorigin.pfoe.be is a much better site for pool size checking.  The 24 hours on Blockchain.info's graph is impacted *significantly* by pool luck.

Just posting this for reference:  I am not attending the Bitcoin 2013 conference (although I really wish I could have made it) due to paranoia that a perfect time to DDoS/brute force/use social engineering on Bitcoin services would be when lots of the people that run them are all away from their offices.  So just in case:  If anybody is there claiming to be me, they're not.