4.3 Slush's score method and miner earnings part 2

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 fulltime miner hashrate: 1600 Ghps
Current pool hopper maximum hashrate: 3220 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: Good
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.0 Introduction

In the last Neighbourhood Pool Watch post on Slush's score method and miner earnings, I explained how strategic miners earn less from Slush's exponentially scored proportional reward system, and that the maximum theoretical fulltime miner earning loss to pool hopping miners would always be less than the maximum theoretical fulltime miner earning loss to pool hoppers at a standard proportional pool - but only when ignoring the hashrate increase due to pool hoppers at the start of a round. In the Neighbourhood Pool Watch post on Bitlc.net, I derived a method for calculating the real world loss of fulltime miner earnings due to pool hoppers rather than just the theoretical maximum. 

In this post I will be applying this to Slush's score method to calculate the estimated loss of earnings for fulltime miners at mining.bitcoin.cz.

Recalling from  Neighbourhood Pool Watch 6.1, the earnings for fulltime miners in terms of the expected earnings for a share submitted to a standard proportional pool is:

(exp(x) * (x * y * E1(x) + y - 1) - y) / (exp(x) * (y - 1) - y) . . . 1.

where

x = shares already submitted to pool in round as a fraction of difficulty,
y = pool hopper hashrate / (average hashrate up to "hop point")
f(x) = the expected earnings from shares submitted to rounds longer than the "hop point"

For a pool using Slush's score method,  this becomes:

(exp(x) * (y * slush.f(x) + y - 1) - y) / (exp(x) * (y - 1) - y) . . . 2.

From Neighbourhood Pool Watch 4.2, slush.f(x) is:

slush.f(x, p, H, c) = expected share value * exp( -x ) * c * H * p * ( 1 - exp( -x/( c * H * p )))

where 
x = total number of shares submitted to pool / difficulty at "hop point"
p = 1 / Difficulty
H = pool hashrate, in shares per second
c = Slush's constant


Because the pool hashrate affects both the expected share value and the proportion of shares submitted by pool hoppers, slush.f(x, p, H, c) becomes:

slush.f(x, p, H0, H1, c)
= expected share value * exp(-x) * c * H1 * p * (1 - exp( -x/(c * H1 * p)))

where

x = total number of shares submitted to pool / difficulty at "hop point"

p = 1 / Difficulty
H0 = Maximum pool hashrate: pool hoppers + fulltimers, shares per second
H1 = Pool hashrate: fulltimers, shares per second 
c = Slush's constant


So in order to determine the loss of earnings for a fulltime miner at a pool using Slush's score method, we need to know the "Hop point" x, the current mining difficulty D, the maximum pool hashrate with pool hoppers and the average pool hashrate due to fulltime miners only,  and Slush's constant 'c'.

It's interesting to note that although H0, the max(pool hopper + fulltime miner hashrate) lengthens the "hop point" and increases the expected value of a submitted share up to the hop point, the maximum possible fulltime miner earnings loss is only determined by slush.f(x, p, H0, H1, c).  The rest of equation 2 is determined only by the hop point, x, which is determined by H1, the fulltime miner hashrate. We might intuit that increasing H0 would move the fulltime miner loss toward the maximum.


2.0 "Hop point" 

In order to determine the point at which expected share values = 1, I used the the approximation I found last year:

Hop point = 0.0164293+1.14254/(1.8747*D/(hashrate*c)+2.71828)
where
D = current mining difficulty
hashrate = pool hashrate in Ghps
c = Slush's constant.

This give the "hop point" in terms of total submitted shares / D, and is accurate to within a few percent of the actual value. It is also used by pool hoppers to determine the point at which the should cease submitting shares. 

For our purposes, "hashrate" is the maximum hashrate pool hashrate when pool hoppers are present.


3.0 Slush's constant.

The last time I checked Slush's constant, it was 300 and had been so since the start of the pool. I hadn't seen anyone mention a change and I had been using c = 300 up until this point. For this post I used Navigator to check Slush's constant, and found that it had changed to c ~ 210. This has a significant effect on expected share values and makes pool hopping much less profitable, but also causes significantly more variance for fulltime miners.

Since I had published Navigator in How to hop 8 last year, I was expecting that strategic miners would be using the updated Slush's constant to determine the "hop point".


4. y, H0,  H1


As well as requiring H0 and H1 as variables, y (the proportion of pool hopper hashes to fulltime miner hashes) is also determined by H0 and H1. However the actual pool hashrate is not provided at mining.bitcoin.cz, and only the average hashrate per round can be calculated from the published pool data . 

Using a method similar to that used in Neighbourhood Pool Watch 2.2 DeepBit and pool hopping, I was able to describe an estimate of actual hashrate in terms of the average hashrate using the log-normal CDF with a log mean = 2.34 and a log standard deviation =  1.68 . I still have no definite explanation for why a log normal CDF matches the increase in hashrate from the start of a round so well, but is does provide a good model.

The plot below shows the the average hashrate per round (black points), the estimated actual hashrate (grey), and the estimated average hashrate per round calculated using the estimated actual hashrate per round in Ghps. Data are separated into the difficulty period to which they belong.

 Using this model, I found that the maximum actual hashrate is approximately 10% higher than the 90th percentile of averaged hashrate. It also appears that pool hoppers are well aware of the change in Slush's constant to 210 since the drop in pool hashrate coincides with the hop point, when expected share value = 1.

For the current difficulty period (D = 2440642.6) :

H0 ~ 3220 Ghps = 750 shares/second
H1 ~ 1600 Ghps = 373 shares/second
y = (H0 - H1) / H0 ~ 0.503

hop point ~ 0.136

5. Current loss of fulltime miner earnings 

Now we have sufficient information to determine the current loss of earnings for fulltime miners at Slush's pool. Since we know that pool hoppers are leaving at the correct hop point, we know that in  slush.f(x, p, H, c)  the expected share value = 1, so:

slush.f(x, p, H, c) = 1 * exp(-x) * c * H1 * p * (1 - exp( -x/(c * H1 * p)))

= exp(-0.136) * 210 * 373 * 4.1e-07  * (1 - exp(-0.136/(210 * 373 * 4.1e-07))) 

= 0.028

So the current loss fulltime miners is:

(exp(0.136) * (0.503 * 0.028 + 0.503 - 1) - 0.503) / (exp(0.136) * (0.503 - 1) - 0.503)

= 0.985

This means that - even in the presence of such a large number of pool hoppers - fulltime miners at Slush's pool are earning 98.5% of what they would earn at a fee free PPS pool. By comparison, fulltime miners at a standard proportional reward pool with the same proportion of pool hoppers would only earn 82.8% of PPS.

If reducing Slush's constant 'c' makes pool hopping less profitable, why not reduce it further, or make it fractional? Apart from the scaling issues this would bring for the score, it would increase the variance experienced by all miners, but especially for fulltime miners. 

I plan to investigate the increase in variance caused by Slush's score method in 4.4 Slush's score method and miner earnings part 3.   

6. Conclusions

• Slush's constant has changed to ~ 210. This has reduced the "hoppability" of the pool significantly. Currently, changing 'c' from 300 to 210 has reduced by half the maximum possible percent loss of earnings for fulltime miners.
• The current loss experienced by fulltime miners is (as a proportion of the expected fee free PPS reward, B/D) for current D, pool hopper hashrate, full time miner hashrate and c is ~ 98.5% of PPS, where a standard proportional reward method would result in fulltime miners only earning ~ 82.8% of PPS.
• Reducing Slush's constant 'c' makes pool hopping less profitable, but increases miner variance.

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