Deepbit makes sense.  Their servers are outdated and still use getwork.  Don't waste your time trying to use an ASIC over getwork.


What's strange is BTC Guild output showing 27 GH/s.  I do see one work submit delay, which could have been a disconnect/loss of connection on 3G.  The hardware errors seem a little high, but I'm not too familiar with BFL ASICs.  Your reject rate looks sane for BFL + 3G (higher latency) connection.

I'm actually wondering if you've been given a 25 GH/s mini-single instead of a 50 GH/s full single.

Captcha is just a pain in the ass for everybody, and there's no way to make it look good and fit with the interface the way the current login does.

2FA is something I've considered, but it's an extra layer I don't feel is needed.  If your email is locked, you're safe unless your email is compromised and used to compromise your BTC Guild account.  If your wallet is locked, you're safe even if your email and BTC Guild account are compromised.  2FA is a support nightmare when somebody loses/bricks/wipes their phone authenticator.  It's bad enough dealing with people who formatted their hard drive and lost their locked wallet, I'm sure phones are formatted/bricked/lost a hell of a lot more frequently than that.

To submit a block, the pool has to have the entire raw block worth of data.  So if the block is 500KB, the miner would have to upload the full 500KB being used to build the block to the pool, plus a bit of overhead for the JSON markup, assuming the miner was actually involved in building the block.

There are *some* ways to shrink this, where the pool dictates what transactions can be selected, with a tx-id integer (instead of full hash) so the miner could just upload a list of the transactions they included in the block, or a list of ones they excluded.  But once the miner is introducing their own transactions from their local node that the pool wasn't originally aware of, this is no longer possible, since the pool needs to know the raw transaction.



A 51% is extremely unlikely.  Even the largest pools now represent less than 30% of the actual network hash rate.  Luck spikes make their 24-hour block percentage above 30%, but this can't be predicted and is not reliable.  The 51% attack threat is having enough power to guarantee eventually you will make the longest chain as long as you keep trying.  If the largest pools were DDoS'd, most of that hash rate filters down to backup pools, so the argument that you just DDoS the largest pools to make a 51% attack easier is not quite accurate.

Modern protocols (GBT & Stratum) both have the full coinbase transaction visible to the miners, meaning you can verify that the block being built will be paid to a certain address or has a certain message encoded in the block that identifies the pool.  This allows you to audit if the pool is trying to skim blocks if certain users start seeing work without a coinbase message that identifies the pool.  In the case of BTC Guild, it's both, they always pay to the same address and always include "Mined by BTC Guild" in the coinbase message.

It's not no-trust, but all it would take is a few % of users monitoring this to determine if a pool was trying to skim blocks by sending a certain % of work that doesn't include identifying marks.

In *all* my experience with FPGAs/ASICs, duplicates are meaningless.  They're a firmware bug in that the hardware is resubmitting a result to the controller, rather than the miner actually doing the same work twice.  That's why I'm considering removing it (I already exclude it from your reject %), it's literally just a sort of visual artifact with no meaning/impact on results.

Automatic payouts (mostly the small ones under 0.10) were getting delayed earlier today.  A lot of people dropped their payout to <0.10, and as a result there was a backlog started.  I've re-run the small auto payout script a few times just now to clear out the backlog, and updated the pool payout schedule to run twice hourly for all 3 categories of payouts:

Large auto payouts (0.10+) now process 7 minutes after the hour and 37 minutes after the hour.
Small auto payouts (Under 0.10) now process 27 minutes after the hour and 57 minutes after the hour.
Manual payouts now process 17 minutes after the hour and 47 minutes after the hour.

They are 100% client side, and they will happen on ANY other pool at the same rate (unless the pool is sloppy and actually pays you multiple times for the same submission), BTC Guild is just one of the few pools that actually publishes the stat to your dashboard instead of ignoring it.  They are most commonly firmware related or hardware bug related.

