<p>I found the reason for this confusion myself now:</p>

<p>It was very confusing and took a while to understand, especially because this information is not easily obtainable when researching on the Internet (without already knowing the answer in order to know the right keywords - forum threads didn't help either).</p>

<p>It seems like there are algorithms, Scrypt is one of them, which use a <strong>scaled value for share difficulty</strong>.</p>

<p>Let me explain:</p>

<p><strong>For Bitcoin (which is SHA-256), the following applies:</strong></p>

<ul>
<li>A hash is a "try" to find a certain solution</li>
<li>On average, you need 2^32 (~4 billion) tries to find a valid "share" (originally this was the only type of share in existence, which has difficulty 1, but by now, all pools use shares with difficulties higher than 1, see below)</li>
<li>If the coin difficulty were 1, this would be a valid block</li>
<li>With a coin difficulty higher than 1, let's say N, on average only 1 out of N such "valid shares" (with difficulty 1) get you a valid block</li>
<li>Recap: for coin difficulty N, you need on average N*2^32 hashes to find a block</li>
<li>Therefore, a formula to know how many seconds on average it takes to find a block with a certain hashing power is "average time = difficulty * 2^32 / hashrate"</li>
<li>When mining pools are concerned, pools accept only shares with difficulty >N, and 1 share with difficulty N is counted the same way as N shares with difficulty 1 (or N/2 shares with difficulty 2*N, etc.) - that's the pool difficulty</li>
<li>This also means that with an N=2*coindiff in PPLNS, like most pools do, on average, the last "N" shares in the "PPLNS" cover 2 blocks</li>
</ul>

<p><strong>OK, so I tried to apply this info to Scrypt</strong>, because when researching things like Litecoin difficulty, the formulae I found were the same, e.g. "average time = difficulty * 2^32 / hashrate", and that on average you need 2^32 hashes to find a difficulty-one share, etc.</p>

<p>However it didn't make sense, everything was far off from what I saw on our mining pools.</p>

<p>In fact, it turned out that it was off by a factor suspiciously close to 2^16.</p>

<p>Further research and testing finally gave us the answer that <strong>for Scrypt, by convention, pools and miners scale the share difficulty value by a factor of 2^16</strong>.</p>

<p>But only the pools and the miner software (e.g. cgminer)! the network difficulty is still displayed without scaling!</p>

<p><strong>Example:</strong></p>

<p>Let's say the network difficulty is 900,000 for BCC (Bitconnect Coin)</p>

<p>In the original calculation, I would assume that it takes on average 21 hours at a hashrate of 50 GH/s to find a block (900k * 2^32 / 50G = ~77k seconds = ~21 hours), which is about right when looking at our pool.</p>

<p>However, I would then also assume that it takes a total value of shares of around 900,000 (exactly the network difficulty), however that's not true, because one AntMiner L3+ alone already submits a share with diff of ~150,000 every ~15 seconds, so I would assume that it finds a block every 90 seconds, which is of course not true (it's closer to 90 days than to 90 seconds).</p>

<p>And here is the issue: for Scrypt, <strong>share difficulty is measured with a value mulitplied by 65,536</strong>!</p>

<p>So, in fact, the "difficulty 150,000" which the pool uses with the AntMiners is <em>actually</em> 150,000/65,536 = 2.29</p>

<p>And, this means that in order to get to that coin difficulty value of 900,000, the pool needs to display a total value of shares of 900,000*65,536 = 58,982,400,000!</p>

<p>Then, everything suddenly makes sense again.</p>

<p>There are also other algorithms which use such a scaling factor. In fact, I found that the UNOMP pool software already has a file which also contains these values: <a href="https://github.com/UNOMP/node-merged-pool/blob/master/lib/algoProperties.js" rel="nofollow noreferrer">https://github.com/UNOMP/node-merged-pool/blob/master/lib/algoProperties.js</a> (look for <code>multiplier</code>). For SHA-256 it's 1, for Scrypt it's 2^16.</p>

