Very nice work, Streblo!

Thanks, this pool math is really interesting to me because the results are sometimes bizzare!

edit: Streblo!

I love the explanation. And I'm adding ppln.

Sounds good. Remember, the quick'n'dirty method with the factor of ~2 for shares adjustment only works with M=0.5. Though, I (or anybody with the mathematica link) can easily calculate numbers for arbitrary M.

Amazing streblo. Really great stuff.

The thing I'm still unclear on though (and maybe I'm just dense) is:

Based on your analysis, given the situation of hopping two pools having different speeds, should I stay with the faster pool even though it is further from share 1 and then hop to slower later. Or do I hop to pool 2 immediately after it solves a block. It seems to me the downside is getting stuck in a slow pool and missing the spread of shares to other available pools ( even backup)

Assuming you switch pools with no increase stales and you have accurate round_shares information, ALWAYS send shares to the pool with least number of shares (unless, of course, all pools are above x=.428, in which case you should solo mine [read: use a "backup" pool]).

nice work streblo, just managed to put my concepts straight thanks. I added you on my future donations list if you don't mind

Thanks man!

Although this should REALLY go in a seperate topic... What's your understanding of PPLNS?

I got it like this, that you _always_ consider the last N shares and don't reset at block boundaries. Yes, this means you can get paid twice or more often for a single share but also that you can be not paid at all for some others. I suspect you do in your model reset your shares when a block was found. Is this true?

Hmm, should I start another topic? I started a similar thread in Mining->Pools, but that is more for a new payout system which I call normalized Proportional Payout (nPP), which is almost identical to proportional, except it cannot be exploited by hoppers.

I don't see how his model could include anything from previous rounds - I think it resets at boundaries. That just means the model gives a low bound for speedup/efficiency.

I'd really like some details (that i probably won't follow!) though. Or at least more details about

PPLNS strongly deviates from proportional only during rounds which pay (per share) below the statistical average. Because the hopper "suffers" from PPLNS only during sub-par rounds, the absolute difference between proportional and PPLNS is small.

because it's tantalising me. I'd like to know why the gamma functions allow us to model the PPLNS behaviour.

You are correct, this analysis resets at the pools found block boundaries. I could run Monte Carlo simulations of the PPLNS system, because handling multiple payouts per share (technically, upto N times!) would be quite difficult, I suspect.

Yes, this analysis does include reseting shares after the pool finds a block (not when the system finds a block). Whoops. I don't included: multiple blocks found per share or the decreased payout from including the last N shares (including previous round(s)). These effects work in opposite directions, although I don't know which one is stronger.

PP expectation value was calculated by taking the payout (1/(n+x)) multiplied by the distribution of number of shares (x) required to find a block, and integrating over all possibilities.

n shares are already submitted

the payout after x more shares are submitted (1/(x+n))

probability of a pool solving a block after x shares = exp(-x)

PP = Integrate exp(-x)/(x+n) from x=0 to Infinity = exp(x) E1(x) = exp(x) Gamma(0,y) (this is the incomplete gamma function)

PPLNS (when incorrectly resetting shares after every block)

n shares are already submitted

the payout after x more shares are submitted: 1/(x+n) (x < M)

PPLNS = Integrate exp(-x)/(x+n) from x=0 to M = exp(x) ( Gamma(0,x) - Gamma(0,M+x)) (x < M)

Cheers

1FQoC3zsos22QxZC35fMfP8JteMK9nEQPU