<p>You should count each share as valuable as the difficulty of the <strong>pre-determined</strong> target for that miner. If you count the actual value of the hash it found itself, either the math won't work, or you'll introduce massive variance instead of reducing it (which a pool is intended to do).</p>

<p>When you choose a particular share difficulty D, you are restricting the set of valid hashes to a set that is D times smaller than the set of valid hashes for difficulty 1. Given that each of such results is D times less likely to be found, it is fair to count it as D shares of difficulty. However, each hash is either good or not good, and each has a fixed probability of being good.</p>

<p>If you're going to use the actual hash value obtained to calculate share value, most hashes won't be valid, but those that do will introduce extra variance: some (unlikely) ones will result in a very high score, and some won't. There is no need for this: just giving each hash the same score is just as well a way of measuring their hash rate, which is what this is all about.</p>

<p>Of course, you can't let a miner choose its share difficulty after finding one: that would allow them to cheat.</p>

CC BY-SA 3.0
2013-04-29T21:23:58.593Z
This is right.  The point is, you want to reward miners for their CPU cycles, not for their luck.  The chance of mining a hash that is small enough to earn a share is constant.  If you faactor in *how small*, then you're rewarding luck.  That's not the goal, so it shouldn't be done.
Eyal
CC BY-SA 3.0
2013-03-03T22:50:05.703Z
2013-03-03T22:50:05.703Z
Pieter Wuille
<p>For discussion purposes, suppose I have an ASIC miner, several GPUs and a CPU botnet all mining with different difficulties.</p>

<p>When a share is returned to the pool, at what difficulty threshold should I consider multiplying the per-share value for that user?</p>

<p>For example if the ASIC miner returns a share that is substantially closer to the target than what a difficulty of 1 would return, should I treat that as any more valuable?</p>

<p>Am I incentivising correct behavior in a client?</p>

<mining-pools><difficulty><mining-pool-shares><pool-payout-methods>
If each miner has a different share difficulty in a PPS pool, how should I calculate and reward the relative effort of each?
makerofthings7
# If each miner has a different share difficulty in a PPS pool, how should I calculate and reward the relative effort of each?

(Asked by: username_0 on 2013-03-03)

For discussion purposes, suppose I have an ASIC miner, several GPUs and a CPU botnet all mining with different difficulties.

When a share is returned to the pool, at what difficulty threshold should I consider multiplying the per-share value for that user?

For example if the ASIC miner returns a share that is substantially closer to the target than what a difficulty of 1 would return, should I treat that as any more valuable?

Am I incentivising correct behavior in a client?

**Tags:** mining-pools, difficulty, mining-pool-shares, pool-payout-methods


---

## 1 answers

### Answer by username_1 on 2013-03-03. Score: 5

You should count each share as valuable as the difficulty of the **pre-determined** target for that miner. If you count the actual value of the hash it found itself, either the math won't work, or you'll introduce massive variance instead of reducing it (which a pool is intended to do).

When you choose a particular share difficulty D, you are restricting the set of valid hashes to a set that is D times smaller than the set of valid hashes for difficulty 1. Given that each of such results is D times less likely to be found, it is fair to count it as D shares of difficulty. However, each hash is either good or not good, and each has a fixed probability of being good.

If you're going to use the actual hash value obtained to calculate share value, most hashes won't be valid, but those that do will introduce extra variance: some (unlikely) ones will result in a very high score, and some won't. There is no need for this: just giving each hash the same score is just as well a way of measuring their hash rate, which is what this is all about.

Of course, you can't let a miner choose its share difficulty after finding one: that would allow them to cheat.

> **Comments:**
> **username_2**: This is right.  The point is, you want to reward miners for their CPU cycles, not for their luck.  The chance of mining a hash that is small enough to earn a share is constant.  If you faactor in *how small*, then you're rewarding luck.  That's not the goal, so it shouldn't be done.  

---

