4.2 Slush's score method and miner earnings part 1

Note: Information in this post about Slush's score method is now out of date. Refer to the pool's website for details on the new score method.

Pool:  mining.bitcoin.cz aka Slush's pool
Pool op: Slush
Publicly identifiable pool operator: Yes, Marek Palatinus is the pool operator.
Payout method: Exponentially scored proportional payout
Hoppable? Yes - at the moment.
Fee: 2%
Current pool hashrate: 1300 Ghps
Availability of public statistics: 

• All rounds since the start of the pool are available on request, last 1000 rounds available via API.
• Miner submitted shares not available, miner score is. 
• Current pool hashrate.
• Handy theoretical vs empirical CDF chart, based on all round since the start of the pool.
• "Daily Pool Payout" chart - limited usefulness, but interesting.

Accuracy of public statistics: 
Are public statistics likely to be reflecting actual data? Yes
Public perception of pool and pool op: Good, but there are ongoing complaints relating to the time it is taking to complete the changeover to DGM.

Should I mine here right now? Yes, although there are some drawbacks caused by the current payout method.

Should I mine here after the payout method change to DGM? Yes.

1. Why use an exponentially scored proportional reward method?

Not long after pools started to offer proportional payouts to miners, bitcointalk.org forum member Raulo produced an interesting analysis of the proportional payout method, which showed that miners could guarantee that submitted shares would always earn more than B/D (the current bitcoin reward and Difficulty)  For those interested, the link to the original paper at http://bitcoin.atspace.com/poolcheating.pdf is dead, but the paper is still available here. The paper derives a proof that showed by mining until ~ 0.43 x D shares have been submitted to a pool and switching to solo mining when not mining strategically at a proportional pool, miner earnings would be approximately 1.28 times expected. 

This sort of strategic mining or "pool hopping", as it came to be known, is a problem for two main reasons:

• If all miners leave a pool at 0.43 x D, then blocks could not be solved
• If some miners are consistently earning more than the expected amount per share by pool hopping, then miners not pool hopping must be earning less than expected per share.

Miners that do not want to earn less due to pool hoppers either move to another payment method or become pool hoppers themselves. This leaves less and less hashrate available to the pool after 0.43 x D shares have been submitted until the pool eventually can no longer solve blocks. Most proportional pools died in this manner, or changed to a different payment method.

Although this information was freely available, most miners and pools ignored it. However, forum member and pool operator Slush did take this issue seriously and devised a score system to combat the problem. By making older shares worth exponentially less, the pool hopping effect would be reduced - but, unfortunately - not eliminated. The very first pool with a non PPS and non-hoppable payment method was, to my knowledge, Continuum pool which used Meni Rosenfeld's "Geometric method".

Currently, only eighteen months later, there are a plethora of non-hoppable bitcoin mining pools available providing Pay-Per-Share,  shift PPLNS, and DGM ("Double Geometric method"). These payment methods are summarised at https://bitcoil.co.il/pool_summary.pdf and explained and examined further in "Analysis of Bitcoin Pooled Mining Reward Systems", both published by Meni Rosenfeld. Since Slush's scored proportional payout method still allows pool hopping, Slush's pool should not be a pool preferred by miners. However, the very good service Slush provides and the regular updates on his progress toward a changeover to DGM mean that Slush's pool has retained and even accumulated hashrate.

The next three posts examine the main disadvantages of the exponential score method: loss of income to pool hoppers, and the increase in miner variance due to the scoring method itself. It should be kept in mind that BTCMine also use the same payout method, with a different "c". Any general conclusions about Slush's method also apply to BTCMine.

2. Comparing proportional and exponentially score payout methods.

Bitcoin pooled mining proportional payment methods pay a miner a proportion of the bitcoin reward, based on the proportion of the miner's shares to the total shares submitted for a round: 

Miner reward = shares/total shares * B

Slush's exponential scored proportional payment method also pays a miner a proportion of the bitcoin reward, but not as a proportion of miner shares to total shares, as a proportion of the sum of an exponential  function applied to each miner's share to the sum  of the same function applied to all shares submitted:

Miner reward = miner score / pool score * B

where:

score = score + exp ((time since round start)/c)

Note: 'c' is a constant which is currently set to 300. To check what the current 'c' is, use Navigator 3.0. Either run it using R or convert to a language of your preference - the GNU scientific library provides the lambert_Wm1 function.

Each share becomes worth more exponentially than the last, so it seems that pool hopping - which relies on only submitting shares to the early part of a round - should be prevented. However this is not the case, as we shall see later. 