<p>According to pieces of information scattered throughout the Internet, this was done because Scrypt is a more difficult algorithm per se, which resulted in pools accepting shares with difficulties smaller than 1, and to avoid issues with the fact that difficulties and share values could suddenly be non-integral, the whole number was scaled so that the unit "difficulty 1" now actually meant 2^(-16).</p>

<p>So, rule of thumb:</p>

<ul>
<li>Whenever you see a difficulty value in context of a <strong>miner</strong> or a <strong>pool</strong> for <strong>Scrypt</strong>, you need to <strong>divide it by 65,536</strong> if you want to compare it with other numbers like the overall coin difficulty.</li>
<li>For coin/block difficulty values (even in Scrypt), and in general for SHA-256 or X11, don't divide it. For other algorithms, look it up (for example, Blake uses 2^8).</li>
</ul>

CC BY-SA 3.0
2017-10-23T07:53:59.483Z
2017-10-23T08:25:21.010Z
2017-10-23T08:25:21.010Z
CherryDT
<blockquote>
  <p>An AntMiner L3+ submits a share at difficulty ~150,000 (which counts as a share value of 150,000 then) every ~15 seconds, so in 3 minutes, that one AntMiner has already filled the whole "N" of 900,000x2=1,800,000. That would, in reverse, mean that I would expect to mine a BitConnect block every 90 seconds on average, with one AntMiner, which is of course not true.</p>
</blockquote>

<p>I don't think that is how shares are counted. According to <a href="https://bitcointalk.org/index.php?topic=39832" rel="nofollow noreferrer">this Bitcointalk post</a>,</p>

<blockquote>
  <p>When a share is submitted, assign to it a score of 1/D, where D is the difficulty at the time the share is submitted.</p>
</blockquote>

<p>So in your scenario, when your AntMiner L3+ submits a share, that share is assigned a score of 1/900000, so its "share value" is 2, not 150000.</p>

CC BY-SA 3.0
2017-10-21T18:00:04.390Z
But that is only to compensate for network difficulty changing over tone, isn't it? And of course the answer your mention is based on bare shares with difficulty 1, so in my case it would be 150000/900000, giving 0.17, how do you get to 2 in your answer?
CherryDT
CC BY-SA 3.0
2017-10-21T18:01:57.370Z
And then how come the difficulty gets squared? This sounds strange. I mean, saying that a diff 1 gives 1/900k, and the N is still 2x900k, meaning that you need 2x(900k^2) diff 1 shares - doesn't that square there feel a bit out of place?
CherryDT
CC BY-SA 3.0
2017-10-21T18:14:00.520Z
What makes you think my answer is based on shares with a difficulty of 1? At no point in the post I linked to is difficulty of 1 suggested or mentioned. The squared is for variance (the statistical term), which is the square of standard deviation. Variance is not part of the calculation that you want to look at.
Ava Chow
CC BY-SA 3.0
2017-10-21T19:19:39.733Z
I meant that the forum post you linked is using the term "share" as "share diff 1". A share with a higher difficulty must have an equally higher value...
CherryDT
CC BY-SA 3.0
2017-10-21T19:21:13.423Z
In fact, after doing various calculations, it seems everything is off from reality by a factor of 2^16, as if N*2^16 (instead of N*2^32) hashes would give you a share with difficulty N... I don't understand yet why, though
CherryDT
CC BY-SA 3.0
2017-10-21T19:32:12.970Z
I found this now: https://bitcoin.stackexchange.com/a/11816/62320 - does this mean that pools show a scaled difficulty value for Scrypt, but for other algorithms it's different, and the block difficulty is confusingly not scaled?
CherryDT
CC BY-SA 3.0
2017-10-23T10:23:43.640Z
@CherryDT: The linked post does assume that share difficulty is 1, but that is easy to fix - instead of assigning a score of 1/D, you assign a score of d/D where d is the share difficulty. I'm not completely sure I understood the rest of your questions, but I highly recommend you read https://bitcoil.co.il/pool_analysis.pdf before starting to implement reward methods. It should either answer your questions or give you the background to ask more focused ones.
Meni Rosenfeld
CC BY-SA 3.0
2017-10-23T14:45:05.310Z
@MeniRosenfeld: Yes, true, that's what I meant in my example in my comment above. The rest of my questions is already answered by myself, see the other answer in this thread. Thanks for your link, though!
CherryDT
CC BY-SA 3.0
2017-10-21T16:36:53.807Z
2017-10-21T16:36:53.807Z
Ava Chow
<p>while my example in the following question is using the altcoin "Bitconnect", I believe it is actually a general question which fits here - if not, let me know.</p>

