We've never hit 51% of *actual* network hash rate, but with good luck streaks we had 24-hour periods where we found more than 51% of the blocks.  It's not exactly the same.

The peak was around 43-45% of network hash rate, which is when the pool increased the PPS rate to encourage users of PPS to look for another pool, and it did help.  The biggest help was obviously ASICMINER going solo.  At the time they were ~35% of the pool's speed, so by leaving the dropped the pool down to ~25-30% of network hash rate.

Always wait a few days before looking at new difficulty projections, they're VERY inaccurate at first.  Right now BTC Guild was running at 150%+ luck for the last 18 hours.  That effectively puts the network speed projections at +175 TH/s just from BTC Guild.  If any other large pools had a similar lucky streak, the estimate is completely thrown off until that luck evens out.

Not at all, the luck stats are purely cosmetic.  Luck is always disabled at the start of a new difficulty (sometimes a little before if it will go up while I'm asleep), since it can't be accurately* measured until a shift that started at the new difficulty has fully matured [closed].  It will resume being displayed when Shift #10116 is closed.


* It can be accurately measured, but I don't actually log the luck per shift.  It's simply calculated live when the page is viewed using current BTC difficulty, and a hand-edited Shift # to use as the first shift at that difficulty.  It would take a lot more work and some extra behind the scenes database logging to actually provide historical luck and not get confused by new difficulties.

We're 31% of the network.  Not even remotely close to 51% especially with ASICMINER + GHash.io being part of the network that will never join a pool.



And those precautions will be extended/altered if it ever happens again, since one of those has already happened due to the last time the pool got too big.

Don't forget the units shipping currently are either Silver or Blue.  Both elusive colors not previously offered by BTC Guild .  Gotta catch 'em all!

Just wait til I start offering combo packs of 9 Erupters, 1 Fan, and an Anker Hub (jk)

This attacker (based off the timing and types of attacks) has been poking at BTC Guild a few times (3 times this week), so I doubt it's related to difficulty changes.  But as you pointed out, it wouldn't matter since the adjustment is based off the entire 2016 block time frame.

All previous USB Block Erupter buyers have been given 50 coupons each.  These will be replenished over time as more inventory arrives.

Slush has been MIA for quite a while as far as I can tell.  It also ends up being a lot easier for pools to just implement a workaround rather than expect ever user to upgrade/patch their proxy.  I'm not sure what you use (based on slush's python, eloipool, or custom), but for mine (custom) it was just a matter of:

1) Adding a check to worker auth to see if the connection has already subscribed.  If it has, act normal.  If not, cache the fact that the connection needs to be updated with a minimum difficulty change when it does subscribe and simply reply with the generic result: true for a successful auth.

2) Add a check to the subscribe function to see if the miner has already authorized a worker that requires a difficulty update.


Total changes needed:  Two variables on the connection object: boolean (isSubscribed) and an integer (diffAfterSubscribe), and about 12 lines of code.

EU-Stratum was (is) under attack.  The DNS was updated to a spare server, but unfortunately DNS updates can sometimes take quite a while before you see them on your end due to DNS caching.  The total full downtime was close to 20 minutes [the spare server wasn't caught up to the blockchain].  As of right now it looks like the vast majority of users have managed to connect to the spare server.

The Stratum proxy makes a single connection to the Stratum server.  Stratum defines difficulty on a per connection basis, so you would need to run one proxy per user to prevent the difficulty from being raised beyond the optimal vardiff levels.  In the long run it doesn't matter, you get paid proportionally more for higher difficulty.  However, like you said, it would suck for a slow user, and it would probably start to trigger idle worker warnings for very slow users due to the gaps between shares.

I've recently completely cleaned out the BTC Guild email inbox due to the amount of garbage clogging it up.  If you have an oustanding request to me that I did not reply to, please resend it.  I tried to make sure I responded to everything during the cleanup.  Going forward I should be able to reliably answer all the incoming emails promptly without any slipping past me due to the flood I get every morning when I first wake up.  I've made quite a few changes to that workflow since it was definitely lagging behind in the quality of service for emails that come in while I'm asleep.

Very neat idea, but I'm curious:  Is this using a custom stratum proxy?  If not, how are you working around the vardiff settings of both slush & BTC Guild?

You can, yes.  But if they had been solo mining they would've made ~30% less than what they've made with BTC Guild so far [assuming their luck would've been the same as what they've had with Guild so far].   This morning they were at ~110m submitted shares per solved block.  Looks like they're a little closer to 100m now, but still quite unlucky.  I'm comparing this to neutral luck, because BTC Guild has been *roughly* neutral (+/- 2%) for the last 3 weeks.

Obviously these numbers could be completely different solo mining (since the data being hashed wouldn't have been the same), but it's a good idea of just how much variance even a 45 TH/s miner has.  They're only ~6% of the overall network.

And what do you know, inventory showed up without the pre-notice from DHL.  Working to get the entire backlog filled before pickup today.  New coupons will be available after today's pickup.

USB Block Erupters are currently sold out.  A large order for new inventory was placed early this week which I'm hoping will arrive today (but I don't have a tracking #). 

There's a limited warranty, and you are supposed to contact the reseller.  Resellers are provided with replacement units in advance from ASICMINER in order to facilitate returns of dead units.  ASICMINER claims 6 months for the warranty, but that will probably expire once they release the next gen chips and stop producing old ones.  BTC Guild is pretty painless for returns.

Hi kslavik,
  Looks like your email got buried among the flood of false alarm emails from the database migration.  I've sent a reply just now.

Are you running at a really high difficulty on the pool?  2 hours to only have 1 accept and 5 errors seems really awkward.  If you're running at a high difficulty on your pool, that may be why you have such a high A vs HW rate.  Multiple your 'A' by the pool difficulty, then divide HW by that number to get your actual error rate.  This number should be 0.00-0.03 without cooling.  Anything over 0.05 would indicate something wrong with the hardware.

When you make your own block, the transaction which pays yourself the coins is a transaction without an input.  Part of that input space is used to create what is called the "coinbase" for the block.  It includes the current block number, and is also where things like ExtraNonce go (part of how Stratum works is letting miners adjust part of the ExtraNonce).  On BTC Guild's blocks, the coinbase also includes "Mined by BTC Guild" in the message (it's in hex, but sites like blockchain will show you the converted message).  The coinbase is also where merged mining information is added, which is why you can externally audit if a pool is merged mining.

In the case of BTC Guild, one of the components of the coinbase message is a unique 2-digit server ID.  This makes it impossible for two servers to ever end up generating the same work.  It's a precaution, though it's EXTREMELY unlikely to ever happen even without the unique ID (there's a lot of pieces that would need to randomly end up identical).