On BTC Guild, Stratum also includes variable difficulty to control the rate of share submissions, with a target rate of approximately 1 share per 5 seconds.  

Each share submission is roughly 110 bytes.  So your upstream bandwidth will be approximately 30 bytes per second upstream (a bit higher when you first connect due to not being adjusted to variable difficulty).  A share response is roughly 50 bytes, meaning 10 bytes per second downstream (for share submissions).

New work jobs are delivered every 30 seconds, and clock in at about 700-1100 bytes.  Using 1kb averages, that is 2 kb/min, or roughly 35 bytes per second downstream.

In the end, you're looking at less than 0.5 KB/s for both downstream and upstream communications.  Since backup pools will be receiving jobs as well, add maybe 0.1 KB/s downstream per connected backup pool.

The Germany stratum server has been put online.  You can connect to it by pointing a native stratum miner or the stratum proxy at de.btcguild.com port 8332 as you would with a regular miner.  It will provide you an redirection to connect to the Stratum backend.

DE server had a few minutes of downtime as I deployed an updating bitcoind to the server.  A new stratum server for EU miners will be available tomorrow.  If you have a miner with native support, you will be able to continue pointing it at de.btcguild.com and it will automatically forward you to the DE stratum server.

Any pool that has upgraded to Stratum or GBT based pool servers.

Stratum - BTC Guild & Slash
GBT - EclipseMC and Eligius

cgminer's latest github now has native stratum support for Linux users.

Over the weekend I will be doing a restart on the old pool servers to update bitcoind, and add new X-Stratum headers so that you can use cgminer load-balancing/failover on multiple BTC Guild servers over Stratum.  There will be 3 locations after the update:

stratum-de.btcguild.com (current DE server).  The DE server will automatically redirect native stratum clients to this server.
stratum.btcguild.com (Chicago, current pool servers).  The current BTC Guild servers will automatically redirect native stratum clients to this server.
The private DNS server will redirect native stratum clients to another server as well.


These DNS entries are not currently live!  I will post another update once they are enabled.

I'll be updating the BTC Guild getwork-based backends to use different X-Stratum redirects this week, now that we're starting to see integration in the most widely used miner.

The proxy responds accepted when it doesn't get confirmed by the server when dealing with higher difficulties.  I understand why you made it do that, since older miner software wasn't written correctly and crashed at higher diff, it's just annoying that miner accepted counts wont exactly match server counts when the proxy is masking lowdiff rejects as accepted.  Though it should be roughly the same.


Stale/Dupe are both reported on the BTC Guild website just fine.  "Other" rejects have been removed from reporting because they shouldn't be possible with stratum unless the server crashes and restarts.

The proxy is actually great for large farms even after native support is introduced, since it merges all the mining traffic for your whole farm into a single stratum connection.  For a small number of machines, I can understand waiting for native support.  Luckily ckolivas seems to be making good progress with cgminer.

I'd argue efficiency isn't even a meaningful stat on Stratum.  Pools sending you more job notifications aren't less efficient, they're actually MORE efficient (more frequent jobs = more current on transactions in the network).

Just FYI:  BTC Guild uses dynamic difficulty on the stratum server, which has been part of the main pool for almost 2 weeks.  Difficulty is adjusted for each connection to a steady rate of share submissions (1 per 3-5 seconds).

Everything is still running smooth.  I am encouraging all users to switch to Stratum still.  The server has been rock solid and hasn't even needed a restart since it was moved to the primary pool.

TX Fees will not come even close to making the block subsidy make up for the reward halving.  Regardless of how big the network becomes, we will likely never see blocks of > 50 BTC again except when somebody screws up their transaction.

Yes, you should run --real-target if you are using cgminer.  The proxy hiding real diff from miners is nice (since it stops some miners from breaking), but it's a bit confusing since those don't reach the server.  So you see "accepted" shares constantly, but your count on the website doesn't go up because they aren't the difficulty the server is expecting, so the proxy is just keeping your miner happy by lying to it.

Fast and slow miners on the same proxy is fine, the only problem with it is you end up with some workers showing much longer periods between shares.  The average for your whole farm is very consistent though.

Miners really shouldn't have much to worry about.  The portion of miners that will mine at a loss is very low.

When reward is halved, gross revenue is halved, and profit is cut in more than half since expenses are static.  Miners will drop out, difficulty will drop.  ASICs won't have a big effect on this.  It's very simple economics.  X investment returns an average of Y profit.  The more profit to be had, the more people mine, the worse their profit margin becomes.

The key here is the following formula:   Price/Difficulty * Block Reward.  If half as many coins are produced per day, difficulty will be cut in half (not precisely, but very close), unless price doubles, in which case difficulty would be roughly the same.  Obviously it will be a mixture of the two.  It will be worse off than we are now because there will always be hobbyists (who mine at a loss), botnets (who mine at no cost), and people with "Free" electricity (who effectively steal it from their oblivious landlord).

The only thing miners are going to notice is pool fees will likely go up/pools will cease to be free.  The reward halving DOES cut pool operator income in half, assuming each pool loses speed proportional to their current share of the network.  This is because pool's earn [at neutral luck]:  Pool Fee * Pool Share of Network * 7200 BTC (daily production of BTC).  With the change, pool's will be earning:  Pool Fee * Pool Share of Network * 3600 BTC (daily production of BTC).

That should be fixed now as well.  It was related to how my averaging window resets when a miner hasn't submitted a share for more than 10 minutes.

I think I figured out what triggered it, shouldn't happen again.  At least for a few brief moments you earned 1/3rd of all bitcoins ever mined in a 24 hour period.  At least on paper you did ;p

That's...interesting.  I'll have to poke around to figure out why you saw that.

Just to verify:  Do you mean you had the same problem on BTC Guild (with Stratum), or that it worked fine on BTC Guild?

If you had the problem on BTC Guild, was the hash rate on the BTC Guild website displaying accurately (and cgminer was just wrong)?  I'm wondering if old cgminer versions calculated hashrate assuming submissions would always be difficulty=1.  New versions definitely don't have any problem.

I think I found out your problem...I think you were refreshing the page after resetting your stats, meaning you kept submitting the POST data telling the page to reset your stats .

You didn't lose any shares from beta.  They just don't show up under 'My Account'.  You can find your old beta stats/earnings by going to Earnings History.  It contains a line of how much you were paid from Beta, and it has a link to the old beta stats page with your share details from beta.

I reset your stats again to look at it myself, and I've verified that this entire time you have had BTC and NMC shares being counted.  The database field which keeps track of resets shows you had 5495 btc and NMC shares accepted prior to the stat reset, and the current accepted counts match between NMC and BTC.