<p>I am struggling to understand PPLNS (I need to implement it in a pool). I know in general how the system works, but what is a mystery to me is where the N comes from.</p>

<p>I read on many places on the Internet that N = 2 * difficulty is a good value, and that this would mean that on average a miner will earn rewards from two blocks for the same shares.</p>

<p>However, it simply does not add up for me.</p>

<p>Practical example: BitConnect pool. Let's say BitConnect's difficulty is currently ~900,000.</p>

<p>An AntMiner L3+ submits a share at difficulty ~150,000 (which counts as a share value of 150,000 then) every ~15 seconds, so in 3 minutes, that one AntMiner has already filled the whole "N" of 900,000x2=1,800,000. That would, in reverse, mean that I would expect to mine a BitConnect block every 90 seconds on average, with one AntMiner, which is of course not true.</p>

<p>100 AntMiners running on our pool gave a share value of 230,000,000 in the last 5 minutes, which would have been more than 100 times the whole "N" already!</p>

<p>So something can't be right here, and I don't understand what. Should I not multiply the submitted share with the work difficulty? But then a small miner would get the same reward as a large one which makes no sense. Or is the whole Internet wrong about the 2*diff for "N", and that it's based on the assumption that it takes on average a value of shares equal to the difficulty to find a block? Doesn't sound likely.</p>

<p>On average, it takes 2^32 hashes to find a valid share at difficulty 1, right? And on average, it takes X shares to find a share at difficulty X, hence why you increase the difficulty at the pool for your miner if the miner is powerful (it will then less often submit a share), right...? But the last point starts to make less sense already, together with the fact that you need a share at difficulty Y to find a block if the currently coin block difficutly is Y... And the pool software counts a share with difficulty X the same as X shares with difficulty 1. At the end I'm left confused how it all works together and how I can arrive at a value for "N" which <em>actually</em> results in a miner getting on average two rewards for the same share...!</p>

<p>Please help me understand what is wrong.</p>

<p>EDIT: I found that all calculations differ from reality by a factor of 2^16. Then I found this: <a href="https://bitcoin.stackexchange.com/a/11816/62320">https://bitcoin.stackexchange.com/a/11816/62320</a>
This would suggest that for Scrypt, pools use a scaled "share difficulty" value by exactly that factor, but the reported block difficulty would not be scaled. This would explain everything but it's the only place I found this on the Internet (and it would mean that I need different calculations depending on the algorithm I'm handling) - can anyone confirm this?</p>

<difficulty><scrypt>
How is the "N" in PPLNS chosen? 2xDiff appears to make no sense - OR - Why are Scrypt share difficulties off by a factor of 65536?
CherryDT
# How is the "N" in PPLNS chosen? 2xDiff appears to make no sense - OR - Why are Scrypt share difficulties off by a factor of 65536?

(Asked by: username_0 on 2017-10-21)

while my example in the following question is using the altcoin "Bitconnect", I believe it is actually a general question which fits here - if not, let me know.

I am struggling to understand PPLNS (I need to implement it in a pool). I know in general how the system works, but what is a mystery to me is where the N comes from.

I read on many places on the Internet that N = 2 \* difficulty is a good value, and that this would mean that on average a miner will earn rewards from two blocks for the same shares.

However, it simply does not add up for me.

Practical example: BitConnect pool. Let's say BitConnect's difficulty is currently ~900,000.

An AntMiner L3+ submits a share at difficulty ~150,000 (which counts as a share value of 150,000 then) every ~15 seconds, so in 3 minutes, that one AntMiner has already filled the whole "N" of 900,000x2=1,800,000. That would, in reverse, mean that I would expect to mine a BitConnect block every 90 seconds on average, with one AntMiner, which is of course not true.

100 AntMiners running on our pool gave a share value of 230,000,000 in the last 5 minutes, which would have been more than 100 times the whole "N" already!

