<p>There really isn't one when you are pool mining. Most pools these days use VarDiff to achieve the same number of shares per minute by changing your workers difficulty. Now, on a low end mining rig (lets say 20 kh/s) the number of shares accepted may vary greatly as you may have some great luck with your share or it may be bad luck. So as long as you have a "sane" level of hashing power you shouldn't see (m)any trends/changes (as long as the pool+VarDiff is properly set up).</p>

<p>That being said, when you are first connecting to VarDiff enabled pools you will start at a diff of 1, then it will adjust over a period of time to achieve a share per minute rate that was defined by the pool op.</p>

<p>Source: Me, I'm a pool-op</p>

<p><em>EDIT</em>
At one time, the number of shares you submitted directly related to your hashrate, the more accepted shares, the faster you were hashing. AsicMiner products still use the protocol originally used by pools (and bitcoind) called "getwork". Most notable of the pool servers used at that time is pushpool.</p>

<p>With VarDiff you don't have the ability to calculate by the number of shares submitted. So you now calculate the hashrate based on the difficulty of the share submitted. I personally have found that when the hashrate calculation based purely on the number of shares submitted is slightly weighed in with your hashrate calculation based on the difficulty of the share submitted, the user's hashrate you calculate is more accurate than you would have if you calculated the hashrate purely on the difficulty of the submitted share.</p>

CC BY-SA 3.0
2014-01-08T21:47:37.593Z
So the difficulty is the number of leading zero bytes required in the hash, right? So a difficulty of 1 would require only the first byte to be zero, and this would then be easier to find? But will the pool reward you with more LTC for higher difficulty ("quality") shares?
John
CC BY-SA 3.0
2014-01-09T14:10:16.023Z
Ahh it seems that's the problem. I'm thinking in terms of the GetWork protocol. VarDiff changes all that. Got it.
John
CC BY-SA 3.0
2014-01-08T21:30:49.137Z
2014-01-09T03:28:02.880Z
2014-01-09T03:28:02.880Z
Joe White
<p>"One of those nonce's is the number you're looking for and will result in an accepted share."</p>

<p>This assumption is wrong. All you need to ensure is that your hash is below target (and the target is based on difficulty). So you might hit a block which has no nonce that would give a hash below target, and you might hit a block for which every nonce would give a valid share.</p>

<p>So if, for example, your target is 0x0FFFFFFFF..., then on average 1 in 16 hashes will result in a valid share. And if your target is 0x0000000000000000FFFF..., for example, then you'll probably need to run the loop multiple times to hit a block.</p>

CC BY-SA 3.0
2014-01-08T22:35:22.810Z
Well then, if your target was 0x0000FFFFFFFF.... on average one in ~65,000 would be valid, right? Then is my comment about 0X00000000FFFFFFFFFFFF.... resulting in one in four billion is right on average?
John
CC BY-SA 3.0
2014-01-08T22:44:12.940Z
Yes, if I count the zeroes correctly. But the point is, the amount of iterations for nonce is pretty much irrelevant - it's the target that defines the ratio between hashrate and sharerate, and difficulty is related to target.

