4

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?

Improve this question

2 Answers 2

Reset to default
3

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.

Improve this answer
2
  • 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
    Jan 8, 2014 at 21:47
  • Ahh it seems that's the problem. I'm thinking in terms of the GetWork protocol. VarDiff changes all that. Got it.
    – John
    Jan 9, 2014 at 14:10
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.

Improve this answer
4
  • 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
    Jan 8, 2014 at 22:35
  • 1
    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
    Jan 8, 2014 at 22:44
  • 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
    Jan 8, 2014 at 22:48
  • 1
    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
    Jan 8, 2014 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.