So something can't be right here, and I don't understand what. Should I not multiply the submitted share with the work difficulty? But then a small miner would get the same reward as a large one which makes no sense. Or is the whole Internet wrong about the 2\*diff for "N", and that it's based on the assumption that it takes on average a value of shares equal to the difficulty to find a block? Doesn't sound likely.

On average, it takes 2^32 hashes to find a valid share at difficulty 1, right? And on average, it takes X shares to find a share at difficulty X, hence why you increase the difficulty at the pool for your miner if the miner is powerful (it will then less often submit a share), right...? But the last point starts to make less sense already, together with the fact that you need a share at difficulty Y to find a block if the currently coin block difficutly is Y... And the pool software counts a share with difficulty X the same as X shares with difficulty 1. At the end I'm left confused how it all works together and how I can arrive at a value for "N" which *actually* results in a miner getting on average two rewards for the same share...!

Please help me understand what is wrong.

EDIT: I found that all calculations differ from reality by a factor of 2^16. Then I found this: <https://bitcoin.stackexchange.com/a/11816/62320>
This would suggest that for Scrypt, pools use a scaled "share difficulty" value by exactly that factor, but the reported block difficulty would not be scaled. This would explain everything but it's the only place I found this on the Internet (and it would mean that I need different calculations depending on the algorithm I'm handling) - can anyone confirm this?

**Tags:** difficulty, scrypt


---

## 2 answers

### Answer by username_0 on 2017-10-23. Score: 0 | Accepted answer

I found the reason for this confusion myself now:

It was very confusing and took a while to understand, especially because this information is not easily obtainable when researching on the Internet (without already knowing the answer in order to know the right keywords - forum threads didn't help either).

It seems like there are algorithms, Scrypt is one of them, which use a **scaled value for share difficulty**.

Let me explain:

**For Bitcoin (which is SHA-256), the following applies:**

* A hash is a "try" to find a certain solution
* On average, you need 2^32 (~4 billion) tries to find a valid "share" (originally this was the only type of share in existence, which has difficulty 1, but by now, all pools use shares with difficulties higher than 1, see below)
* If the coin difficulty were 1, this would be a valid block
* With a coin difficulty higher than 1, let's say N, on average only 1 out of N such "valid shares" (with difficulty 1) get you a valid block
* Recap: for coin difficulty N, you need on average N\*2^32 hashes to find a block
* Therefore, a formula to know how many seconds on average it takes to find a block with a certain hashing power is "average time = difficulty \* 2^32 / hashrate"
* When mining pools are concerned, pools accept only shares with difficulty >N, and 1 share with difficulty N is counted the same way as N shares with difficulty 1 (or N/2 shares with difficulty 2\*N, etc.) - that's the pool difficulty
* This also means that with an N=2\*coindiff in PPLNS, like most pools do, on average, the last "N" shares in the "PPLNS" cover 2 blocks

**OK, so I tried to apply this info to Scrypt**, because when researching things like Litecoin difficulty, the formulae I found were the same, e.g. "average time = difficulty \* 2^32 / hashrate", and that on average you need 2^32 hashes to find a difficulty-one share, etc.

However it didn't make sense, everything was far off from what I saw on our mining pools.

In fact, it turned out that it was off by a factor suspiciously close to 2^16.

Further research and testing finally gave us the answer that **for Scrypt, by convention, pools and miners scale the share difficulty value by a factor of 2^16**.

But only the pools and the miner software (e.g. cgminer)! the network difficulty is still displayed without scaling!

**Example:**

Let's say the network difficulty is 900,000 for BCC (Bitconnect Coin)

In the original calculation, I would assume that it takes on average 21 hours at a hashrate of 50 GH/s to find a block (900k \* 2^32 / 50G = ~77k seconds = ~21 hours), which is about right when looking at our pool.

However, I would then also assume that it takes a total value of shares of around 900,000 (exactly the network difficulty), however that's not true, because one AntMiner L3+ alone already submits a share with diff of ~150,000 every ~15 seconds, so I would assume that it finds a block every 90 seconds, which is of course not true (it's closer to 90 days than to 90 seconds).

