Bitcoin Forum

(Updated November 17, 2011)

I have completed my Analysis of Bitcoin Pooled Mining Reward Systems (https://bitcoil.co.il/pool_analysis.pdf).

This document analyzes the foundations of mining pools and explores the various reward systems in existence, as a resource to anyone who would like to know more about the subject. It includes both discussion and mathematical results, some of which I have already haphazardly posted around the forum.

It is technical, though it is my intention that it will be approachable to everyone. Any feedback is welcome, and there used to be a bounty (https://bitcointalk.org/index.php?topic=52113) for helping improve it.

If you're looking for a more concise overview, also available is Summary of mining pool reward systems (https://bitcoil.co.il/pool_summary.pdf). There are also slides (https://bitcoil.co.il/Mining%20Pool%20Reward%20Methods%20(San%20Jose).pptx) prepared for the San Jose conference.

Enjoy!


Table of contents:

1 Introduction
1.1 Bitcoin and mining
1.2 Variance of solo mining
1.3 Pooled mining
2 Simple reward systems
2.1 Proportional
2.2 Pay-per-share (PPS)
3 Score-based methods
3.1 Slush's method
3.2 Geometric method
3.3 Pay-per-last-N-shares (PPLNS)
3.4 Score-based methods myths
4 Attempts for risk-free pay-per-share
4.1 Maximum pay-per-share (MPPS)
4.2 Shared maximum pay-per-share (SMPPS)
4.3 Equalized SMPPS (ESMPPS)
5 Advanced methods
5.1 Double geometric method
5.2 General unit-based framework
5.3 PPLNS variants
6 Attack vectors
6.1 Pool-hopping
6.2 Block withholding
7 Nonstandard reward systems
7.1 Shares as a future payment contract
7.2 Variable block rewards
7.3 Hybrid reward methods
7.4 Heterogeneous pools
7.5 Variable difficulty shares
7.6 Proxy mining
7.7 Score cashout
7.8 Score markets
7.9 Streamlined PPS investments
8 Conclusion
A Properties of proportional pools with constant hashrate
B Pool-hopping in proportional pools
C Safety nets for PPS pools
D The hopping immunity theorem
E Properties of the geometric method
F Properties of *MPPS pools
G Hashrate fluctuation pool-hopping

just write the PPLNS section now, because it is intuitively the easiest to understand hopping-proof method that doesn't penalize or reward pool-hopping since each share has the same chance of making the window (as long as the window crosses round boundaries)

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

Why is this on page 2? Probably the most valuable research paper on Bitcoin since the Satoshi document.

Still, I agree with iopq, PPLNS has a strong future esp. for new startup pools (in fact it might even be the perfect reward model)
would be good if everyone got an in-depth review on it.

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

Thanks for the positive comments. My motivation to work on this is directly related to how useful people consider it. But I have some much bigger things right now so it might take a while.

I agree that PPLNS is a wonderful method and I'll get to it. I need to write the sections in order to get the logical flow right.

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 think it is extremely useful.  There is a lot of misinformation floating around and having a thorough and transparent analysis of the various methods will help clear the fog.

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.

As far as I understood the "difficulty scored N" value, it devaluates shares (a bit) that were submitted during lower difficulty rounds if difficulty changes. This can be done with a static N as well - I don't see the need to change N at all other than to make sure the percentages of getting paid for a share are constant (if you set N to 1 million fixed and difficulty goes up to 10 millions the ration between N and difficulty goes from ~1/2 to 1/10 - meaning you are less likely to be paid for a share - but you get paid proportionally more, once one gets paid).

Any exploitability there (especially since at the end of the 2016 blocks, it's easy to estimate what the next difficulty will be) is bad in my opinion and I fear there IS some exploitation potential left, if N can change.

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.

Could you paste a link to Meni's suggestion then? I recall lower difficulty being devalueted with the reasoning that the current block (found in the higher diff.) was more difficult to find and this means that shares from a lower diff. are worth less. I could be wrong though... I don't want to say any more until I have read through the suggestion again, but I can't seem to find it.


Oh and on a side note: I'd love to have chapters markings in the document! I guess you're using LaTeX, Meni? Please embed a library to automatically create these, thanks!

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

I still need to research if score-PPLNS works exactly the way I think. But the idea is as sirky said - each share gets a score of 1/difficulty, and the fixed quantity is the total score. So you can set S=2 which means that the number of shares is twice the difficulty, and if the difficulty changed mid-round you take shares up to a total score of 2.

That discussion started here (https://bitcointalk.org/index.php?topic=27870.msg379601#msg379601).

LaTeX indeed. I've uploaded a new version, is this what you wanted?

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.

I don't understand what you are saying in the first few paragraphs. But fixed N without scoring invites hoppers. You will not get full value at the end of the difficulty in this pool. So you should hop away. This is because your extra % of finding a block at lower difficulty will not be rewarded at the new difficulty.

Basically, your work should be worth more at a lower difficulty. It isn't in a fixed N system with no scoring.

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.

I think p2pool's method isn't 100% hopping-proof, but I don't understand it well enough to be sure.

About that example, I wanted to point out that if there's 0.75 score left and the shares are 0.1 each, you use a score of 0.1 for the last 7 and 0.05 for the 8th.


You still need to tell me if the chapter marking are what you were looking for.

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.

@Meni Rosenfeld thanks for the excellent research.

Ok, how about the new version?

Perfect, thanks a lot! :)

Makes it also much easier to navigate the document, right?

One good thing about writing documentation is that when you have to explain your models, you need to think about them more carefully. And sometimes you find out that one of them is wrong.

I used to think that the existence of pool-hopping causes non-hoppers to earn, in the worst case, 70% of the normal reward. But I've now added to appendix B a derivation of this result, and it turns out my original model is wrong and it's actually 56.5%, equivalent to a 43.5% fee (and I've now confirmed it by simulation). All the more reason for miners in proportional pools to reconsider.

Still looking forward to seeing more of this. I especially hope you go into the caveats of handling difficulty changes properly with each system.

I'll get to that too, eventually. But my already busy schedule just got a whole lot busier now that I've decided to attend the NYC conference. So it will take some time.

Umm - how can you start a sentence with a fact and end it with the exact opposite of that factual statement?

You've just stated correctly that you cannot predict the future, but then said the past affects the future.

Simplest link to verify it: http://en.wikipedia.org/wiki/Gamblers_fallacy

I'll put it this way:
Once you have mined n shares, there is absolutely no change in the probability of finding a block in the next share than there was in all of the previous shares back to the first.

Secondly, regarding your copy of Roulo's suggestion that pools that pay based on share% mined are affected detrimentally by hoppers
(or: hoppers make more BTC by hopping)

Let me use the simplest way to disprove a theory: An example that fails the theory will show it to be false.

Take this statement from Roulo's document:

Thus stating that from 43.5% to 100% (λ = 1) there is a gain between 28% and 22%

Yet a simple example with 50% shows this to be false:
If you mine with a share% of 10% at a site for 50% of the expected time to find a block, then, your shares will be worth on average 5% instead of 10% (since your % will slowly drop, after you leave, to 5% (on average) until the block is found)
During this time you can go to another pool with the same hash rate and do the same thing ... and thus get a total of 10% (5% from each) ... which is what you would have got to start with - not anywhere near 20% extra ...

No he didn't. He said the past affects your estimation for the future.


That is true. It is also obvious, which is why nobody is disputing it.


"a gain between 28% and 22%" - going from 28% to 22% is a LOSS, not a gain.


This is not correct. You cannot use the average number of shares (from any point) needed to find a block to determine the average length of a round from the start of the round given that the round is already in progress. This is the obvious point you made earlier.

What? If a round already has two million shares, and difficulty is two million, your estimate for the round is that it will be four million shares. The two million already mined are important.


True


What? This isn't true at all. Statistics is not high school science. A single counterexample proves nothing. We are talking about what should happen over large timeframes.


I have no idea what you are trying to say here. But I am positive it doesn't make sense, because it is an indisputable fact that you make money by hopping proportional pools.

Let's say there are two pools, one with 0 blocks mined this round, and one with 10 million blocks mined. You are claiming it doesn't matter which one you mine.

If you are going to be 10% of the hashrate of each pool, and difficulty is 2 million, in theory if you choose pool A, you will make 200000 / 12000000 * 50  = .83 btc

If you choose pool B you will make 200000 / 5000000 * 50 = 5 btc.

Go back to my first point. That seems to be what you don't get. The number of blocks mined already does affect the average number of blocks that it takes the solve a block this round.

I might have to reword this sentence in a way which is less dramatic but also less ambiguous.

What I meant is that, if a future event is random and independent of the past, you can't predict it better than the prior probability.

But if the event is not independent of the past, you certainly can improve upon the prior.

"Number of shares remaining until round end" is independent on the past. "Eventual total number of shares at the end of current round" is certainly dependent on the past. At round start, "probability that the round will have >3D shares" is 5%. If 2D shares have already been found, this probability is 37%. If 2.9D have been found it's 90%, and if 3D or more have been found it's 100%.

And, pertinently, the eventual total number of shares at the end of current round (denoted N) is what matters, since your payout for every share you submit is B/N. If E[B/N] is less than what you could get per share elsewhere (which is B/D), you should mine elsewhere.

And I'll repeat the simple example - if 2D shares have already been found, then necessarily N>2D so E[B/N] < B/(2D), so you want to mine elsewhere.

So, if I say something which is true, and which was already said before many times, and I'm properly citing an influential paper about it, redoing the calculations myself and adding calculations and results which were never published before, then I'm "copying"?

You'll have 5% of the shares. You'll have more than 5% of the reward because you will have more shares in short rounds than in long rounds.

Very nice so far. Can't wait to read the finished paper.
Thanks!

Kano, I think you're confusing efficiency over one round with efficiency over many rounds. Your example only works over one round, or many rounds where a pool finds a block at the exact same difficulty level.

The whole point to pool hopping is that with the type of random number we deal with here and a proportional payout, there is a way to maximise your payout by leaving early. The reward for shorter rounds will over time be greater for those who leave early than for those who leave later or not at all.

Take the extreme example of a pool hitting a 10x difficulty block. You don't know this will happen, but if you hop off even at 1*difficulty, you might have had 9 rounds worth of other PPS payouts by the time the round at the original pool starts again. You've submitted the same number of shares as you would staying at the original pool, but ended up with a much greater reward. The same applies to a less extreme example - even if the pool hits a 2*difficulty block and you hop at 1*difficulty, you'd get a full rounds worth from PPS.

The real mind twister for me is that even without hopping to PPS, even if you turn your miners off at some arbitrary hop point before then end of a round, efficiency for the submitted shares will always be better than 1.0 in the long run. In the short term, variability can hide this, though.

Hope that helps.

Not really that surprising. The expected gain per share decreases with the age of the round. If you stick through the whole round (and there are no other hoppers) the efficiency will be 1. So if you leave early, even if this "early" is pretty late, you'll always get more than 1.

I haven't made much progress with this lately, partly because I was too busy inventing a new reward system (https://bitcointalk.org/index.php?topic=39497). But I hope to be able to resume work soon.

Yeh, hyperbole is not really my strong point.  :P

I've added a section and appendix about PPS, thus completing chapter 2.

Due to real or perceived demand, I've written a complementary paper Summary of mining pool reward systems (https://bitcoil.co.il/pool_summary.pdf).

All this math is way over most of our heads ( at least mine)

But the 2 simplest reward systems -PPS and Proportional are Implemented very nicely
by two of the bigger pools.

BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof. (Basically possible on fast pools only)
ARSbitcoin  and their SMPPS seems to be very good  and so far has  "survived " having a negative Buffer for short periods.

I doubt that, hoppers are just too lazy to hop it properly.

Patience, it will collapse eventually (unless something happens to the pool due to unrelated matters first).

It's true. You can still hop it in exactly the same manner as before, it just is less effective. To make proportional hopper proof you need a delay that is longer than a round could ever conceivably be.

Actually, I was thinking about hopping without using the pool's published stats at all. When a block is found on the network which is not by any of the transparent pools, assign a certain probability to it in being from each of the delaying pools based on their hashrate. Calculate expected efficiency for such pools based on these probabilities. When efficiency is higher than other pools mine there (this will usually be when several hidden blocks are found in a relatively short time).

And that's without using technical methods to figure out block origin, of which I know very little (something to do with network traffic, long polling, etc.)

Well, one could delay the stats by 3 hours which on BTCguild would cover the majority of rounds(at this difficulty)
but since there are very many rounds in the area of an hour  it basically keeps most hoppers away.
Maybe if/when there are no more other good PP pools the hoppers would work harder and try to hop there as well.

I read your predictions about ARS and the negative buffer a while back.
I guess it all comes down to luck and patience of the Users.

or maybe Burningtoad  will change the system before it happens as he said he might.

This falls under the scope of "something happens to the pool". Doesn't have to be a bad thing! I recommend he uses a hopping-proof method.

This is sort of what I've attempted to do with poclbm-autohop (there's a thread about it in the mining software forum). The only thing that's ultimately pulled directly from the pools is the list of solved blocks. The biggest problem is that it relies on an API I compute on my own machine and update online when it changes. This makes me (and my computers) a major point of failure.

Actually, for each block that could possibly be each pool's last block, it calculates the expected efficiency if that block, and then does a weighted average of the efficiencies over all possibilities for the latest block.

Results from BTC Guild suggest that it works relatively effectively, but collecting enough data to be sure (or automating the data collection) is more work than I have yet wanted to do. Also, the system would have to be modified to handle hopping a pool that doesn't report any of its blocks.

In short: stat delays make hopping slightly more difficult, but they won't eliminate the problem, especially as techniques such as this become more common in the various hopping softwares.

bitHopper allows hopping using LP. It has been successful for me. Almost on par with normal prop pools, and better than using btcguild with the delay.

Meni, nice work on Slush style pools. I've almost finished a blog series looking at Slush and score from a simulation pov, and I got qualitatively the same results as you. Always nice to see someone explain clearly what a simulation shows. Another thing I noticed was that although too low a 'c' increases variance greatly, the expected payout for submitting at share at any time approaches 1.0 as c decreases. My explanation was that as c decreases for a given hashrate, reward and variance approache solo mining. Correct?

Also bitcoinpool (and I think polmine, not sure) recently decided to do a 'tax' on pool hoppers by still scoring proportionally and then taxing pool hoppers - by 50% for bitcoinpool. I'd like to see an analysis of this if you have time - and if you think it will become a common idea amongst pools. Simulations just show a reduced hop point and reduced efficiency for the round compared to proportional but still much better than a slush scored pool with any c value under 800 (for 1820 Ghps).

Thanks again for the hard work you put into this paper.

Exactly. Basically when c=0 each share is infinitely more valuable than the last, so only the winning share is rewarded, which is essentially solo.

I hope this ugly, unfair patching won't become popular. I might write about it at some point. How do they determine who is a hopper?

They define the system as follows:


And yes, it's an ugly system, and still fails. If they wanted something still proportional with fairly low variance they could have used Slush's score with a large 'c'. Instead the system is designed to seem fair to full time miners, but still leaving quite a hole for hoppers: ~ 2.0 efficiency per hopped round, and hop point of 0.23* difficulty.

I think it might become popular because of its seeming fairness. I'm hoping it won't though. I got a post out on it rather quickly  (http://hoppersden.info/content/5-How-to-hop-3-the-50-50-tax)and I'm hoping a few miners will understand the pointlessness of a 50-50 tax.

How do they define "participate"? Assuming that, as written here (http://bitcoinpool.com/forum/viewtopic.php?f=1&t=103), they take the time between first and last shares, this is completely idiotic. You can stay all the way to 43%, and just submit a share once in a while to maintain >50% span. If you've mined for an hour, you need to submit a single share one hour later, then 2 hours, then 4, until the round ends. (You always submit a share a few minutes before twice the time of your last share).

Yes, and there was a proposal on the bitHopper forum about enabling 'trickle mining' to do exactly that.

pool.itzod.ru had a similar tax system, which apparently got quite complicated in order to close loopholes like that one. They are reoprtedly PPLNS now.

I find the apparently anti-intellectual stance the tax system implies to be a bit odd for a pool op - you can't just decide, "We decided on 50% as the supposed benefit from pool hopping would be only an additional 30% income" (http://bitcoinpool.com/forum/viewtopic.php?f=1&t=103#p648) based on incorrect facts and a lack of knowledge. Even more recently (https://bitcointalk.org/index.php?topic=14133.msg514928#msg514928) the pool ops show a lack of knowledge about the basic facts of mining.

On an unrelated but still topical subject, do you know if anyone ever proposed a dynamic c for Slush scored pools? Both BTCMine and Slush's pool have had about 25% reduced hashrates recently and I wonder if fulltime miners will get tired of increased variance before they get around to changing c.

Since at share n exp(duration/c) == exp(n/(av shares per second for round*c)), wouldn't it be better to keep the average shares per second*c to a constant value? Or would a dynamic c - to keep be too hard to implement? Just an interesting thought.

They should lie down before they hurt themselves. Designing reward systems requires a clue, which they have none. Not to mention their arrogant, obnoxious attitude when discussing these matters.

Are you talking mid-round or between rounds? Between rounds, that's what I tried to suggest here (https://bitcointalk.org/index.php?topic=4787.msg90179#msg90179). The real quantity controlling the tradeoff between variance and hoppability is c*hashrate, so to maintain the same tradeoff c should be chosen inversely to the hashrate. I was told that in BTCMine, "of course decay adjusted to lover[sic] value, when pool hashrate grow.", but they didn't specify if this was done automatically.

If c is dynamically changed during the round, this reduces to just doing the right thing and basing decay on number of shares rather than amount of time.

Yes, I meant during a round and you answered my next question too.

Even if a score = score + exp(n/constant) proportional scoring would still be hoppable, I'd have thought it more stable. A score look-up table for the nth share could then be used instead of a recalculation. I think.

The geometric method is basically like slush's method but

1. With share-based decay rather than time-based.
2. With operator score to always maintain a steady state.

Each of these improvements can be used regardless of the other, and what you're suggesting is basically doing the first without the second. This is an improvement over the current slush method, but the second improvement is more significant, so if you're thinking about these things you may as well just go geometric. (Or PPLNS if you want to decrease variance and are ok with crossing round boundaries and increased maturity time).

And there's no point in a lookup table, the calculation isn't expensive, you only need to make it robust against overflows.

And a moment of satori for free. I followed your explanation on the thread but I don't think i really understood it until just then.


You're right of course - I was looking at it from a simulation pov where a table if is needed if you want to simulate 10^7 rounds worth of data in a reasonable time. But in real time, I can see load wouldn't be a significant problem.


I'm changing to using the R package Brobdingnag (http://cran.r-project.org/web/packages/Brobdingnag/index.html) which does some nifty log conversions behind the scenes so you can continue as if not using logs, specifically for very large (and I suppose very small) numbers. I think it should be a bit more cycle sparing (for me) than going for multiple precision, and less hacky than renormalising every n simulated shares.

Yeah, I tried, perhaps unsuccessfully, to get across the idea that the 1/(r-1) operator score in the method represents infinitely many shares submitted by the operator before the round starts. So at any point a miner who wants to submit a share sees behind him an infinite sequence of shares, so the competition with existing shares is always the same. That is, in the beginning of the round, the past, present and future shares look like this:
..., r^-5, r^-4, r^-3, r^-2, r^-1, (r^0), r^1, r^2, r^3, r^4, r^5, ...
10 shares into the round, it looks like this:
..., r^5, r^6, r^7, r^8, r^9, (r^10), r^11, r^12, r^13, r^14, r^15, ...
This is exactly like the previous case, but with everything scaled by a factor of r^10 which doesn't matter. Thus the statistical properties of the payout for a submitted share are always the same.

Chapter 3 is complete.

Chapter 4 (*MPPS) is done.

Great work Meni. As readable and informative as ever. And also nice to know that the crazy huge negative buffers I seemed to get in simulation aren't a bug but a feature. Over hundreds of thousands of simulated rounds the buffers go up and down like a bride's nightie, but the time taken to get out of a negative buffer hole can be hundreds of rounds.

Starting with a very large positive buffer (say 1000 time the bitcoin reward for a block) can make it much less likely that an SMPPS pool will go in to negative buffer in the short to medium term, but the more rounds I simulate the greater the changes in buffer can be. Even if the pool knows it might go into positive at soe later point, can it survive until then?

Anyway, nice to know the reasons behind the observations. Thanks!

Yes, Brownian motion (http://en.wikipedia.org/wiki/Wiener_process) is pretty crazy but quite a lot can be said about its dynamics. For example, over a period of n rounds the buffer will change in an amount on the order of sqrt(n) times the block reward. The probability that it will take at least n rounds to recover from a negative buffer of m times the block reward is roughly (m/sqrt(n))*sqrt(2/Pi). (From which it follows that the expected time to recovery is infinite.)

The pool has no problem surviving as long as its buffer is high - in this case the distinction between it and PPS are blurred. If the buffer is currently positive but on a more earthly level, people are signing up for a pool which is by design doomed to failure (even if it will take a while for the failure to actually take place).

I'm not sure I follow this - if m is large and n is small, you get a large probability of the negative buffer recovering quickly. Can you provide an example for me?

The approximation only holds for sufficiently large n and m. So you can't use it directly to find the probability of quick recovery. But you can do it in reverse. For example, m=10, n=1000 gives a probability of 25.2% that it will take at least 1000 rounds to recover from -500 BTC, which means probability of 74.8% to recover within 1000 rounds. While m=20, n=1000 gives a probability of 50.4% for at least 1000 rounds, meaning only 49.6% probability of less than 1000 rounds.

Nice work on your latest edit. Still reading it and working through the math bit by bit (heh) and especially loving the appendix on hashrate increase for a slush scored pools.

Btw looked at coinotron's score system? which means the score has a maximum of exp(C) and the final pool score will be (total submitted shares)/(C*exp(C)) if you assume a constant hashrate for the pool.

It's interesting - it increases the expected share efficiency 1.0 point to about .73*D but has much lower overall increase in expected share value for that range and never gets above about 1.25 at maximum. The expected round efficiency at that point is also quite low. Also as far as I can tell it's resistant to changes in hashrate and D unlike Slush's score. A nice find, that one (plus it was easier to integrate the function than Slush's :)).

Why do people keep making up these things? There are reward systems which actually work, why not use that instead? From their site - "anti-cheating score system punishing pool-hooping cheaters" - the fact that they think pool-hoppers should be "punished" (rather than simply using a fair invariant method) or that their method does this with any effectiveness, demonstrates they don't know what they're doing.

It may be "resistant" to changes in hashrate and difficulty, but not immune. It has a different variance/hopping profile from slush's, with at least one significant disadvantage - the profitability has no lower bound for arbitrarily long rounds.

Probably should be (total submitted shares*exp(C))/(C).

Chapter 6 done.

Oops! I posted that too late at night. You are right of course.

I just noticed this thread.  Great work Meni.  This is a fascinating document.

Thanks!

I really like chapter 6.2.*. Haven't found that much information about this topic anywhere yet. Even countermeasures are described.

Awesome work Meni like always, you are a gift!

Thanks. Most of the content of section 6.2 actually goes back more than half a year (https://bitcointalk.org/index.php?topic=6577.0). PS the lie-in-wait attack was named by me and I'm the only one talking about it, but I didn't invent it, I picked it up from a comment on slush's pool's thread.

Hey Meni,

I've been going over Appendix B, the section related to the loss in earnings for full time miners. I might have this wrong, but the figure you derive fro expected share reward, 0.565..., seems only to take into account rounds that the miners can submit to - did I follow that correctly? So if we take into account all the rounds<0.435*D, then the figure I get is 0.565*(1-probability of rounds under 0.435*D)=0.565* 0.6472645= 0.3662109.

So full time miners would expect to earn as little as 36.6% of their usual reward if they were unable to submit shares in any round less than 0.435*D and can only submit (total round shares-0.435*D) in any round longer than 0.435*D.

I'm hoping I have this right, but if not could you show me where I went wrong? Cheers.

No. The efficiency is (total reward)/(total value of shares submitted). They do not submit any shares to <0.435*D rounds (by assumption these rounds take 0 time) so these rounds don't add to either the numerator or denominator.

The appendix calculates the average reward for every share submitted (by considering the reward in a random time), not for hypothetical shares which were not submitted.

Think of this. Let's say you're mining in some pool (doesn't really matter if it's a fair or proportional pool). Suddenly a Exahash/s miner joins the pool and in a split second finds 1000 blocks, then leaves. Do you lose anything from these 1000 blocks you had not chance to submit work to? No, you didn't do any work in this time and didn't get any reward, it doesn't affect you at all.

Who told you about the exahash farm I am building?  It is very efficient because the waste heat is used to generate steam for a turbine which powers the exahash farm.  ;D

True, but in the case of exahash hoppers that leave at 0.43*D, you do lose the ability to submit any shares to the very short and more profitable rounds - which has an impact on your per round earnings. Of course as you say these unsubmitted shares cannot count to an expected share value, which is what you were deriving in the appendix. What I'm want to determine - or find out if i'm wrong -  is the real world effect of the unreal  ;) exahash hopper on average per round earnings of the fulltime miners, and from there determine the effect of a finite hooper boost to hashrate. I've gotten results in simulation that agree with your expected values per share - I want to make sure my expected earnings per available round - compared to a fulltime miner at an unhopped pool - are also correct. I apologise for being unclear - it's way too late for me to be doing this.

Is what you want to calculate "average per round of the total earnings which go to honest miners"?

This has no effect whatsoever on what really interest miners, which is how much they get in relation to what they would average solo (which is 56.5%). And if you want to calculate this quantity, then it has very little to do with the calculation in the appendix. In a round of length X the amount awarded to continuous miners is B * max (1 - (0.435*D)/X, 0)). Calculate the average of this over an exponentially distributed X and you'll get your answer.

I too have just found this thread.

I have gotten irritated lately by folks promoting/attacking payout methods and/or pools without providing any or few objective facts.

I had since been hoping someone knowledgeable would start a thread for each payout method and attempt to explain them from the purely objective standpoint and then, after sufficient background has been established, delve into the more subjective pro's and con's for each without trashing pools or a persons freedom of choice.

I will d/l your pdf's and review them before I jump into anymore conversation here.
Thanks,
Sam

Chapter 5 is complete. Took me less time than I expected. (Let's hope the quality isn't too much adversely affected.)

Chapter 7 is finished.

Pool ops, please pay special attention to section "Score cashout". It describes a nice pool feature which I think shouldn't be too difficult to add.

The work is now complete, but not quite finished. I might still add new content as time permits, and there's a bounty (https://bitcointalk.org/index.php?topic=52113) for helping me improve it.

Thanks to everyone who have given me their support.

Hi Meni, thanks for your great work!

I think p2p mining is an interesting subject to study.

There is now also a PowerPoint presentation (https://bitcoil.co.il/Mining%20Pool%20Reward%20Methods%20(San%20Jose).pptx) about this subject, prepared for the conference in San Jose. I had to make it fit in an half-hour slot so not a lot of material is covered.

Bumping this - soooo many new users would benefit from understanding payout methods (and more than a few wannabe poolops)

Thanks for sticvkying mods :)

I'll take this opportunity to reference the latest development in this area, Multi-PPS (https://bitcointalk.org/index.php?topic=281180.0).

There is no pool that matches this category [Equalized SMPPS (ESMPPS)] exactly. So the leaves SMPPS as the best category?
Thanks

I don't understand the question. SMPPS and ESMPPS are among the worst methods that exist.

There was an ESMPPS pool once. I don't remember its name.

I see the table is split into 2 pieces (wrapped). I misread it. My concentration is about 50/50 today.
So PPS is best category.
Thanks for throwing a red flag.

Oh, you're talking about the summary paper.

Yeah, PPS is the method with the most potential but it needs to be done right.

Bitpit. They died and took some of my coins with them.

What do you mean they died? They made a run for it, when it was at the highest.

The pool died, not its operators...

Where is CPPSRB?

Not worth spending time on. I believe it was invented / became popular after the paper was completed, and I don't update it for every new broken method. IIRC, it's fairly similar to the *SMPPS.

Weird. I thought I heard you using it as an example at the conference as a scheme which made a long term uncertainty of when you'd be paid.

I think it's something of an extreme example of making tradeoff for the lowest long term uncertainty in exchange for the higher medium term uncertainty. Kind of an odd example.  Primary argument I have against it is that the high medium term uncertainty kinda stinks.

I didn't mention CPPSRB except perhaps in the context of the list of pools and their methods in the end; and I didn't use the term "long-term uncertainty". Of course, this doesn't contradict the statement that it is newer than the paper; the paper is 2 years old.

The closest thing I can think of is in the reward method triangle, I've probably mentioned that PPLNS can achieve any tradeoff between variance and maturity time.

The main problem with CPPSRB, as with all other methods that I refer to as broken, is that it is not hopping-proof. The hoppability is low, but still exists.

So...what pools would you use?  What's PtoPool???

P2pool is a p2p pool. As far as reward methods go, I would use any pool that has a hopping-proof method.

What's a hopping proofing method and which pools offer it?  I tried to look on the wiki forum...but it doesn't say anything about hopping-proof.

PPLNS, PPS, DGM. If you want more details, it's all explained in the paper linked to on the first page of this thread.

I do wish p2pool used DGM, but PPLNS is a decent method. :)

Very informative post.

Great helpful

Thats because its misspelled, it should read hoping-for-profit. :)

^^ you are asking for a document that is over 7 years old...
Very safe bet that most of the information is obsolete. Most of the pools running today were started long after that was written and the mining landscape has drastically changed since then.

Kudos for knowing how to search (and found this) though!

Look at https://bitcointalk.org/index.php?topic=104664.msg1146108#msg1146108 at the top of this section. That is the most up to date info on pools running today.