Analysis of Bitcoin Pooled Mining Reward Systems

[Meni Rosenfeld]

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.

Ok, how about the new version?

[Sukrim]

Perfect, thanks a lot!

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

[Meni Rosenfeld]

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.

[Aexoden]

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

[Meni Rosenfeld]

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.

[kano]

Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be.

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:

It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate.

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 ...

[asher2]

Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be.

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.

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

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.

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

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:

It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate.

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

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

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 ...

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.

[sirky]

Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be.

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.

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.

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.

True

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.

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.

Take this statement from Roulo's document:

It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate.

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 ...

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.

[Meni Rosenfeld]

Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be.

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.

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.

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)

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"?

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:

It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate.

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 ...

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.

[Bitsinmyhead]

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

[organofcorti]

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 ...

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.

[Meni Rosenfeld]

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.

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.

[Meni Rosenfeld]

I haven't made much progress with this lately, partly because I was too busy inventing a new reward system. But I hope to be able to resume work soon.

[organofcorti]

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.

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.

Yeh, hyperbole is not really my strong point. 

[Meni Rosenfeld]

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

[Meni Rosenfeld]

Due to real or perceived demand, I've written a complementary paper Summary of mining pool reward systems.

[farfiman]

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.

[Meni Rosenfeld]

BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof.

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

ARSbitcoin  and their SMPPS seems to be very good  and so far has  "survived " having a negative Buffer for short periods.

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

[sirky]

BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof.

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

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.

[Meni Rosenfeld]

BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof.

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

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.)