One stratum server was acting up earlier.  Some work is being done to distribute the BTC Guild servers across more datacenters to reduce the effectiveness of DDoS attacks.

The website may be inaccessible for a brief period.


EDIT/UPDATE:  New DNS entries made for the website.  If you're having problems connecting, try flushing your DNS cache (in windows, open a command prompt and type ipconfig /flushdns, then restart your browser and try again).

Don't feel too bad.  Your winning hash wouldn't have been valid anywhere but that pool.  If you had been solo, you may not have found a single block yet .

Last I heard, slush promoted Stratum heavily to users who aren't already using it.  Same as BTC Guild, and I'm sure almost every other pool that implemented Stratum or GBT.  There is absolutely no reason for a miner to still cling to the outdated getwork protocol.  Worst case scenario they should run the Stratum Proxy.  The only resistance I've seen from running native miners are people on Phoenix.  If you can run phoenix, you can run the proxy, it is not difficult (easier than setting up phoenix, thats for sure), and offers immediate performance benefits.

This isn't a case of pushing brand new technology too fast.  It's a case of miners actively refusing to modernize and update to a protocol that is better in every single way.

It has been confirmed this miner on BTC Guild is ASICMINER.  So far there have only been two high profile confirmations of any Avalon units (Bitcoin Foundation and Jeff Garzik).

While I do believe they are tweaking things on their end, you're also going to see hash rate variance.  Since they are mining at diff=1024 currently, you see a few % migration + or - over the course of an hour.  The variable difficulty target rate at BTC Guild normalizes to a less than 1% variance when measured for a 24 hour period for any miner of 1.2 GH/s or higher.

On the bright side, BTC Guild should not be in danger of hitting 51% even if all 12 TH/s is pointed at it.  The network pre-ASICMINER was ~25 TH/s.  With ASICMINER at 12, it would be 37 TH/s.  Pre-ASICMINER BTC Guild speed was 4 TH/s, which would put us at 16 out of 37 assuming all speed was pointed at and kept on BTC Guild.  While it's "close", it's still missing 3 TH/s (a relatively HUGE amount of hashing power).

It's 43%, which is a high amount, and certainly a number I'd prefer to stay under (too much of an attack target), but given the size of the network these days, it's far off from the time that Deepbit actually had >51%.

The hashrate rises so constantly because the Hall of Fame uses the average hash rate over the course of an hour.  ASICMINER has been putting on single units at a time (each of which runs multiple workers).  As the small update said, this is somewhat of a stress test.

I'm very happy my pool was chosen for the stress test, but I do share the above concerns and hope after the testing is done it is split among pools.  For stress testing, it makes sense to use a single pool so you have a consistent point of comparison when encountering problems.  I'm sure once the units are confirmed to work we'll see them move around and diversify.

It's automatically calculated every time a shift completes.

I'm looking into it.  I actually calculated it by copy & pasting the table into excel and selecting the Block/Per Share columns to autosum/average .


EDIT/UPDATE:  I've added the last 100-matured shifts per-share rate above the PPLNS Shift History table.  This number is somewhat unreliable for comparison after a difficulty change.

*runs off with a cold wallet file and blames it on someone named Sir Thomas Erick Trendon the Third*

PPLNS has paid more than PPS consistently over the last month.  The problem is you focus on bad shifts and don't acknowledge the good shifts (its human nature to dwell on the negatives).  If you were mining with two identical speed workers, one on PPS, one on PPLNS this month, you would have made somewhere around 110% PPS on the PPLNS worker.  Bad luck drags on longer than good luck, it's just how it works (due to bad luck requiring significant time to be considered bad luck).  But if you get one shift of 15 blocks, that makes up for 6 shifts of 8 blocks, or 3 shifts of 7 blocks.  And generally when you get a really big shift like that, you have a few others similarly above the average.

Examples with real data:
The last 90 MATURED shifts (you cannot include open shifts) have averaged 9.3 blocks per shift, AKA: 0.0000076339143/share (more than 100% PPS).
The last 190 matured shifts have averaged 9.48 blocks/shift, or 0.00000777397457/share, which is 2% above 0%-fee PPS.

It's hard to oooover-state my sat-is-faction.

Guess I can't troll as much anymore .  Very honored to have BTC Guild picked by ASICMINER for their initial ramp up/testing.  I've made myself very available for them to help in the ramp up period.

ASICMINER now has the privilege of being the first to truly give Stratum a test as a next generation mining protocol, and the results have been fantastic from my end.

I've not added client.get_version yet.  It's one of those commands that offers fairly limited use.  I'll probably add it in the coming weeks as I continue to work on more diagnostic utilities in my Stratum code.  I do know that they are using a Stratum Proxy (most likely slush's proxy) to run all their workers through one connection.

User 67117 has now become the first connection on Stratum to reach a 4-digit variable difficulty.

[00:39:31] Increasing [obfuscated]'s difficulty to 1024!


What does that mean?  It means somebody mining at 1.5+ TH/s is using roughly as much bandwidth and server resources as a miner running a graphics card over Stratum, and LESS bandwidth than a graphics card using the outdated getwork protocol.

Ahh, the Java, it burns!  Glad to see another fresh implementation of Stratum.  I'll try to take a deeper look at it tomorrow, but so far I must say it's one of the cleaner java-based pool servers I've seen in quite some time.

For weeks I've been waiting for an event like today.  A heavy crash of multiple dollars, a brief period of hesitation, and then a return back to the growth we had been seeing previously.  The June 2011 market would've taken this event and crashed down to rock bottom, but today we have enough support and confidence that the price was able to recover in very little time.

This was actually a great interview/panel.  One of the few times I've seen an interview about Bitcoin bring up the black market/gambling/tax evasion aspects without dwelling on them.  So many of the articles/videos tend to focus on the "dark side" of Bitcoin, completely ignoring that every currency in the world is used for gambling, tax evasion, and drug trade.  Bitcoin can do all that, and SO MUCH MORE!  It was great to watch, and I hope future coverage can keep the positive aspects at the forefront of the discussion like this video.

Higher payouts are a factor of MASSIVE luck today .  But with this user in the pool, it should help shrink the daily variance a bit.

It's a mix of both.  They can filter some attacks, while others are blackholes.  It's one of the reasons my colocated servers there run with virtualization, it makes it very easy to migrate the services over different IPs when blackholes are required.  I've actually got two extra subnets already reserved at the DC for my use that I can switch to if an attack ever targeted my current subnet ranges.