And here is the issue: for Scrypt, **share difficulty is measured with a value mulitplied by 65,536**!

So, in fact, the "difficulty 150,000" which the pool uses with the AntMiners is *actually* 150,000/65,536 = 2.29

And, this means that in order to get to that coin difficulty value of 900,000, the pool needs to display a total value of shares of 900,000\*65,536 = 58,982,400,000!

Then, everything suddenly makes sense again.

There are also other algorithms which use such a scaling factor. In fact, I found that the UNOMP pool software already has a file which also contains these values: <https://github.com/UNOMP/node-merged-pool/blob/master/lib/algoProperties.js> (look for `multiplier`). For SHA-256 it's 1, for Scrypt it's 2^16.

According to pieces of information scattered throughout the Internet, this was done because Scrypt is a more difficult algorithm per se, which resulted in pools accepting shares with difficulties smaller than 1, and to avoid issues with the fact that difficulties and share values could suddenly be non-integral, the whole number was scaled so that the unit "difficulty 1" now actually meant 2^(-16).

So, rule of thumb:

* Whenever you see a difficulty value in context of a **miner** or a **pool** for **Scrypt**, you need to **divide it by 65,536** if you want to compare it with other numbers like the overall coin difficulty.
* For coin/block difficulty values (even in Scrypt), and in general for SHA-256 or X11, don't divide it. For other algorithms, look it up (for example, Blake uses 2^8).


---

### Answer by username_1 on 2017-10-21. Score: 0

> An AntMiner L3+ submits a share at difficulty ~150,000 (which counts as a share value of 150,000 then) every ~15 seconds, so in 3 minutes, that one AntMiner has already filled the whole "N" of 900,000x2=1,800,000. That would, in reverse, mean that I would expect to mine a BitConnect block every 90 seconds on average, with one AntMiner, which is of course not true.

I don't think that is how shares are counted. According to [this Bitcointalk post](https://bitcointalk.org/index.php?topic=39832),

> When a share is submitted, assign to it a score of 1/D, where D is the difficulty at the time the share is submitted.

So in your scenario, when your AntMiner L3+ submits a share, that share is assigned a score of 1/900000, so its "share value" is 2, not 150000.

> **Comments:**
> **username_0**: But that is only to compensate for network difficulty changing over tone, isn't it? And of course the answer your mention is based on bare shares with difficulty 1, so in my case it would be 150000/900000, giving 0.17, how do you get to 2 in your answer?  
> **username_0**: And then how come the difficulty gets squared? This sounds strange. I mean, saying that a diff 1 gives 1/900k, and the N is still 2x900k, meaning that you need 2x(900k^2) diff 1 shares - doesn't that square there feel a bit out of place?  
> **username_1**: What makes you think my answer is based on shares with a difficulty of 1? At no point in the post I linked to is difficulty of 1 suggested or mentioned. The squared is for variance (the statistical term), which is the square of standard deviation. Variance is not part of the calculation that you want to look at.  
> **username_0**: I meant that the forum post you linked is using the term "share" as "share diff 1". A share with a higher difficulty must have an equally higher value...  
> **username_0**: In fact, after doing various calculations, it seems everything is off from reality by a factor of 2^16, as if N*2^16 (instead of N*2^32) hashes would give you a share with difficulty N... I don't understand yet why, though  
> **username_0**: I found this now: https://bitcoin.stackexchange.com/a/11816/62320 - does this mean that pools show a scaled difficulty value for Scrypt, but for other algorithms it's different, and the block difficulty is confusingly not scaled?  
> **username_2**: @username_0: The linked post does assume that share difficulty is 1, but that is easy to fix - instead of assigning a score of 1/D, you assign a score of d/D where d is the share difficulty. I'm not completely sure I understood the rest of your questions, but I highly recommend you read https://bitcoil.co.il/pool_analysis.pdf before starting to implement reward methods. It should either answer your questions or give you the background to ask more focused ones.  
> **username_0**: @username_2: Yes, true, that's what I meant in my example in my comment above. The rest of my questions is already answered by myself, see the other answer in this thread. Thanks for your link, though!  

---

