It varies from miner to miner, but they should be able to recover.  The downtime is expected to be extremely short (ie: About 1 second), it's simply killing one pushpool instance which will -instantly- start up the new version.

I'll be making that a part of block statistics shortly.  For the record, our luck has been the following:

Past 24 hours:  546k average per block = 25.5% bad luck
Past 48 hours:  587k average per block = 35.1% bad luck
Past 72 hours:  567k average per block = 30.4% bad luck
Past 96 hours:  527k average per block = 21.2% bad luck
Since current difficulty of 434882:  481k average per block = 10.6% bad luck

So if your time frame was the last 4 days, the payouts were 21.2% worse than the expected average for your machines.  If it was the past 2 days, it was 35.1% worse.  For comparison, our average shares at the last difficulty (244112) was 212437, which is 13% ahead of expectations.  Meaning the average between this difficulty and last difficulty, the pool is still ahead by about 2.4% (this is overly simplified and wrong to just compare two luck percentages for rounds which vary in length, but the point behind it is still valid).

Your comparison is occuring during a period of bad luck.  We've been going at 20-30% above average for this difficulty in the past 48 hours, and close to average prior to that.  This is standard variance and can hit any pool including DeepBit (and has in the past).  If you had tried about 2 weeks ago at BTC Guild we were averaging about 30% -under- the average for the difficulty.

Larger pools do not eliminate variance, it only helps smooth the effects of variance.  The only relevant factors when comparing pools are:  Fee %, Stale %, Downtime %.  Those are the only 3 items that can be measured which have an effect on your payouts, everything else is chance.

The Since Reset column has been buggy since I made the change to remove old shares from the log (to speed up stat calculations and not require infinite hard drive space).

I'm going to be having a short (< 1 minute) restart on the server this weekend to update pushpool.  The update will reduce overall load on the MySQL database, and it will include a fix to the reset column so it won't be resetting the counts.

When a block is finished, it is not known that it is invalid yet.  So the block is calculated and all the users are rewarded proportionally as normal.  When the block becomes invalid, it nulls the rewards that we're allocated to anybody that did not donate 2.5%.  So the people that donated 2.5% receive the same reward they would have if that block was valid.

I had not considered it, so I'll look into it down the road.  For additional questions/comments/suggestions in the main BTC Guild thread, to keep the bitcoin.org forum less cluttered .

When were you having the problem?  The server moved to a dedicated server 4 days ago, which has virtually eliminated the issues the old box was having.


This weekend I'll be adding a 24-hour statistic to the pool for keeping track of that, and an added perk for 2% donators where you'll receive an income statement-like report in your email each day (or week) detailing your earnings, withdrawals, and worker stats for the previous 24 hours worth of blocks.

Curious where you're getting UNTAXED from.  Surely you mean BEFORE taxes.  Unless Tycho is in a country with no income tax, he's going to owe on that money.  Once you convert BTC to cash, you have real, recognized income.  I know it defeats the whole anti-government branch of the bitcoin userbase, but tax evasion can carry serious consequences.

Also, his 3% fee is partially used up paying users when there is an invalid block (so he keeps about 2% of the fee assuming ~1% invalid rate).

This is normally an error from people who are mining from countries with poor connections to a US based server.  The lag between you and the server means sometimes if you finish two work units in quick succession, you have not yet received new work from the server (miners keep 1 unit in queue behind the one they're currently working on).

Try running phoenix with -q 3 or -q 4, which will increase the amount of work the client tries to keep stored locally.  This has solved the issue for some of the people connecting from countries in Africa, or from China, or people that connect by wifi, 3g/4g, or satellite internet.

A 2m round, while uncommon, is not a sign of anything being broken.  I can recall a few pools which had even longer rounds back when the difficulty was half of what it is now.  It's just an unlucky round for the pool.

It will only be moving forward.  "Retroactive" reports would just be spitting out your current rewards summary.  The report will be roughly as follows:

=== BTC Balance Summary ===
BTC Earned in Last 24 hours:  0.93859010
Previous BTC Balance:  1.03910000
Sub-total:  1.97769010
Manual Payout (Timestamp):  (0.00948001)
Automatic Payout (Timestamp):  (1.03910390)
Balance Remaining:  0.92910619


=== Worker Summary ===
Worker #1:
  Shares submitted in previous 24 hours of blocks: 1,000,000 (103 invalid)
  Average Speed over 24 hours:  xxx.xx mHash/sec

Worker #2:
  <Repeat>

Total:
  <Summary>

Auto payout will be implemented on Friday.  After that I will be making the "Last 24 hours" summary of BTC earned (available to all members).  Following that update, there will be a second perk added at the 2% level, which is an email that can be received daily or weekly, which provides you with an earnings summary report in your email.

I've been considering swapping BTC Guild to a higher difficulty of shares to reduce the work being sent to/from miners, as well as lowering the amount of requests going between pushpool, bitcoind, and MySQL.  My only concern at this point is for CPU miners, who are already submitting shares so rarely that a difficulty of 2 could mean they don't even complete a share before some rounds end.

An update based on some people reporting issues in IRC:

If you have PeerBlock installed, set an exception to btcguild.com's IP address: 69.42.217.226 .  Apparently we're on the "Business ISP" list, and the "level1" list and the response from the people that setup the "Business ISP" list is that they won't exempt anybody on that list.  Yay for paranoid morons who try to mask illegal activities by blocking entire IP ranges because someone somewhere in that range may have been connected to an anti-piracy or government group.

A bit smaller than BTC Guild actually .

The point is still valid though, some pools have been attacked/had downtime lately, which removes them from the pie chart temporarily.  Reloading bitcoinwatch's pie chart right now shows Other roughly the size of BTC Guild / BTCMine.

Your miner is the accurate measurement.  All pools (BTC Guild included) measure your hash rate based on the shares your miner has submitted over a certain length of time, 15 minutes on the case of BTC Guild.  Pools cannot see the actual hash rate of your miner, only estimate it.

No idles on my miners (checked all 12), and the IRC channel only had one person reporting idles, but that was due a bad ping as a result of their geographic location (South Africa).

Email notifications were added a couple hours before your post .


The pool has had bad luck on block solve speed the last two days.  This type of variance evens out over a long period of time thanks to the very quick solves a pool occasionally gets.  As the pool grows, these variances should even out in a shorter time frame.

And due to popular demand (and finally having time to get work done):  https://www.btcguild.com  (AKA:  SSL protected website) is now available.

Miner idle notifications have now been added.  This feature is available to anybody who donated 2% in the previous round.  The feature will cease notifications if your donation percentage is dropped under 2% in the previous round.

You can enable this feature on the My Account page (it requires an email address).  Every minute, the server will check to see if any of your workers haven't submitted shares within your threshold value (default 30 minutes, minimum 5 minutes).  If a worker has not submitted work in that window, you will receive an email of all workers currently identified as idle.  It will not send another email unless the worker comes back online, and then returns to being idle.