The graph would only 0% luck if we have 3 shifts close with 0 blocks (which would be ~6.4x diff I believe).  The graph uses the average of 3 shifts since graphing every point over 3 months caused phones and some computer browsers to get slow/unresponsive.

GHash.io also burns through about 4x as many blocks as BTC Guild.  That means they would average 4 times more 5x(+) difficulty blocks than BTC Guild in the given time frame.  They also don't last as long since they are much faster, so the time people spend staring at a long block doesn't seem as bad even though it's no different.

And we just did it.  Actually surprised we haven't had a 0-block shift until now, considering the 10 shifts have only been 100b shares combined for months.  These days that means you only need a block to hit ~4.8x difficulty for a shift to end with 0.

EDIT:  ~4.7x difficulty as of this post (110b shares / 23.8b diff)

No, I'd shut down instead.  I have *zero* desire to be responsible for collecting and maintaining personal details on users.

When you're mining, you're actually attempting to brute force a hash to be less than a certain value.  On modern hardware, this is generally billions/trillions (GH/TH) times per second.  Bitcoin only cares about an actual solution which is less than the value required by the current difficulty.

"Difficulty 1" shares are hashes which would have met that requirement if the network difficulty was still 1.  Approximately 1 in 2^32 (~4.2 billion) hashes will produce a result that is at least good enough for difficulty 1.  From that point on, the easiest way to look at is is exponentially:

50% (1 in 2) Difficulty 1 results can also match Difficulty 2.
25% (1 in 4) Difficulty 1 results can also match Difficulty 4
12.5% for Difficulty 8
6.25% for Difficulty 16
....
1 in 23,844,670,039 chance of matching today's network difficulty.


Pool mining uses this as the basis for allocating block rewards.  If you were solo mining, Bitcoin would simply ignore any results that are not the network difficulty (or better).  With pool mining, the pool has you submit any results that match a certain difficulty (it used to be diff=1, these days it's normally variable based on your speed).  Most pools target very frequent share submissions (10-30 per minute).  This lets them get a fairly accurate estimate of your local hashing speed, and also allows them to give you a fair share of the reward by comparing how much effective work you have submitted with the rest of the pool's miners.



The "problem" you're being given by the pool never changes, just the quality of the answers you give back.

I looked into it a long time ago, but at this point I'm not looking at touching the code which handles payouts.  If something goes wrong, there is no way the pool would recover from the loss without it affecting the users.

Hidden workers are fully functional.  They simply don't get shown on your dashboard, worker charts, or the API.

Correct.  When you connect there's two phases.  The first phase is a botnet/DDoS filter.  Then you get redirected to the pool's load balancer, which will put you on one of five physical servers.  One of those five had the issue.  The load balancer is extremely efficient at keeping each server within +/- 5 connections of each other, so one server going down will take out almost exactly 1/5th the connections, and the load balancer will redirect them to the next available server upon reconnect.

There was a very brief interruption of service for about 20% of miners.  One backend lost its bitcoind connection to the other backends (used to virtually eliminate the chance of two pool servers orphaning each other's blocks) and a restart was triggered.  Everything is working normally again, and it should have only impacted about 1 in 5 connections.  If it did affect you, it likely only lasted a few seconds (long enough to reconnect and have the load balancer put you on a different node).

They will never provide an exact definition of "financial services".  I would say a pool probably is a financial service, though it certainly isn't the kind they're targeting.  All we can do is wait to see what the next form of BitLicense looks like and then adjust as necessary.

Pro-actively blocking a state, and requiring users to affirm they are not from that state should be adequate in preventing the state from trying to establish a nexus when there are clear attempts to prevent that state from accessing it.

It will require an affirmitive "I am not a resident of the state of New York" and "I do not run any of my equipment from within the state of New York" before allowing you to register a new account, and existing accounts will have to affirm that within a certain time frame or else the account will be frozen.

I will also be adding IP-range lockouts for known New York IP addresses which will give a splash page stating that New York residents are forbidden from using the pool.

I'm guessing very, very little.

I've checked my 5 mining nodes and my payment node.  Only the payment node's namecoind goes over 1-2% CPU, though it's generally only peaking at ~15% then goes back down to 1-3% during "idle" time.  My payment node for namecoind is a SIGNIFICANTLY weaker machine though, so that may just be due to the difference in CPU power.

A better way to put that is you CAN use a coinbase address when mining on Eligius.  But there are many reasons you should not use a wallet which you don't have direct control of.

I should say, it only takes one of the users being sent to "PrivateAddressXYZ" paying attention.  Obviously if they're sending 5% to another address like in your example, you'd probably need multiple people.  Mixing account ages/speeds as well, in order to have a good spread of candidates in case the pool is using certain criteria in order to pick which users to send somewhere else.

WDC deposits on Cryptsy have finally cleared.  I will be transferring some coins out to cover the currently pending withdrawals.  A huge conversion was just done of ~50k WDC.

Both Stratum and GBT provide the miner with the complete coinbase transaction, which means you can audit exactly what address(es) are getting paid by the work you're completing.  That doesn't mean a bad pool can't still be filtering off hashrate, but they could not do it in complete secrecy.  It only takes one user paying attention to reveal the theft if it was happening.

Deposits have now been recognized and my internal accounting agrees with Cryptsy's again.

Hey, what's wrong with a one man operation?