It's not a flaw in the protocol, it's a flaw in my current implementation.  It was significantly easier to tie difficulty to the miner connection object, rather than to keep a list of the miner's recent difficulties per work unit.  If I did that, it would allow you to submit "old difficulty" work, and be credited at your old difficulty.  I didn't do this because difficulty adjustments do not happen frequently enough for this to materially affect any miner unless they have a habit of reconnecting every 10 minutes.

I will be making that change to account for "stale olddifficulty" shares in one of the upcoming pool software updates.

Variable difficulty -has- to adjust upon new work without being opened up to exploitation, regardless of protocol used.  It's very simple for a fast miner to withhold higher difficulty shares when it knows that it's going to force a difficulty increase, then submit them for higher credit once the adjustment lands.

The Stratum pool finally crashed again, and I've found the piece of code that caused it.  I'll be working on a fix tonight and hopefully deploy it tomorrow.  Downtime wasn't long, and the pool is back up and running while I work on the fix.


EDIT/UPDATE:  I've restarted the primary stratum server again, with a fix deployed for the crash.  It's going to run in debug mode for the next month, but that shouldn't affect user performance in any way.

The full SPM is based on a 5 minute average.  If they are 20 SPM or higher, the difficulty is doubled.  There are extra adjustments during shorter time intervals to catch extremely fast miners in under 5 minutes.  Additionally the difficulty is halved if no shares are submitted after a minute, or if SPM drops to 6 or less (which would only happen if the miner leaves the server/turns off miners behind a proxy).

BTC Guild:  Stratum with variable difficulty.  Current SPM target is 15 (10~19 depending on a miner's proximity to a difficulty adjustment).

Even if blockchain.info had 0% unknown, it would be the wrong graph to use.  They misreport pools blocks frequently.  I love blockchain.info's service, but their pie chart of hashrate distribution causes so many threads to show up everytime they screw something up.

Using blockchain's graph would be a bad idea because it's so inaccurate on a regular basis.  http://blockorigin.pfoe.be/ would be able to provide a more reliable hashrate over time graph, though I don't know if they keep historical data beyond 2016 blocks.

If they did it wouldn't matter.  The rate is based on doubling difficulty.  To increase, you have to be above 20 shares per minute (for 5 minutes).  To decrease you have to be under 6 shares per minute (for 5 minutes).  So the theoretical range is 6.1-19.9 shares per minute, though it would require very awkward share spikes to end up outside of 10~19 shares per minute.  Average being 15 SPM.

My point was unless the miner is constantly leaving the pool, they won't be seeing difficulty adjustments outside of the first few minutes.

Except I don't check shares that are rejected as block solves, so it's not saving money, it's a break even (I don't pay the miner for submitting olddifficulty shares, and I don't check to send them upstream).  Even so, the fact is difficulty changes are infrequent.  They will only happen when you first turn on your miner.  And only a few times (if any).

Once I track down the current bug on Stratum that caused the last crash, I'll look into adding a small window where old work can be submitted after a diff adjustment.  This really isn't a high priority though since any miner that isn't constantly hopping between pools will rarely see an olddifficulty reject.

BTC Guild forces you to submit new work when updating difficulty currently.  It won't accept work from previous work when you're adjusted because it keeps track of the miner's difficulty separate from the work sent to the miner.  With the current setup, if I accepted old work, you'd get credited at the new difficulty.  This opens up an exploit where a very fast miner can purposely withhold higher diff shares at first, knowing that they are going to force multiple difficulty increases in a short time, then submit them all for higher credit than what they should have been earning.

While it could be done in another way (keeping a list of difficulties for the miner as of each WorkID), it would add a lot of extra code for effectively no gain.  We're talking maybe a few pennies over the course of a year, if that.  Difficulty adjustments are a rare occurrence.  They only happen when you first start mining over the connection.  That share you "lost" from the diff adjustment was 0.0001 dollars (1/100th of a penny).

Suggestion for Variable Difficulty column:  Don't just put Yes/No.  Put 'None' on pools that don't offer it.  For pools that do, show the target share frequency (or "User-Defined" if applicable).  As an example, the BTC Guild variable difficulty target frequency is 15 SPM (Shares-per-Minute)

I just wanted to give everybody a small update on what new things will be heading to BTC Guild soon.  The Stratum pool is being run in a debugger right now, so the next time it crashes (first one took over a month to happen) the bug that caused it can be swiftly patched.

After the crash bug has been found, I will be working on a special log file that is updated whenever the Stratum pool updates its transactions and sends out new work.  The goal of the update is that at any time, a miner will be able to inspect the full list of all transactions that are a part of the block being created.  As of this time I don't know if the page will be able to provide full details like you would see on blockchain.info (inputs/outputs) or just the transaction hash + raw transaction data.

PPS pools function on probability (and depending on how low they set their fee, gambling).  They pay a rate of (1 / Network Difficulty) * 50 BTC * (1 - Pool Fee%).  So the rate you get paid per share on a PPS pool will only change roughly every 2 weeks, when the network difficulty adjusts.  That is why PPS pools charge fees, it is a gamble.  The lower the fee, the more the pool operator's are gambling that they won't hit a run of bad luck.  organofcorti (or was it Meni?) has a writeup about the odds of PPS pools going bankrupt based on fee/how much BTC they've set aside as a buffer.


EDIT:  So apparently the post I quoted was a bit older than I thought, didn't notice that this thread has been going for about 3 weeks.  Sorry if you already figured out how PPS rates are set/modified since the original post.

Python isn't immune to crashing ;p  And with 600 concurrent users CPU usage never breaks above 3% of one core at peak.  Peak being when it's parsing a getmemorypool output with a large # of transactions, and spitting the work out.

I've been running Stratum for over a month now on the main servers with no crash, and even beta didn't crash after the first week, just restarts to add/speed up features.  I'm pretty surprised it happened now, but hopefully it will happen again and I can backtrace the exact cause and implement a fix shortly after.

Actually, this is a must have feature.  If cgminer is going to support BFL ASICs, which include a "coffee warmer", I think cgminer should interface with my coffee pot to brew my coffee as well.

The real problem was the transaction threshold Deepbit used was not published.  The default fees generated by bitcoin did not meet the hidden criteria.  Sure, Bitcoin is all about free market, anybody can set their fee requirements.  But you'd expect that in that situation, those requirements would be published somewhere.  It's pretty messed up when (at the time) ~25% of the network was not processing transactions that included the default fees.

We've actually been running faster than Deepbit for the last 4 days straight everytime I've checked.  I think Guild is destined to always fall into the #2 slot.  Not a bad place to be, but never taking the gold .

My Stratum pool is not related to the proxy or pool that slush has posted.  It's an entirely custom C++ design.

Stratum had its first crash...straight up segfault.  Restarted it inside GDB to catch the cause next time it happens (if it does).

The stuck payouts (payments that were made but never confirmed by bitcoind) have been manually added in, and the accounts have been "unfrozen" so they can request payouts again.

I've updated my payout script slightly to fix this faster in the future.  Whenever it happens again, the payment will be added to your history (so far there has never been an instance where the payment wasn't made), and your account will be "frozen" again.  When it happens, anytime I personally go to the website a very large blinking banner will appear telling me that a payment was not fully completed, so that I can go in and verify the transaction and unfreeze the account.  I load the page constantly throughout the day, so the maximum time an account should ever be stuck in frozen status would be maybe 12 hours except in very unusual circumstances.

During "frozen" status, you can always turn on automatic payments.  This has always been the preferred method of users handling their payouts since it means I'm not having to move coins in/out of a cold wallet as a result of users leaving coins in their account for long periods of time.