I've been asked a few times by email (ever since ASICMINER and other users came) about plans for PPLNS shifts, now that they've gone from ~1 hour to ~30 minutes each.  The time it takes for a PPLNS shift to complete is not very important.  The N value is currently 30 million, which is ~8 times higher than the current difficulty, meaning an average shift will receive ~8 blocks worth of payments.  The very high value for 'N' was to reduce per-shift variance.  Higher 'N' values have virtually no effect on 24 hour/7 day/30 day variance, but many users would hate to see a share receive no payment at all, so a high 'N' value makes the odds of a shift receiving 0 payments very low.

However, there will be an increase to the 'N' value as difficulty rises.  I'm currently anticipating increasing N from 30 million to 60 million in March, based on current network speed projections.  I will update again before the change is implemented.  Again, this would have very little affect on overall earnings, aside from smoothing out individual shift variance, and hopefully reducing the odds of a shift receiving 0 blocks.

Sorry I didn't mention DE.  If you are connected through de.btcguild.com:8332 or de.btcguild.com:3333, you do not need to make any changes.  These only affect the US servers.

That is certainly one way a pool can handle it, and one way I've been considering for BTC Guild.  However, I think simple minimum difficulty settings available through the frontend solve problems for large workers.  And at least with my implementation, the pool will adjust very high speed workers to an appropriate difficulty before bandwidth becomes an issue.  They'll see a spike at the very start, but with aggressive difficulty adjustments you can prevent it from being enough to saturate even on a very slow connection (3g/dial-up).



Stratum by definition is per-connection difficulty.  gigavps's suggestion would only affect pools which try to remember/re-instate difficulty on a after worker authorization.

I am continuing to work on shifting servers around in the background, and adding new IPs to the round robin DNS entries for Stratum.  Users should not be affected by any of these changes (no old servers are turning off yet).  This process is almost complete, which should eliminate the ability for a DDoS to take down all servers for extended lengths of time.  The servers are being relocated to different providers all over the country, some of which have policies which should prevent one of the more common DDoS attack vectors (many-many gbps UDP floods).

No amount of protection can eliminate the DDoS threat (at least without spending every dime the pool makes and possibly more), but by spreading the servers out, the hope is that future attacks can not take out all servers simultaneously, and that I will be able to modify the DNS entries to help mitigate attacks as they happen.


One note to Stratum users:  If you are currently mining on 50.31.149.57 (this used to be the redirect URL if you connected to btcguild.com:8332), please change your miner over to stratum.btcguild.com:3333 .  The 50.31.149.57 server will be turned off once the active connection count drops under 50, or by February 28th, whichever happens first.

Overall network hash rate will move a lot soon.  BTC Guild's luck since the difficulty change has been abysmal, roughly HALF the block generation we should be having at this speed, which would swing the overall network hash rate graphs about 2.5-3.5 TH/s under what they should be.

Although ASICMINER shareholders can look on the bright side, imagine if you were solo mining/p2pool and only seeing half the earnings you expected instead :p

Glad it's working so great for you!  Of course one rejected would increase your reject rate infinity% compared to the current value .  But most miners (good FPGA drivers/not running insane intensity) the target acceptance rate is 99.90%+.  The newer Stratum servers have helped as well, with a faster production of work after a new block is detected (higher ghz processors in the new servers).

The botnet detection would cause you to see constant disconnects whenever you authorized a banned worker.  It is quite obvious if it's affecting you.  I'd try reconnecting and seeing if you're still noticing any kind of drop.  The only reason I can see for a drop is if your miner didn't reconnect promptly (since hash rates displayed are an hour long average, it takes a while for the ESTIMATED HASH RATE to become accurate again).

I've felt that the client should send their name/version unsolicited with the initial subscription from the start.  It makes sense for the client to push that data, rather than the server to ask for it explicitly.  It's just a few bytes sent once.

Don't forget that the OzCoin miner may have been one of the proxy/pool hopping pools.  I know they always used to go to OzCoin/Eclipse when the more easily hoppable pools were having bad rounds.

Great idea, nice way to get some more people involved (and I just love the concept of paying people to "mine" bitcoins in Minecraft).

1 BTC sent to 13m8dAb16KqWv7v9oEsr97mYMXbynR6CoD (TXID: 0ab3836b7d6da4e19707d659d86d58167eb3cf801b4e5d130f5af53536db8a30).  Feel free to point them to BTC Guild if they want to put the rest of their GPU to work (although Minecraft seems to have no problem maxing out any card for some reason ).

I know, just exaggerating .

If our luck doesn't pick up soon we're still not going to show up on top next week !

There was a brief restart to some of the Stratum servers.  Each server had about 2-3 seconds of downtime to deploy a patch that aims at helping detect and remove botnet miners from the Stratum interface.  I've recently discovered two accounts that appear to have been spreading a cgminer/bfgminer bot using the Stratum servers.

Not really.  It wasn't even 3 hours between the blocks.  The entire network regularly (few times a week) has periods of an hour or more without a block.  That's why variance is still a consideration when you're a huge amount of hash power.  A bad luck streak can drastically impact your earnings during a difficulty.

Unlucky since the difficulty change.  Our blocks show up clearly on Blockchain.info due to being tagged with 'BTC Guild' or 'Mined by BTC Guild' (Stratum uses 'Mined by', getwork is just 'BTC Guild').  The day is young though!

EDIT:  See, this always happens.  Within minutes of complaining about luck, a block appears.  And if people do the opposite and mention our good luck, we have a dry spell.  The curse of the word 'luck' in relation to blocks.

The BTC Guild website was being migrated off of the server.  The default page (www.btcguild.com) had a Migration in process notice, though other links would have been broken.  The only part offline other than the website was one of the getwork nodes [now also migrated].  Luckily, ASICMINER is using Stratum which kept chugging along just fine.

The pool website is temporarily unavailable.  Working on restoring it immediately.  Migration to a different host node is also happening while the current node is being restored, so this should not happen again unless there is an attack.

All stratum servers, and most getwork servers are still functioning normally.


UPDATE:  Website is back online, and the one getwork server that was down should be restored shortly.
UPDATE2: Server migration in process for the website.
UPDATE3: Server migration was finished after about 20 minutes.  Mining on most servers was unaffected, only one getwork server was unavailable for part of the migration.

What does 50 BTC track that BTC Guild does not currently?  Also, the BTC Guild minimum payout was dropped at the beginning of the year to 0.02 [which is less than $1], and will be dropped again in the event that a rally takes us to where the minimum payout is more than $1 again.

You're seeing the mixture of > 4 TH/s added to the network + variance.  It can create VERY large spikes in 24-hour estimates.  I say > 4 TH/s because ASICMINER has added > 3 now, and there have been a large number of miners coming back online in response to the recent rallies.

There was a small problem earlier where users were being given the error message that they had made too many invalid login attempts recently, and should wait ~800 seconds.  This was an unexpected side effect of moving parts of the website/database infrastructure.  The problem should no longer appear, and I'm sorry that this error was not caught earlier in the transition.