PPLNS

[Meni Rosenfeld]

It doesn't help if N is chosen to be a given multiple of the difficulty at the time a block is found. If the difficulty is about to increase, it is more profitable to mine a short while before. For example, if N is set equal to the difficulty D, a share submitted D shares before the increase will be paid the full expectation in the D-window, and then when difficulty increased it will once again go inside the window and have more expected reward.

I am new to learning bitcoin mining, but I don't get your statement above: If N is set equal to D, then on average the window will just cover the round, so on average there will be no overlap.

That statement refers specifically to a change in difficulty at a roughly known future time. After the difficulty increases the retrospective window get larger, since it is a number of shares equal to the current difficulty.

[1715519022]

1715519022

[1715519022]

1715519022

[irrational]

The correct method is as follows.
1. Choose a parameter X, which represents multiples of D to include in the window when difficulty is static. X=2 is a good choice.
2. When a share is submitted, assign to it a score of 1/D, where D is the difficulty at the time the share is submitted.
3. When a block is found, pay (sB)/X for the last share (the one before the winning share), where s is the share's score and B is the block reward. Continue backwards, paying each share based on its score, until you reach a share which brings the total score of the shares counted above X. Pay that share the amount (sB)/(tX) * min (r,t), where r is the score required to bring the total to exactly X and t is the score of the winning share. Don't pay any older shares.
4. If the pool has just started, and a block is found before there are shares totaling a score of X, there will be leftover rewards and it should be decided what to do with them. It doesn't matter much, but I recommend that the operator keeps them (in a macroscopic view, if the pool ever changes, this is compensation for the funds needed to cash participants out). Other options include donating to charity, or distributing among the miners.

How does this (specifically steps 2 & 3) change when a pool fee is involved? Is B simply reduced by the fee amount (e.g. B is only 99% of what it otherwise was in a 1% fee pool)?

[Meni Rosenfeld]

The correct method is as follows.
1. Choose a parameter X, which represents multiples of D to include in the window when difficulty is static. X=2 is a good choice.
2. When a share is submitted, assign to it a score of 1/D, where D is the difficulty at the time the share is submitted.
3. When a block is found, pay (sB)/X for the last share (the one before the winning share), where s is the share's score and B is the block reward. Continue backwards, paying each share based on its score, until you reach a share which brings the total score of the shares counted above X. Pay that share the amount (sB)/(tX) * min (r,t), where r is the score required to bring the total to exactly X and t is the score of the winning share. Don't pay any older shares.
4. If the pool has just started, and a block is found before there are shares totaling a score of X, there will be leftover rewards and it should be decided what to do with them. It doesn't matter much, but I recommend that the operator keeps them (in a macroscopic view, if the pool ever changes, this is compensation for the funds needed to cash participants out). Other options include donating to charity, or distributing among the miners.

How does this (specifically steps 2 & 3) change when a pool fee is involved? Is B simply reduced by the fee amount (e.g. B is only 99% of what it otherwise was in a 1% fee pool)?

This will be applied when the payment is calculated. If the fee is f (e.g., 1% fee is f=0.01), the amount to pay for a share will be (1-f)*(sB)/(tX) * min (r,t).

[baristor]

the cex io guys deffered me to this link when asked why im having negative balance for holding 1gH/s

[-ck]

the cex io guys deffered me to this link when asked why im having negative balance for holding 1gH/s

And that's bullshit on cex's part. PPLNS is a pooled mining reward system which you cannot possibly have a negative balance. You have a negative balance for buying a rip off cloud mining service which gets its "income" from a pooled mining reward.

[Meni Rosenfeld]

the cex io guys deffered me to this link when asked why im having negative balance for holding 1gH/s

And that's bullshit on cex's part. PPLNS is a pooled mining reward system which you cannot possibly have a negative balance. You have a negative balance for buying a rip off cloud mining service which gets its "income" from a pooled mining reward.

I agree.

[aurel57]

the cex io guys deffered me to this link when asked why im having negative balance for holding 1gH/s

Now you know what kind of people your dealing with...

[kano]

the cex io guys deffered me to this link when asked why im having negative balance for holding 1gH/s

Now you know what kind of people your dealing with...

... "what kind of people" a sizable % of the network (>10%?) of people are silly enough to deal with ...
It's actually quite astounding that so many people do, and even before when this was already obvious, that a much higher % were.

[RandoMiner]

Heya everyone,

thank you very much esp. Meni Rosenfeld for explaining the PPLNS method in great detail. Maybe someone here can shed a bit of light to a little detail:
I am trying to implement the scheme and therefor have consulted this thread and re-read it numerous times.
Also I have studied the source code of some open source pools. I am pretty much sure to have understood it, but have found different implementations, and am in doubt especially about to how to understand the boundary conditions.

My main question still is - how to treat the "last" (oldest) share - meaning the one which brings the Totalscore > X.

a) let r become negative and include this share into the payment.

b) stop 1 share before - at the "last" share where Totalscore <= X.

After studying a lot I came to the following conclusion (method b) and would like to sum up and show how my understanding is, in one post so to say. It maybe help others, and would like to ask for comments if everything is correct.

Therefor I prepared an example with 10 shares, and easy to calculate numbers.
The following mini spreadsheet visualizes what I mean:

https://pasteboard.co/IlbdR2U.png

Boiling everything down, it looks like a very simple pseudo code:

Code:

0. TotalScore = 0, X = 2, B = Block.Reward


1. Calculate score of Winning share: 
	
	s = Share Diff / NW Diff and remember as t


2. Do WHILE TotalScore < X
      
      s = share.Difficulty / network.Difficulty

      TotalScore += s

      r = X - TotalScore

      Payout = (s * B) / (t * X) * min(r, t)

      TotalPayout += Payout

      share.Next()

What do you say - is that a correct PPLNS implementation?

Thank you very much!

Randominer  

[kano]

PPLNS has no scoring.

Each share has the same value per difficulty, you just add up the total difficulty of a miner's shares and divide it by the total difficulty of all the shares used for N to get their % of the total reward.

[RandoMiner]

Thank you kano, appreciate your answer!

I am using Mendis terminology. His "score" is the "share diff" / "NW diff" - just wording stuff.

Good to hear a confirmation of how PPLNS is supposed to work - in the end quite simple

--

I was going after his various enhancements which he updated in this OP.
There he indicates to have a solution for some extreme on the edge cases, where I try to get my head around.

So I should rephrase my final question - then would be - if I correctly implemented the "Mendi Rosenfeld Windowed PPLNS" method
I figured btw - payouts of his method are different - as PPLNS in your description always pays out the exact Blockreward.
Mendis method has  variance in there.

Thx & Cheers!