Analysis of Bitcoin Pooled Mining Reward Systems

[Meni Rosenfeld]

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

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.

[1715407034]

1715407034

[1715407034]

1715407034

[1715407034]

1715407034

[1715407034]

1715407034

[organofcorti]

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?

Code:

score<-score+exp(C*time to submit share/duration of round)

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

[Meni Rosenfeld]

Btw looked at coinotron's score system?

Code:

score<-score+exp(C*time to submit share/duration of round)

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.

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.

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

[Meni Rosenfeld]

Chapter 6 done.

[organofcorti]

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

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

[mndrix]

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

[Meni Rosenfeld]

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

Thanks!

[urstroyer]

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!

[Meni Rosenfeld]

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

[organofcorti]

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.

[Meni Rosenfeld]

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.

[DeathAndTaxes]

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. 

[organofcorti]

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.

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.

[Meni Rosenfeld]

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.

[os2sam]

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

[Meni Rosenfeld]

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

[Meni Rosenfeld]

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.

[Meni Rosenfeld]

The work is now complete, but not quite finished. I might still add new content as time permits, and there's a bounty for helping me improve it.

Thanks to everyone who have given me their support.

[MyZhre]

Hi Meni, thanks for your great work!

I think p2p mining is an interesting subject to study.

[Meni Rosenfeld]

There is now also a PowerPoint presentation 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.