Would you prefer I turn back time and hide the fact that its a 1 hour delay?  If you were mining here continuously you would never know the delay existed in the first place.

The point of 2.5% is invalid insurance.  Quite frankly I'd prefer if people donated 2% rather than 2.5%, because I make more profit out of those donators.

I will be adding back an estimated reward field, which will be measured by calculating your speed in comparison to overall pool speed.  Assuming 100% participation in the round, this will give you an accurate representation of your estimated rewards.

You can still get payouts before 120 confirmations, and on invalid blocks.  The only delay is that you won't know you have any rewards (and therefor be unable to request them) until 1 hour after a block solves.

In my post a few pages back, I put up my math showing how pool hoppers don't impact the BTC/minute for a round in any of 3 scenarios:  Pool hoppers there the whole round, part of a round, or not at all.  My math was wrong because it was looking at a single round worth of information.  If you look back at the post, and COMBINE the two rounds you will get the following:

In scenario 1 (with hoppers) "rest of the pool" will get
45 + 48.34 = 93.34 BTC
in 5 + 32.22 = 37.22 min,
resulting in 2.51 BTC/min

In scenario 2 (without hoppers) "rest of the pool" will get
50 + 50 = 100 BTC
in 5.55 + 33.33 = 38.88 min,
resulting in 2.57 BTC/min


These were using fairly simplified numbers, and assuming hoppers were only 100 GH/s rather than 200+ which I now know they were.  In those scenarios (a 500k and a 3m round), the net effect was 0.06 BTC/minute drop if hoppers were part of the pool during the start of rounds, or 2.3%.  Now my math used was very simple, but the theory holds true for actual pool hopping.

Would love to see them try.  The website completely masks the last hour of round activities.  It's not updated hourly, its a rolling window.

Last Share timer is now counting up for workers that were not active in the round.  Miner Idle emails will be back up soon.

2.5% donators/invalids are still here.  I'm not going to put time into thinking about how it'd work in SMPPS since I don't have any realistic plans on switching .

I'm still tempted to switch to SMPPS, for the sole purpose of seeing what fake/misguided outrage fills this thread .

Worker stats reset share/stales functionality has been restored.  Next up:  Last share time for previous rounds.

If 580 BTC over the course of two months and a week is nice coin, then yes.  As of right now my earnings after expenses are significantly less than minimum wage, but the consolidation of servers into significantly more powerful loadbalanced multi-servers will hopefully at least make it worth my time.

For those bad with math:  679 in donations + 187 in transaction fees - 283 paid on invalids.  Doesn't include the fact that I've been paying transaction fees for member payouts since the DDoS to help payouts go faster while we recover from the downtime.

Lets see, two days ago:

"I'd join BTC Guild but pool hopping will hurt my return"
"I left BTC Guild because pool hoppers are walking off with rewards that I should have earned."
-Debate ensues, eventually someone sends me a complete breakdown of exactly what pool hopping can do for their return and shows how it HURTS LEGIT MEMBERS-

Now: 1 hour delay added
"Pool hopping is just a myth!"
"OMG WTF YOU'RE HIDING OUR STATS FOR AN HOUR I'M LEAVING"


Damned if you do, damned if you don't.

For those leaving, think about this one simple fact:  Legit users returns ARE reduced by pool hoppers.  MY RETURNS are increased because of the speed fluctuations pool hoppers bring at the start of each round.  I just reduced my income to help legit users.

When I first implemented the stat delay, I immediatley changed the pool stats API to show the current round at 1 second with 100 shares.  Within 15 minutes the pool speed increased over 200 GH/sec.  We are still higher now than before I put in that delay.

Reset stats are almost fully restored (just adding the reset buttons now).  That will let you monitor miner performance when testing new configurations.  Last share times are also about to be restored, which will be almost immediately followed by miner idle settings being visible again.

Unconfirmed/Confirmed rewards do not increase until 1 hour after the block was found.  For 2.5% donators, the 1 hour delay means your rewards don't go up until after that hour has passed.  Otherwise its trivial to track when a new round starts.

The unconfirmed rewards will reach confirmed status in the exact same amount of time.  The delay is on publishing a new block's stats, not updating confirmations on blocks that have already been published.

What clarification?  Stats are delayed by 1 hour, exactly the same as Deepbit.  The alternative is you have pool hoppers that DO impact your rewards per day.

Pool stats are now running on a 1 hour delay.  Current round stats/estimated reward have been removed to remove any way to scrape data from the website to determine when we have started a new round.

Anybody using the API should remove the following pieces from their code:
  estimate_reward, round_shares, round_stales, round_time

They will be taken out of the API in about a week.  Until then they have been filled in with dummy data to avoid breaking gadgets/parsers, as well as give me some good stats on how much speed is involved in pool hopping.

If you're using TOR, expect shitty rejected share rates.  Just an FYI.  The IP changing of TOR will mark your account as a potential botnet and give you last priority on LP updates/getwork processing.

Individual block variance is always pretty large.  The point of having a high speed pool isn't that your variance per block is low, its that your variance over a period of time is low.  Looking at our luck over an entire difficulty shows our variance has been fairly low (the last two difficulties were less than 1% from average).  Even this difficulty we're within 10% of the expected average, and we were offline/slowed for a very large chunk of the difficulty.

We are NOT on difficulty 2 shares.  That was planned a while ago, but it was due to some poor scaling on the database backend.  Difficulty 2 shares would've cut the DB load in half, but I was able to revise the DB schema and completely eliminate the need for it.


If you're receiving stales over 2%, odds are your miner is screwed up.  It is nearly impossible to have that rate of stales.  Nearly every user is reporting rates of 0.5% or less.

The most common reason people are seeing invalids is that their miner is sending shares to multiple servers at once.  PM me with your IP Xephen, there's one possible reason for the huge increase, but I will not announce it in the thread as its only affecting a very small subset of users and its for a very specific reason.

In the end, a stat delay is what we're going with.  Proportional is the most FAIR distribution - Every valid share is worth the same as every other in the round.



One of the things I did when trying to find out why the load balancer was crashing at long polls was remove the 'hub mode' feature from our bitcoind in case it was trying to spam too many p2p connections with other nodes.  I re-deployed JoelKatz's bitcoind "hub-mode patch" this evening after our invalid.  The two invalids in the last 24 hours were real invalids (the previous 4 from earlier last week were bugged bitcoind/load balancer crashing related).  The new invalids were simply other pools producing a block very close to our own, and the block chain favoring the other block.  Hub mode essentially makes bitcoind aggressively connect to other nodes to maintain a certain number of peers.

With hub mode re-enabled, we should now spread our blocks out among the other nodes on the bitcoin network significantly faster, and we will get the new blocks faster as well to reduce the odds of an invalid being produced.  After a few hours, it has been running strong and not causing any unusual long poll performance issues.

Yes, I had a few minutes to spare and decided to get the Blocks Found to sync up with the master server when a round ends, and decided to take a couple minutes to color code block lists/block details:

If you found a block, it shows up with a blue background color in the block list/all blocks table.
When looking at block details, the block finder is highlighted in blue, you are highlighted in yellow.
If you found the block, your row will be highlighted in green.