Welcome to my world.  Just don't expect them to ever start reading, they're convinced they completely understand everything already.  I find their ability to write coherent sentences is a good indicator of how much they actually know.

So cute when people who have no clue how PPLNS works try to make arguments about it.  I like that he was hiding in another thread.  I still don't understand how it's so hard of a concept to grasp: 

1) Shares get bundled into shifts.
2) Blocks get found.
3) Blocks get applied to the most recent group of shifts.

The actual length of a shift is arbitrary.  Longer shifts only reduce the expected variance, so instead of being 30-170%, they're 50-150% (example fake numbers, do not use as fact).  You lose out on the extreme highs, and you gain by not having extreme lows per shift, but in the end, it all comes down to your mining speed for the last 24 hours and how many blocks the pool solved.

My guess is this person is too stupid to understand PPLNS, probably the same person who emailed me the other day since he had the same "40 minutes is too short, you're screwing people" argument.

My guess (given his lack of proper english) is he's referring to the per share rate in the last 24 hours being less than it was for the same # of block solves in shifts a day or two before.  14452 paid more per share for 13 blocks than 14486 which also had 13 blocks in his screenshot.

Which is obvious, and there's even a news post on BTC Guild, and a forum post explaining it:  Shifts were increased from 2.5 billion to 3.25 billion shares.  That means when a block is solved, it's split over ~30% more shares, meaning the payment per share from a block is ~30% less.  But, it also lasts ~30% longer, meaning on average a shift will find...wait for it...~30% more blocks.  It ends up being the same damn number you moron, just lower variance per shift.  NEITHER OF WHICH affect 24 hour earnings.