How does the proportional payment method and the scored payment method compare? For a full time miner and ignoring the effects pool hoppers may have on earnings, the expected earnings are the same. However, the scoring method does increase the variability of the fulltime earnings as compared to a purely proportional payment.

Below is a simulation of the cumulative sums of scored payments compared to proportional payments for the same rounds:

This chart demonstrates significant deviations of the scored proportional payment from the standard proportional payment - a problem for miners who need to be able to rely on earnings in the short term.

This can be investigated somewhat further. By simulating earnings for a large number of rounds and recording the percentage difference in earnings between standard and scored proportional payments, we can estimate the 95% confidence interval for the deviation of earnings from the scored and standard proportional payments. The empirical cumulative distribution function (eCDF)  for the simulated percentage difference in earnings can be modeled by generalised normal distribution, with parameters calculated using a maximum likelihood estimator. The plots below shows the QQ and eCDF comparisons for the simulated results and the model. Deviation is only obvious at the extremes of the range; the model is sufficiently accurate for our purposes.

The parameters determined by the maximum likelihood estimator for the generalised normal distribution are:

      mean         sd         nu         xi 

-0.0144005  6.7436798  1.7266073  1.0368221

Using these parameters, we find the 95% confidence interval for the percentage difference between the standard proportional and scored proportional earnings:

95% confidence interval = -13.26147% to 13.67485%

This means that scored proportional payouts will vary from about -13% less and 14% more than a standard proportional payout, with mean approximately 0%.

There are two reasons for these deviations: the difference between share value expectation and share value variance for the two methods. 

3. Expected share values

In How to hop 5, How to hop 6,  and How to hop 7  I discussed why some shares have more value than others in a proportional pool, and discussed basic probability and what "expected share value" means. To very briefly recap, the expected proportional reward for a share submitted after x*D shares in total have already been submitted to a pool is:

Expected reward = mean(x*D/(rounds longer than x*D)) * B

It turns out ( and is derived here ) that for rounds with a standard proportional reward method, the value of a share in submitted after x*D total submitted shares is dependant only on x. The smaller x is, the larger the value of a share is compared to p*B, the expected value of a share. A close approximation of the share value amplification of a share submitted at x is:

Expected reward amplification = exp(x) * E1(x)

Expected reward = exp(x) * E1(x) * p * B 

where E1 is the exponential integral (n=1).

Although expected share values also vary with x for Slush's exponentially scored proportional reward method,  the fact that share proportion decays exponentially affects expected share value. Another complicating factor is the temporal aspect of the pool - the 

exp ((time since round start)/c)

part, means that share values also depend on pool hashrate and current difficulty. How to hop 1, How to hop 2, How to hop 4 and How to hop 8, discussed in detail ( and in order of decreasing incorrectness ) what expected share values were and how they were affected by changes in hashrate and 'c' ( changes in Difficulty were not covered ). "Analysis of Bitcoin Pooled Mining Reward Systems" provides more accurate information in Chapter 3 and Appendix G.

So, what do the expected share values for Slush's score payout method look like? This is a little difficult to show, compared to a standard proportional payout, since share values change with pool hashrate, D, 'c' and time since the start of the round, rather than varying simply by order of share submission as in a standard proportional pool.

We'll start by illustrating the expected share values for a proportional pool and Slush's pool. Note that to enable a simpler comparison, I have converted "time since start of round" to "Shares submitted since start of round" by changing the score to an equivalent:

score = score + exp(n/shares per unit time)/c

where 'n' is the number of shares submitted since the start of the round. 

Although the pool hashrate will probably increase as Difficulty increases to retain a particular percentage of the network hashrate, the three variables - pool hashrate, "c", and Difficulty  - are essentially independent. Thus an illustration of the changes    in  expected share values for a Slush's pool require slightly more complex charts.  

However, if we make  the simplifying assumption that the pool's hashrate is a constant proportion of the hashrate that D represents, then share values only change with D, 'c' and the time since the start of the round. At the moment Slush's hashrate is about 0.09 of the hashrate that the current difficulty represents, so we will use that value.

This simplification is for illustrative purposes only and assumes a constant hashrate. Further, it is approximately valid from D = 1e06 to at least D = 1e08; but not below D = 1e06.

In the plot below, the x axis is the number of shares submitted before the share value we wish to know, and the y - axis has been normalised so that it represents the "amplification factor" of the share's expected value, so that the expected value of a given share is the amplification factor multiplied by p * B  ( I have previously referred to this as "Share efficiency" but have discarded this term in favour of a more accurate description ).

