Pay Per Last N Shares

Jan connects his mining machine to a Mining Pool, a service coordinating miners’ work. Under PPLNS, the pool does not promise a fixed price for each accepted result. Instead, when it finds a block, it uses a record of recent work to divide the reward. Think of that record as a moving list: new results arrive while the oldest gradually drop out. Finding a block does not erase the list. The same work can therefore earn a portion of several block rewards, or leave the list before any rewarded block arrives. [1]

The results a machine submits as ongoing evidence of work are called shares. Here, a hash is a number calculated from data describing the proposed block. The network requires it to be no greater than a set target, so the miner keeps varying the data and calculating a new result. They satisfy the pool’s easier condition but usually do not qualify for a new Bitcoin block. N denotes the size of the work window being considered. In the simplest model, it means the pool’s last N shares of equal difficulty, not the last N people. Where share difficulty varies, the work must be weighted accordingly. Nor does the window itself mean a fixed number of hours: its duration depends on how quickly further work arrives. [1]

Imagine a full window containing 1000 equally weighted shares, of which 100 belong to Jan. The pool has just found a block and has 3 BTC to distribute after its deduction. Jan’s portion in this example is 100 / 1000 × 3 = 0.3 BTC. Jan contributed a tenth of the work being counted, so he receives a tenth of the reward being distributed. These are illustrative figures: 3 BTC is not a statement of the block subsidy, meaning the newly created bitcoin awarded for a block, and 0.3 BTC is not a promised daily income. By the next block, the window may contain different results and the amount available may differ too. [1]

Jan disconnects his machine for maintenance. In correctly implemented PPLNS, that does not erase work already accepted. It remains in the window and can participate in later block rewards until newer work pushes it out. It would age in exactly the same way if Jan kept mining; he would merely add more results. When he reconnects, his presence in the window gradually builds up again. Intermittent operation can produce greater fluctuations, but is not itself an automatic penalty for leaving. [1]

PPLNS distributes the outcome of actual block discoveries, so a successful pool day differs from a day without a find. How the pool includes transaction fees paid by Bitcoin users matters too. F2Pool explicitly describes this variability. Full Pay Per Share (FPPS) instead prices accepted work using an estimate that includes the block subsidy and transaction fees; Pay Per Share Plus (PPS+) may use PPLNS only for the fee portion. The service fee percentage alone therefore cannot tell Jan which outcome will be better. He also needs to know the amount to which that percentage applies. [2] [3]

A calculated portion, an account balance and a payment received in your own wallet are separate steps. Jan checks whether the block was accepted, how his portion was calculated and when the balance can be withdrawn under the threshold and schedule. Switching reward methods may not take effect immediately either. F2Pool, for example, publishes its own effective time for changes. A fair comparison must include work before the change and any later rewards from its remaining window. PPLNS removes neither the risk that the pool fails to pay nor electricity bills and equipment costs. [3] [4]

A longer window keeps work eligible for longer and spreads its possible rewards across more future block discoveries. This smooths some of the fluctuations caused by a very short window. It does not make a small pool find blocks regularly. The trade-off is a longer wait before the full outcome of past work becomes known. If a dashboard shows the expected reward for that work, it is still an estimate of future discoveries, not a fixed promised amount available for immediate withdrawal. [1]

One purpose of PPLNS is to limit pool-hopping: switching pools solely to exploit a more favourable stage of reward distribution. A window spanning block discoveries removes the simple advantage of arriving at the start of a new round. Mathematical fairness still depends on the variant. Meni Rosenfeld distinguishes simple fixed N from the more sophisticated unit-PPLNS; naive rules can be exploited when network difficulty or block value changes. Unit-PPLNS records information based on the network difficulty and block reward when each share is submitted. This lets later payouts account for the conditions under which that work was done. When changing parameters, an operator should preserve the expected value of previously accepted work. A service’s name does not prove that its calculation actually does so. [1]