EDIT:  Update with more clarification over what I think the person is trying to imply, and a correction to the % (it's closer to 30% than 25%).

Could be worse.  Your 24 hour earnings is just low.  Mine is negative.

14494 is the msot recently completed shift.  The most recently completed shift will always start with 0 blocks.  That number increases for hours (as noted by the giant bold text right above it).

You clearly weren't paying attention.  The network difficulty has been going up by roughly 20-30% every 10-11 days since October.  Your earnings have similarly declined regularly since then.  On a day to day basis they've gone up and down wildly (look at the luck chart which shows the last 3 months of luck per shift), but on average, each 10-11 days has been earning you less than the 10-11 days previous.

I have mining hardware.  I did test it myself.  For days on end, purposely trying to break it.  It did not break.  There is no feasible way to test something designed to handle tens of thousands of connections with varying hardware and varying speeds, on a local test.

The project was completely scrapped because I do not want to repeat live testing, and there is no alternative to live testing to test this kind of software.  I cannot just go up and buy 4000 TH/s and place it all over the country so it connects from 30,000 different locations in every country on the planet.


Even the largest tech companies eventually have to push out updates to their online services, and they break.  There is simply nothing that can compare to regular users connecting in massive numbers.  Unit testing and local stress testing simply cannot mimic the organic loads and broken client implementations that exist in the real world.

It's just bad luck, not like we haven't been due for some of it for months now.  Hell, our 1-week average is still 105%.


However, the new shares per shift number will bring the # of blocks per shift to ~14 for neutral luck once all 10 open shifts are at 3 billion shares each.

There's been a reasonable bump (2.5 billion -> 3 billion) in the length of shifts due to the recent growth in overall pool hash rate pushing shifts below the 40 minute mark.

For those who still don't understand PPLNS:  Shift length has NO effect on your overall payout.  It's purely a way to do the accounting and smooth out variance over a short period of time.  In a 24 hour window, the length of shifts has NO effect on your payout, that's purely based on pool luck.

By default I believe it is EST, but it adjusts to your local time zone if you set one in the settings.

The luck graph only reflects closed shifts since it can't measure luck from a shift that is not done getting paid.  Its generally one shift behind the most recently closed.

I'm assuming you mean 3 shifts, not 3 blocks...shifts only update with payments when blocks are solved.  Since shifts only last 40 minutes, and block solves can take anywhere from 1 second to 3-4 hours, it's not unusual for 2-3 shifts to have 0 blocks paid when they're at the top of the Open Shifts section.  That is why there is a large BOLD NOTICE stating this exact fact.

Swap back and forth if this happens until the error doesn't show up.  It shouldn't happen for very long if it happens at all, it's when the frontend server is unable to access the validation server, generally it's very brief unless there's an attack hitting the validation server.

It happens in waves.  I remember 2011 when the Simplecoin frontend for pushpool came out and we had a new pool every week for a while.

Not sure on the name, but it's definitely a standard template that's floating around out there that a significant number of altcoin pools have been using.  Not just bootstrap, but the entire design (and database schema/pool software config I believe).

Eventually those little pieces are going to separate from "usable" Bitcoin amounts when you spend your BTC on something.  This wouldn't affect people who just cash their entire balance out to an exchange, but anybody who actually USES Bitcoin is unlikely to be spending amounts under 0.0000x.  Some sites might go all the way to satoshis, but that is pretty rare (outside of gambling sites).

Over time, you can attempt to consolidate those little dust outputs by sending them along with larger amounts to attempt to avoid fees, but all that does is bloat the blockchain even more than it already is.


The pool offers users the choice of convenience (auto payouts) or precision (manual payouts).  I do not want the pool to make contributing to blockchain bloat part of the convenient option.

Correct.  Automatic payouts are (obviously) designed assuming you're continuing to mine.  As such, filling your wallet with unspendably small amounts makes no sense for the user (it will eventually cause you to pay extra tx fees).

Manual payouts are there for users who want full withdrawals, or users who want to leave the pool, allowing them to have a complete liquidation of their balance.


Support -> How Am I Paid?  covers both withdrawal methods.

Manual payouts are full precision to the last satoshi.  Only automatic payouts are cut off after to 0.0x amounts.

Just to clarify shifts/share counts:

BTC Guild's shifts are cut off at a certain # of shares.  It's not a precise cutoff due to just how fast they come in, but at this time the cutoff is whenever the In Progress shift has 2,500,000,000 shares in it.  It will normally be 2.51-2.52b shares by the time the script officially records the shift.  This slight variation is factored in when blocks are rewarded so there is not any kind of penalty for a shift having slightly more or less shares.

The # of shares in a shift is manually increased, generally around the time of a difficulty increase, or alternatively when the pool sees a large increase in hash rate.  The target rate is that shifts are more than 40 minutes, less than 60 minutes, that way the PPLNS system fully matures (closes) shifts in under 10 hours.

===

When the pool is speeding up (which is almost always happening), you will generally see your share counts decreasing per shift each day, unless you're adding more speed to keep up with the pool growth.  This happens because the shifts finish faster.  It has no affect on your payout, since you're completing more shifts in the same amount of time.

When the pool adjusts the shift size, that's when you'll see an increase in shares per shift.  Again, just like when shifts speed up, it has no direct impact on your payout, you now have more shares per shift but complete fewer shifts in the same amount of time.

===

The target rate of 40-60 minutes was decided on because it keeps the average blocks per shift (at neutral luck) at more than 10 blocks.  This number was chosen because the likelihood of a 10x difficulty block is *extremely* rare, meaning it's virtually impossible for the pool to have a shift that goes completely unpaid due to lack of block solves.  It also means the per share variance is reduced significantly compared to PPLNS pools that use a much lower 'N' value.  24-hour variance for a consistent miner really doesn't matter what the 'N' value is, but per-shift variance is what users tend to gauge the most, so keeping that as consistent as possible is the goal.

There's no chance of a Low Hashrate warning, the amount of calculations that would require is SIGNIFICANT since the pool does not actually track worker hash rates, only their shares over a certain time frame.  This may change in the future if I find a way to integrate hashrate tracking in the backends, but there are major problems with trying to do that when it comes to the same worker being present on multiple backend servers.


Also:  Fun fact...BTC Guild is around 23% of the network hash rate and just found 8 blocks in a row on the network.  This is after having a day with relatively terrible luck including multiple 2.5+ hour blocks.  Yay Variance!

Sigh...another person who doesn't understand the difference between GetBlockTemplate and GBT pools.  GBT does not give users voting power when used in any pool as they exist today.  At best they give a window into the transactions (at the cost of using hundreds of times more bandwidth compared to Stratum), but they do not actually give users ANY control over the contents of the blocks provided by the pool.