Instead of using simulations as in the "How to hop" posts, I was able to save a great deal of time creating this chart by using derived functions. The function for the expected values of the scored proportional payout were also derived by Meni Rosenfeld, but has not been published ( although the effects of a change in pool hashrate are derived in Appendix G of  "Analysis of Bitcoin Pooled Mining Reward Systems" ). 

The so called "hop point", or the point at which the expected share value = 1.0 and after which strategic miners will mine elsewhere, can be seen to be about 0.1 x D for the exponentially scored method (for the noted variables), and 0.43 x D for the standard proportional method ( for the same D ) . The latter "hop point" is independent of anything other than the number of previously submitted shares divided by the current difficulty, and is always approximately 0.43 x D. Another difference is that the exponentially score proportional method reaches a steady state of expected share value after the "hop point", whereas the standard proportional method share values keep declining toward zero value (are asymptotic to 1/( x+1 ) to be exact.

How do expected values change with changes in hashrate and changes to 'c'? Keeping the pool hashrate simplification, the charts below show the changes in amplification to the expected share value for changes in pool hashrate as a proportion of current difficulty, and for changes in 'c'. As noted above, changes in difficulty do not affect the amplification factor unless the pool's hashrate increases compared to Difficulty, or if Difficulty is less than 1e06 ( unlikely for the foreseeable future ).

These charts are contour plots; the axes denote the independent variables and the colour denotes the dependant variable ( the share value amplification factor ). Some general trends can be observed:

• As hashrate as a proportion of Difficulty increases, the amplification factor increases.
• As the constant 'c' increases, the amplification factor decreases. This means that if the pool starts to gain a significant proportion of the networks hashrate, Slush would need to reduce 'c' to reduce the amplification factor.
• Shares submitted / Difficulty increase, the amplification factor decreases.
• The difference between maximum and minimum amplification factors is increases with increasing hashrate.

As a corollary, it should be plain that as Difficulty increases (without a change in the proportional hashrate or 'c'), the amplification factor decreases.

What does this mean for "pool hoppers"? When should they leave the pool and mine elsewhere? By equating to 1.0 the score amplification function provided by Meni and converting from time elapsed to shares submitted divided by difficulty, we obtain the a certain number of shares / D representing the point at which share values become less than 1.0.

A strategic miner wants the "hop point" to be as far into the round as possible, so she can submit as many shares as possible before that point. As Difficulty decreases, or the "c" constant or pool hashrate increase, the hop point will increase to create a greater number of amplified shares.

From the foregoing, a very serious flaw in the score method is obvious - increasing hashrate extends the hop point and increases the amplification of the value of submitted shares. Since "pool hoppers" will join the pool at the start of a round,  the pool hashrate will be increased and the reward for mining strategically will be even greater. Appendix G of "Analysis of Bitcoin Pooled Mining Reward Systems" investigates this effect more rigorously.

4. How are fulltime miners affected by "pool hopping" in proportional pools?

To determine the effect of strategic miners on the expected earnings per share of fulltime miners we first need to calculate the expected earnings per share per round for pool hoppers. In the calculations that follow, we consider all shares submitted to a pool and all earnings derived from them, not just the subset that could be attributable to a certain percentage of pool hopper hashrate. Further, this is done without reference to the type of proportional payout method used.

To do this we consider all shares and earnings from the first x / p (where p is the probability of a single share solving a block = 1 / D ) shares submitted to a pool for a particular round. Firstly the earnings and shares from  first x / p shares are split into two categories each - shares submitted to rounds shorter than the "hop point" x / p  those shares' earnings, and shares submitted to rounds longer than the "hop point" x / p those shares' earnings. If we define the variables as follows:

 For the first x / p shares submitted:

a: Shares submitted to rounds shorter than x / p
b: Shares submitted to rounds longer than x / p
c: Earnings from rounds shorter than x / p
d: Earnings from rounds shorter than x / p

, then the earnings per share for a strategic miner for a given round at a particular pool is:

(c + d) / (a + b) 

A comparison to the expected value of a share when solo mining provides the expected amplification factor and thus the expected earnings for  a pool hopper:

E(Hopper earnings) =  (c + d) / (a + b)  / (p*B) . . . . . . . . . 1.

A, the total number of shares submitted to rounds shorter than x / p is calculated by multiplying the probability of the number of rounds shorter than x / p by the number of shares in that round. We can do this by integrating the probability of a particular round occurring by x / p:

a = integral(geometric probability density function * x / p)

B, the total number of shares submitted to rounds longer than x / p  is the number of shares submitted multiplied by the number of rounds longer than x / p. Since the number of shares per round does not change, it is not necessary to integrate, so:

b = lower tail geometric cumulative distribution function * x / p

C, expected earnings from the first x / p shares submitted to rounds shorter than x / p is simple to calculate: since we are considering the pool as a whole, the earnings are the bitcoin reward multiplied by the number of rounds shorter than x / p:

c = lower tail geometric CDF * B

For D, the expected earnings from the first x / p shares submitted to rounds longer than x / p, we need to calculate the expected proportional value of those shares. To do this recall that the expected value of a share reflects only the value of a share at that time and no earlier - meaning that these shares can be considered as if submitted at x / p all at once. So the earnings of these shares can be calculated as being the expected value of the shares multiplied by the number of rounds longer than x / p:

d = expected share value  * proportion of rounds > x * B

For a standard proportional reward, this becomes:

d = prop f( x ) = expected share value  * x  / p * upper tail geometric CDF * B

And for Slush's exponentially scored proportional reward:

d = score f( x ) = expected share value *

* exp( -x ) * c * H * p * ( 1 - exp( -x/( c * H * p ))) * B

We can make this somewhat less cumbersome by approximating it using the exponential distribution, and setting lambda = 1. The numerator is then the fraction of earnings of the first  x / p shares, and the denominator the fraction of shares submitted:

( c + d ) / ( a + b )  = f(x)/(exp(x) - 1) + f(x) + 1 . . . . . 3.

Equation 3. results in a number that is the amplification multiplier for any miner that only submits shares until a given point in a round. This allows us to calculate the expected earnings amplification per share per round for a strategic miner at a standard or exponentially scored proportional pool. The chart below compares earnings amplification up to 10 * D.

The maximum possible loss to pool hoppers occurs in the extreme case of only pool hoppers being able to submit shares up to the hop point, and fulltime miners thereafter. This is the maximum amount that could be lost from expected full time miner earnings, and is calculated as follows:

( 1 - ( c + d )) / ( 1 - ( a + b ))  = 1 - exp(x) * f(x) . . . . . . . 4.

Assuming all pool hoopers leave when the expected share value = 1, the loss to fulltime miners is 0.4345 of the bitcoin reward - fulltime miners could lose a maximum of over 56% of their expected earnings. For Slush's pool, the proportion lost to pool hoppers increases with increasing pool hashrate, increasing 'c' and decreasing difficulty. Depending on these parameters, and assuming all pool hoopers leave at the point expected share value = 1, the maximum proportion that could possibly be lost approaches the standard proportional maximum loss and the minimum approaches no loss at all to pool hoppers as the "hop point" approaches zero. The chart below illustrates the maximum possible proportion of fulltime miner earnings lost to pool hoppers. 

With the current average hashrate at Slush's pool, current difficulty and current 'c' estimate, the maximum possible loss to pool hoppers is 0.41, or 4.1%, so the actual amount lost will be somewhere between 0 and 4.1% loss to pool hoppers, and will vary as hashrate, Difficulty, and 'c' vary. The actual amount fulltime miners lose to pool hoppers currently will be addressed in 4.3 Slush's score method and miner earnings part 2.

If the 'c' constant was changed to a very low number, the loss to pool hoppers would be close to zero. Why not make 'c' very lowAnd why do so many miners complain that they don't earn what they think they should for a round. These questions will be answered in
4.4 Slush's score method and miner earnings part 3.

5. Conclusions

• Expected share values decrease with increasing total shares submitted until reaching a steady state.
• The current steady state expected share value is about 0.957 and is reached shortly after the "hop point"
• Increasing difficulty or decreasing 'c' or pool hashrate reduces the hop point and thus the pool hoppers potential profits; the converse is also true.
• If ignoring the increase in hashrate caused by "pool hoppers", the theoretical maximum expected earnings loss is much lower than for a standard proportional pool; currently about 4.1% for Slush's pool as opposed to 43.4% for a standard proportional pool.

Donations help give me the time to investigate pools and write these posts. If you enjoy or find them helpful, please consider a small bitcoin donation:
12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r

Thank you to Meni Rosenfeld who supplied tools and inspiration for this post. If you'd like to tip him, I don't think he'd mind:
1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr