The problem is users seem to think there is "real time status".  Shifts update when blocks are found, or a new shift completes.  Those are the ONLY times anything changes for a shift.  There is absolutely no way to know what the outcome of a shift will be until it is no longer receiving payments (meaning 10 newer shifts have completed).

In BTC Guild's case, you can see the current rewards paid to open shifts.  I have a warning that says the number aren't final.  That doesn't stop a significant number of people from complaining to me about shifts not getting paid, and that "something must be broken, there's 7 0s in a row!".  DrHaribo got the same comments, and changed it to simply not show the 10 open shifts.

I think not showing the current rewards of the 10 open shifts by default is a good change, and I may end up implementing a similar change on my pool.  Though I think an option to enable the stats on open shifts should be provided for those who actively want it.

PPLNS in general (shifts actually simplify it for reporting) is hard to explain in a table.  If I were a graphics designer it would take me no time at all.  I think the key to explaining PPLNS relies in either a real-time conversation, a LOT of images, or the best way: an animation.

A simple GIF could probably clear up PPLNS misunderstandings in under 15 seconds :/.

Not much can be done to help when the only information we have is that the miner isn't mining (which is the case if you're showing offline).  What hardware?  Region?  What does the mining software say?

Nope.  NMC is still working.

The actual earnings aren't known until a shift stops receiving payments.  DrHaribo made the right choice (one I might copy for my pool) by simply showing a '?', to avoid people complaining about the earnings on recent shifts before they've matured.

Your new speed had only been active for 2 of the last 10 shifts as of the time those blocks were found.  Additionally you had practically 0 work for one shift (probably when you were setting up the new gear).  Your contribution per block the average percentage of the last 10 shifts.  There's an entire piece in the Support section which covers the chrage-up/wind-down way rewards are distributed when first starting or stopping on PPLNS.

Sorry for the website downtime.  As others have noticed:  Mining is completely unaffected.  I'm trying to figure out why cloudflare is serving up a "currently offline" page while the web server is having no issues when connected to directly.


EDIT:  Website frontend is back online.  Absolutely no mining time was lost during the outage.

Just to add some emphasis to this:  Your income would drop a bit because you didn't work for 4-6 hours.  But your pay for the other hours you did mine on any proper pool will not be penalized by the lapse in your mining time.

The most common misconception with PPLNS is that you need to mine in all currently paying shifts in order to receive "full" payments.  This is false.  The expected payout of any share on PPLNS is the same whether you mine for hours without stop or mine for a few minutes every day.

If you're a regular miner it has no impact on your average reward.  Some shares will go unpaid in long blocks, but the shares that do get paid get more per share.  The same amount of BTC goes out to miners in the end.

Yes, BTC Guild has had user selectable difficulty on the worker management page for ages (just a few days after stratum was announced).

The default difficulty for workers has been increased from 4 to 32.  Existing worker settings have not been changed, and new workers can be adjusted back down to lower levels if desired.  The filtering server (the server you initially connect to) has also been updated to a difficulty of 16 before it will redirect you to the appropriate backend/loadbalancer.  As usual, the filtering server is only accessed for a single submission when you first attempt a connection to stratum.btcguild.com or eu-stratum.btcguild.com.

Every decent pool has their difficulty automatically adjust.  The problem is that they all start at a base level and adjust up from there unless the user sets a minimum level/starting level (which most pools also have the ability to change).  If the user keeps the minimum/starting level too low, the S4 will choke to death before it is adjusted to an adequate level.

You're missing the point of this attack.  The point is that a person includes a TX fee high enough that it is so valuable that miners will try to orphan the previous block in order to claim the transaction fee for themselves.  If the fee is high enough, the cost of trying to do this is less than the payoff, making it worth doing.  By doing this, essentially the entire network (except the entity that found the block and honest miners) stops working on the longest chain, in order to fork the chain and claim that fee for themselves.  This would slow down the network as a result (since most of the network is now re-mining a prior block in order to claim it themselves).

If the network were split evenly, and all actors were dishonest (claim it for themselves), this would result in an extremely slowed block rate because basically each entity would be mining their own version of the blockchain, hoping they get a long enough streak that the other competing entities give up on claiming it for themselves.


However, the current network is NOTHING like that.  Large entities have too much discrepancy in their speed, and the majority of the network is honest.

This attack would only cause network slowdown, not a freeze, so the name isn't very good.  While the entity that first solved the block is working on a new block in the chain, the rest of the network is mining the previous block still to claim it themselves.  Even if the entire network is doing this, eventually you would end up with one entity creating a chain long enough that it will be impossible to wrestle it back via forced orphans.

This "attack" only works if the entire network is divided into competiting entities with almost identical speeds that are all acting to purposely orphan another entity's block to claim the enhanced reward themselves.  The second you introduce any speed discrepancy *OR* miners who aren't trying to break Bitcoin, it fails.


EDIT:  I can see honest miners being forced out eventually, but I am doubtful we'll ever see the network in a situation where the big entities are close enough in speed for this to ever actually happen.

No.  Most americans and most companies do not elect for a different fiscal year, following the Jan-December calendar year for taxes.  The federal government uses a fiscal year of Oct-Sep, but very few companies use that (April - March is the 2nd most common, behind Jan - Dec).

And others say they don't work on Guild...I love how it seems ASICs are becoming even less consistent than their first generation units.

No direct fees on NMC withdrawals, but only automatic withdrawals are done for NMC (intervals of 0.01), so the sub-cent bits (0.00x) can't be pulled out.  So I suppose the "fee" is whatever is leftover beyond 0.01 if you empty the account and quit mining.

While not seeing it in the thread (yet), I've gotten about 2 dozen emails so far about the current block and wanted to put things into perspective:

The current difficulty is 34 billion.  The current shift length (which was increased recently) is 14 billion shares.  We have had 13 shifts without a block so far, which means 182 billion shares.  That means so far we have not even hit 6x difficulty on the current block, though we're not far from it (another shift and a half roughly).

 The pool lost a 2 PH/s miner, which accounted for about 15% of the pool's speed, and meanwhile the network difficulty went up by 16% just a few days after.  That means the pool average block time went up by a relatively large chunk over the last week.  The longer the average block time for the pool, the longer a bad block will last.  It's simple percentages.  BTC Guild's average block time at it's current speed is a little over 3 hours.



EDIT:  And now over 6x diff, closing in on 7x...I really hope this isn't the first 24h+ block in BTC Guild history (not counting the first one I solo mined and the time we were DDoS'd completely offline for more than 24h).

There are no fees for automatic withdrawals.  There is only a fee for manual withdrawals under 0.01 BTC.

The per block rewards are a calculated value.  The system wasn't designed for so many shifts between block solves from the high difficulty, lower pool hash rate, and the absolutely shitty luck for the last 3 days.


EDIT:  A little more detail:  The dashboard loads up your stats for the last 50 shifts internally, and then uses that data to *calculate* your per block reward.  The pool doesn't store rewards per block, only per shift, but it can calculate the other value (with an insignificant bit of rounding).  Unfortunately, the luck in the last 3 days has been bad enough that 50 shifts isn't enough to contain all the data for the last 11 blocks.  I've pushed an update that extends that 50-shift window to 100 shifts, so the problem should be fixed.