Looking good so far.  Looking forward to sections 3-5 as those are the the most interesting parts to me.

Excellent write up so far.  Clear and concise.  Technical but easy to understand.  I look forward to reading the rest.

I was discussing a method I'd call "PPLNShifts" via PM a while ago. It would work like this:

To make it easier for pool operators on the database calculations and to allow for potentially huge "N"s, freeze the database in "blocks" of (for example) 500 000 shares. If a block is found, only pay the shares in the last (for example) 5 "shifts" proportionally, which you already have put in a nicer and leaner database format.

|---| means a complete block of X shares
* means a block was found

|---|---|---|---|---|-*

^ these last 5 "shifts" get paid, the "shareholders" in the shift during which the block was found have to hope for another block. It's not hoppable in my opinion, as you cannot benefit from jumping in on lucky "shifts" as they only benefit past shifts.

This makes it also much easier to for example dump all 500 000 getworks + solutions + account id in a csv and put it (seeded with bitTorrent) in a public archive on the pool's website, so anyone can verify and audit all solutions. This should keep a database small enough to still function well, while having all benefits of PPLNS.
Maybe this helps to have PPLNS pools with huge "N"s (I've sometimes seen now in the forum that people think "N" means "current difficulty"... maybe also clarify that N is just a radnom number - if it is "1", it is equal to solo mining) so the "I don't get paid anything on long blocks with PPLNS!!!11112" critics can calm down.

About PPLNS I'd also like to see if it is relevant and changes expectation values that some pools implement an "N" that is dependent on (and changes with) the current difficulty. As far as I understood it, N should be a constant, not a dynamic value that changes every 2 weeks.

I am not sure what advantage your system has over traditional PPLNS. I mean, is it really simpler from the database side or from the auditing side? I mean, if you want to have estimates, they would only need to be updated every N, instead of every share, but still, this seems like overkill. Having stats update every minute, or every 5, or something else is probably easier for everyone.

Not paying out the most recently submitted shares seems like it would disincentivize people from joining? After all, they can mine somewhere else where they will be paid right away. Especially at the beginning of an N round, they are going to be theoretically N - current shares in N round + difficulty shares away from being paid. It seems that theoretically you would be getting paid sooner at a pool where the N round was almost over, so you would rather mine there. Especially when you think of small pools compared to the current difficulty. If it takes a really long time just to reach the end of N, you would never mine there since you wouldn't be paid for a long time at minimum. In regular PPLNS, you don't have this 'waiting period', so it makes no difference.

The way Meni and I have discussed N for traditional PPLNS, the N would be a factor of the difficulty, so it wouldn't change. However, since Meni suggested that the payout is score based, with difficulty as a factor, the "N" as you are referring to it would change based on difficulty.

In my opinion, having N only update sparingly (and not having it score based) is much better than a proportional pool, or something like that, but know that it does allow a bit of pool hopping around difficulty changes (you would mine at a fair pool at the end of a difficulty, and at a PPLNS pool at the beginning of a new difficulty). You need score based (which relies on difficulty) to defeat this.

You actually need to devalue the shares that are submitted at higher difficulties, not lower ones. Because it's less likely you will find a block at a higher difficulty.


There is no way to exploit the score based PPLNS system that Meni suggested. You get paid exactly what you should. What difficulty changes to does not matter, as it will be reflected in the score.

If you have constant N value (where N is shares, and not score), that is where it can be exploited. You wouldn't want to mine at the end of a round if a difficulty jump is coming up in a PPLNS pool that isn't scorebased, because you are going to be underpaid for your efforts.

Your score for each share is 1/difficulty, so a lower difficulty makes for a higher score.

A higher score, yes but on the other hand it also lowers the chance to be included in the payout.

Example: dif10 --> diff40, N=difficulty*1

diff10 shares have a score of 1/10, diff40 shares of 1/40.

Once let's say 10 diff40 shares have been submitted, a block is found.
Now we sum up 10/40 from diff40 shares and 7 (0.75 "left") diff10 shares.
The 7 diff10 shares get paid 70% of the block, the 10 diff40 shares get paid 25% and 5% have to be otherwise distributed (10 and 40 are too small numbers for this, however current difficulties still are - but increases are rarely 4-fold). Here you could even use prop. between these 17 shares (maybe also scored with these scores), put it in some kind of jackpot or whatever is fitting to your pool.


This means there are 2 different approaches to PPLNS:
fixed N --> no scoring needed, payout variance changes with difficulty
dynamic N (N is dependent on difficulty) --> scoring needed, payout variance is constant

The biggest issue I see with dynamic N, is that you can not predict how big your active database might get.
Still it might be the preferred method of miners, since you can in-/decrease variance at will at the cost of delayed payouts (it takes longer until you have the full payout in your hands).
Fixed N on the other hand might scare away random miners, as variance is already an issue for them and it only increases with growing difficulty.

In any case I would really recommend to any PPLNS pool operator to give out estimates how much can be earned per share in percentages rather than in BTC (xx% chance of not being paid, yy% chance of being paid once, zz% chance of being paid twice etc.) + a sum below and maybe even an overview how this correlates with real data already submitted. Already earned/pending amounts of course can be in BTC.

Ah, now I understood, yes, you're of course 100% correct - scoring is necessary in both scenarios.

I was just mixing the system with p2ppool's PPLNS approach, but there the difficulty of the shares themselves is also dynamic, so they factor in hash rate of the pool+ the network via this value.
In the beginning I gave an example of Meni's PPLNS share scoring, might be a bit confusingly written.

No, that's not how I meant it.

You could include a package like hyperref (http://www.tug.org/applications/hyperref/), this should by default already create clickable references to every chapter + section as well as create a pdf index in the document.