Unfortunately, BTC Guild history pre-October 2011 is pretty much lost .  It was only about 5 months old, and I was still learning as I went along back then.  I didn't quite realize importance of keeping all that just for historical accuracy back then, after only being involved in BTC for half a year, paired with the long sustained decline in value after the 2011 bubble popped.  We didn't start signing the coinbase until PoolServerJ was released.

Considering 50BTC's history about quite a lot of things, including their PPS rates by cheating miners out of more than a few % due to rounding off the decimals...not a surprise.  I'm surprised so many people actually believe they're going to get any money out of them when they haven't made a post in almost a month.  Even if they were hacked, it's looking like they used it as an excuse to run off with whatever was left in the cold wallets at this point.

Try to keep it civil please (says the person who drops f-bombs regularly in IRC).

Sorry I can't give you the May 2011 through ~October 2011 speeds for BTC Guild.  All that information was wiped when the pool switched from free proportional to PPS .

One request/suggestion:  Perhaps a graph which only shows a smaller subset of pools?  It's virtually impossible to distinguish them when their colors are so similar.

Automatic payouts are processed every hour, and it sends *the amount you set it to*.  Set your auto payout to 25 and you'll get 25 NMC.  At 0.1, you'll only get 0.1/hr.

I remember my first Christmas in Bitcoin-land.  I figured the price would take a hit due to large selloffs as people sold their BTC stash to buy gifts...then the price went up instead and my first major prediction on BTC market movement was dead wrong.

It's not 150KB free (that's blockprioritysize, not minblocksize).  The space set aside for freebies/low-fee is 27KB.  If it doesn't have 150KB of transactions, it will include extra freebies to fill up the space.

Your shares per shift should roughly reflect your speed vs the pool speed.  So if you have 1300 GH/s and the pool is 1300 TH/s, you should be 0.1% of the shares in a shift.  At this time, shifts are 1 billion shares.  It will fluctuate between shifts based on your personal luck, as well as the pool's speed fluctuations.


Without knowing your mining speed, I can't provide much guidance on the proper difficulty.  128 should be fine as a starting point, the pool will adjust it higher if it's needed.

API apps may currently be broken due to attack mode being activated on Cloudflare.  Somebody is slamming the web server pretty hard.  The new API server is hopefully coming up within the next few days which will not be required to go through a cloudflare server [which breaks most API pollers when Attack Mode is turned on].

No pool at this time actually supports miners picking and choosing transactions with GBT.  They use GBT the same way pools use stratum.  They give you the block contents, you mine it.  You have no say.

There is a whole new level of complication added to the Miner<->Pool dynamic when it comes to letting miners pick transactions.  Specifically, the pool needs to know which transactions you're including every time you send in shares so it can validate your share results are correct.  This is a MASSIVE amount of bandwidth that would be required when looking at even a 10% fraction of the pool opting for it, not to mention a large increase in stale rates for most miners since they would have to upload 300-500KB to the pool to tell them the block contents.  Hell, GBT is already a complete major bandwidth hog compared to Stratum because it has to send miners the entire block contents when it pushes work instead of just a merklebranch.

They have, but I'm not sure if I'm going to bite on them.  Due to the big fluctuations in BTC:USD, they're quoting a price in USD for once.  Unfortunately, that puts me in the situation where by buying cubes for inventory, I'm basically betting against the value of BTC rising between the time I place the order and the time I sell them.

Small automatic payouts (payouts under 0.10 get processed in a separate batch) got stuck a little earlier today.  A few runs of the automatic payout script were run to clear up any backlog that was caused by the delay.  Larger auto payouts and manual payouts were unaffected.

BTC Guild has been using a max size of 500KB and min size of 150KB for months (the only gap being when we had the 0.8 hardfork event and had to wait a few months to give everybody time to upgrade before allowing another potential hardfork block due to the bug in 0.7 and earlier versions).

Orphans are a concern for all pools, but my experience has shown that these sizes did not materially affect orphan rates, and actually reduced stale shares for users.  The minimum size helped our nodes clear out the memory pool faster, which is the biggest slowdown when a new block is found and bitcoind recalculates the priority of everything in the memory pool to build it's new blocks.