Also, pools generally either have a set difficulty for everyone (that means you'd get more shares on lower difficulty, but *everybody* would be getting more shares, so when the pool hits a block, a single share is worth less), or varies difficulty, and then calculates shares submitted with higher difficulty as worth more when it comes to distributing the block.
Maciej Stachowski
CC BY-SA 3.0
2014-01-08T22:48:50.440Z
I did some quick reading and it seems litecoin uses fractional difficulties... Which makes no sense to me. I always thought of difficulty as the number of zero bytes in the hash. Now it looks like it's whether the hash is less than the target. What would a normal-ish difficulty target look like that would result in one accepted share per second at somewhere around 700-1500Kh/s?
John
CC BY-SA 3.0
2014-01-08T22:53:53.747Z
I'm currently mining at difficulty 32 and my target is 0x000007fff800... ; to be perfectly honest, I have no idea what the exact relationship between difficulty and target is. I'd say that this would result in about 1 share per 1-2 seconds on a ~1MH/s mining rig, but you generally don't want to be submitting shares too fast, or you risk getting bound by your network throughput.
Maciej Stachowski
CC BY-SA 3.0
2014-01-08T22:23:49.413Z
2014-01-08T22:23:49.413Z
Maciej Stachowski
<p>Specifically this question is about Litecoin, but I suspect the answer would apply to both.</p>

<p>Say you have a rig mining at 700Kh/s (LTC). It seems that you get, more or less, a one or a few accepted shares per second.</p>

<p>My understanding is that when mining, you're iterating through 0 to ~ 4 billion for your nonce. One of those nonce's is the number you're looking for and will result in an accepted share.</p>

<p>On average, you'd expect to solve for the correct nonce in about 2 billion tries. But, if you're only mining at 700Kh/s, the math doesn't add up. If you're only trying 700,000 nonces per second, it will take about 45 minutes to find the right nonce.</p>

<p>What am I missing here?</p>

<mining-pools><litecoin><hash><mining-pool-shares><nonce>
What is the relationship between hash rate and accepted shares?
John
# What is the relationship between hash rate and accepted shares?

(Asked by: username_0 on 2014-01-08)

Specifically this question is about Litecoin, but I suspect the answer would apply to both.

Say you have a rig mining at 700Kh/s (LTC). It seems that you get, more or less, a one or a few accepted shares per second.

My understanding is that when mining, you're iterating through 0 to ~ 4 billion for your nonce. One of those nonce's is the number you're looking for and will result in an accepted share.

On average, you'd expect to solve for the correct nonce in about 2 billion tries. But, if you're only mining at 700Kh/s, the math doesn't add up. If you're only trying 700,000 nonces per second, it will take about 45 minutes to find the right nonce.

What am I missing here?

**Tags:** mining-pools, litecoin, hash, mining-pool-shares, nonce


---

## 2 answers

### Answer by username_1 on 2014-01-08. Score: 3 | Accepted answer

There really isn't one when you are pool mining. Most pools these days use VarDiff to achieve the same number of shares per minute by changing your workers difficulty. Now, on a low end mining rig (lets say 20 kh/s) the number of shares accepted may vary greatly as you may have some great luck with your share or it may be bad luck. So as long as you have a "sane" level of hashing power you shouldn't see (m)any trends/changes (as long as the pool+VarDiff is properly set up).

That being said, when you are first connecting to VarDiff enabled pools you will start at a diff of 1, then it will adjust over a period of time to achieve a share per minute rate that was defined by the pool op.

Source: Me, I'm a pool-op

*EDIT*
At one time, the number of shares you submitted directly related to your hashrate, the more accepted shares, the faster you were hashing. AsicMiner products still use the protocol originally used by pools (and bitcoind) called "getwork". Most notable of the pool servers used at that time is pushpool.

With VarDiff you don't have the ability to calculate by the number of shares submitted. So you now calculate the hashrate based on the difficulty of the share submitted. I personally have found that when the hashrate calculation based purely on the number of shares submitted is slightly weighed in with your hashrate calculation based on the difficulty of the share submitted, the user's hashrate you calculate is more accurate than you would have if you calculated the hashrate purely on the difficulty of the submitted share.

> **Comments:**
> **username_0**: So the difficulty is the number of leading zero bytes required in the hash, right? So a difficulty of 1 would require only the first byte to be zero, and this would then be easier to find? But will the pool reward you with more LTC for higher difficulty ("quality") shares?  
> **username_0**: Ahh it seems that's the problem. I'm thinking in terms of the GetWork protocol. VarDiff changes all that. Got it.  

---

### Answer by username_2 on 2014-01-08. Score: 1

"One of those nonce's is the number you're looking for and will result in an accepted share."

This assumption is wrong. All you need to ensure is that your hash is below target (and the target is based on difficulty). So you might hit a block which has no nonce that would give a hash below target, and you might hit a block for which every nonce would give a valid share.

So if, for example, your target is 0x0FFFFFFFF..., then on average 1 in 16 hashes will result in a valid share. And if your target is 0x0000000000000000FFFF..., for example, then you'll probably need to run the loop multiple times to hit a block.

> **Comments:**
> **username_0**: Well then, if your target was 0x0000FFFFFFFF.... on average one in ~65,000 would be valid, right? Then is my comment about 0X00000000FFFFFFFFFFFF.... resulting in one in four billion is right on average?  
> **username_2**: Yes, if I count the zeroes correctly. But the point is, the amount of iterations for nonce is pretty much irrelevant - it's the target that defines the ratio between hashrate and sharerate, and difficulty is related to target.  Also, pools generally either have a set difficulty for everyone (that means you'd get more shares on lower difficulty, but *everybody* would be getting more shares, so when the pool hits a block, a single share is worth less), or varies difficulty, and then calculates shares submitted with higher difficulty as worth more when it comes to distributing the block.  
> **username_0**: I did some quick reading and it seems litecoin uses fractional difficulties... Which makes no sense to me. I always thought of difficulty as the number of zero bytes in the hash. Now it looks like it's whether the hash is less than the target. What would a normal-ish difficulty target look like that would result in one accepted share per second at somewhere around 700-1500Kh/s?  
> **username_2**: I'm currently mining at difficulty 32 and my target is 0x000007fff800... ; to be perfectly honest, I have no idea what the exact relationship between difficulty and target is. I'd say that this would result in about 1 share per 1-2 seconds on a ~1MH/s mining rig, but you generally don't want to be submitting shares too fast, or you risk getting bound by your network throughput.  

---

