Understanding difficulty

[konradp]

Hi,

After reading https://en.bitcoin.it/wiki/Difficulty I understand that difficulty is max diff/current diff.

But I don't understand two things:

1. Why does this even exist? Why not use the target, a pool sends a target (lower than network target) and miners try to find a hash for it. I understand that difficulty is something easier to understand for humans, but why *software* works basing on difficulty?

2. Current difficulty is about 5 006 937 017, then why a pool I'm using sends "set_difficulty,240" (stratum), besides on many pools user can set a difficulty between 1 and a few hundred. What is this?

[1715106397]

1715106397

[1715106397]

1715106397

[Altoidnerd]

1. Why does this even exist? Why not use the target, a pool sends a target

Because inverses and fractions make people happy.  

Now diff goes like ~ 1/target.

For long times, network_hashrate/diff ~ constant rather than the product network_harshrate*target.  Fraction good, product bad.

...
 then why a pool I'm using sends "set_difficulty,240" (stratum), besides on many pools user can set a difficulty between 1 and a few hundred. What is this?

Sharediff is different... let a true expert explain better but basically, if you have a super fast miner, you can ask it to only send shares that are twice as good, but only half as often...its a server optimization.

If my miner has a sharediff set to 10, I (should) get 10x the credit every time I submit a share.  The rules vary by pool.

[konradp]

Thanks.

If my miner has a sharediff set to 10, I (should) get 10x the credit every time I submit a share.  The rules vary by pool.

OK, I get it, but the range (e.g. sharediff from 1 to e.g. 100) is up to the pool creator yes? Or is there maybe a consensus/well established rules about it?

Edit: or maybe there is no reason to set the maximum of it?

[Altoidnerd]

The way the pools work is quite mysterious to me.  Slush invented pools, but he's a busy guy.  I think I know someone who will know the answer, I'll try to loop him in.

[litecoin_messiah]

Thanks.

If my miner has a sharediff set to 10, I (should) get 10x the credit every time I submit a share.  The rules vary by pool.

OK, I get it, but the range (e.g. sharediff from 1 to e.g. 100) is up to the pool creator yes? Or is there maybe a consensus/well established rules about it?

Edit: or maybe there is no reason to set the maximum of it?

65536 is the average number of hashes to be computed in order to find a 1 share at mining difficulty 1 for a bitcoin based coin.

When the pool sets the share-diff to something higher, for example at share diff 10, your miner has to hash 10x more to find that share on average.

So 655360 hashes at share diff 10 and 65536 hashes at share diff 1.


Pools with vardiff or anything similar adjust the share diff to something like 512, because miners with 100's of khashs will have to make more connections to the stratum server at a lower mining difficulty resulting a higher risk of shares being lost. If they send shares at a higher difficulty they will be submitting work less often and have less stales.

Dunno why i'm explaining this or even if it was necessary, i haven't slept so excuse me 

[konradp]

Thanks.

If my miner has a sharediff set to 10, I (should) get 10x the credit every time I submit a share.  The rules vary by pool.

OK, I get it, but the range (e.g. sharediff from 1 to e.g. 100) is up to the pool creator yes? Or is there maybe a consensus/well established rules about it?

Edit: or maybe there is no reason to set the maximum of it?

65536 is the average number of hashes to be computed in order to find a 1 share at mining difficulty 1 for a bitcoin based coin.

When the pool sets the share-diff to something higher, for example at share diff 10, your miner has to hash 10x more to find that share on average.

So 655360 hashes at share diff 10 and 65536 hashes at share diff 1.


Pools with vardiff or anything similar adjust the share diff to something like 512, because miners with 100's of khashs will have to make more connections to the stratum server at a lower mining difficulty resulting a higher risk of shares being lost. If they send shares at a higher difficulty they will be submitting work less often and have less stales.

Dunno why i'm explaining this or even if it was necessary, i haven't slept so excuse me 

Thanks, but now I'm completely lost

Why 65536? Why this *constant*? Doesn't it depend on current network difficulty?
And - why sending sending shares less often results in lower risk of shares being lost?

[litecoin_messiah]

Thanks.

If my miner has a sharediff set to 10, I (should) get 10x the credit every time I submit a share.  The rules vary by pool.

OK, I get it, but the range (e.g. sharediff from 1 to e.g. 100) is up to the pool creator yes? Or is there maybe a consensus/well established rules about it?

Edit: or maybe there is no reason to set the maximum of it?

65536 is the average number of hashes to be computed in order to find a 1 share at mining difficulty 1 for a bitcoin based coin.

When the pool sets the share-diff to something higher, for example at share diff 10, your miner has to hash 10x more to find that share on average.

So 655360 hashes at share diff 10 and 65536 hashes at share diff 1.


Pools with vardiff or anything similar adjust the share diff to something like 512, because miners with 100's of khashs will have to make more connections to the stratum server at a lower mining difficulty resulting a higher risk of shares being lost. If they send shares at a higher difficulty they will be submitting work less often and have less stales.

Dunno why i'm explaining this or even if it was necessary, i haven't slept so excuse me 

Thanks, but now I'm completely lost

Why 65536? Why this *constant*? Doesn't it depend on current network difficulty?
And - why sending sending shares less often results in lower risk of shares being lost?

Network latency and stuff like that cause disruptions in connections now and then.

dunno i'm very tired.

[konradp]

dunno i'm very tired

But will you be back tomorrow to this question? 

[Altoidnerd]

Why 65536? Why this *constant*?

https://www.google.com/#q=2%5E16&safe=off

If you haven't already, you should try mining.  That's the best way to learn.

[konradp]

Thanks, but it doesn't really help me that 65536==2^16 ...

I am mining, but this doesn't help either.

[Altoidnerd]

Thanks, but it doesn't really help me that 65536==2^16 ...

I am mining, but this doesn't help either.

https://en.bitcoin.it/wiki/Difficulty#What_network_hash_rate_results_in_a_given_difficulty.3F

[Jamestty]

Thanks, but it doesn't really help me that 65536==2^16 ...

I am mining, but this doesn't help either.

I also mining, for I have not much use!

[Altoidnerd]

The linked article explains the origin of the number. 

https://en.bitcoin.it/wiki/Difficulty#What_network_hash_rate_results_in_a_given_difficulty.3F

[Rannasha]

Thanks.

If my miner has a sharediff set to 10, I (should) get 10x the credit every time I submit a share.  The rules vary by pool.

OK, I get it, but the range (e.g. sharediff from 1 to e.g. 100) is up to the pool creator yes? Or is there maybe a consensus/well established rules about it?

Edit: or maybe there is no reason to set the maximum of it?

Pools can pick whatever they want for the share difficulty, as that is something between the pool and the miner. The idea is to give the miner a job that is significantly less difficult than finding a Bitcoin block, so that it can do this job many times before the pool finds a block. The pool then keeps track of how often each miner has performed this job in order to determine payouts.

The higher the share-difficulty, the longer it takes between shares being found by the miner. This means that there is more variability in payouts. On the other hand, every time a share is found, the miner has to communicate with the pool and the pool has to verify the share. If the share difficulty is too low, fast miners will spam the pool-server with new shares, possibly overloading it. That's why some pools adjust the share-difficulty based on the speed of the miner. Fast miners have to generate higher difficulty shares than slow miners. Of course, the higher difficulty shares count more towards the payout in the end.

Not long ago, I wrote a not-too-technical blogpost about the what, why and how of pool-mining. It may help you understand it a bit better. See: http://bitcoin.rannasha.net/?p=29

[konradp]

Pools can pick whatever they want for the share difficulty, as that is something between the pool and the miner

But there must be some kind of a standard, after all, miners must behave in the same way after receiving difficulty level.

[Rannasha]

Pools can pick whatever they want for the share difficulty, as that is something between the pool and the miner

But there must be some kind of a standard, after all, miners must behave in the same way after receiving difficulty level.

Why?

The Bitcoin network difficulty changes regularly as well. If anything, miners should be able to handle any difficulty value. The difficulty doesn't change the computation that is performed, it only affects the chance whether the outcome of the computation is good enough. A miner repeats the same computation with slightly different input until it finds an outcome that is good enough and beats the target.

[Altoidnerd]

But there must be some kind of a standard ..

The network cares if a pool finds a block.  The network doesn't care what a pool does internally.  A pool is free to use any method imaginable to produce blocks.  You are free to start mining blocks mentally if you wish.

after all, miners must behave in the same way after receiving difficulty level.

Forget the miner sharediff thing - there is a "standard" so that the pools agree on what the next difficulty shall be. Paraphrased, it is "readjust the target so that had the target been so for the previous the previous 2016 blocks, there would have been a 600 seconds block generation time.

If unsure, ask http://blockexplorer.com/q/nextretarget  http://blockexplorer.com/q/estimate

The notion of sharediff is a mining pools option for how they operate.  Slush's pool finds your optimal diff setting for you.  (You can prolly tell I am a Slush fan).

[cp1]

When a pool finds a block they need to divide the reward up between all the miners who helped.  So they need a way to track who helped and how much they helped.  Someone with 1GH/sec shouldn't get as much of a reward as someone with 1TH/sec.

They could have you submit each hash you calculate.  The 1GH/sec would then be sending 1 billion hashes to the pool per second, and the 1TH/sec miner would be sending 1 trillion hashes to the pool per second.  Each hash is 16 bytes, so this would be 16 terabytes of data per second sending back and forth to the pool.  Good luck with that.  Even if they only have you send the nonce, that's a crazy amount of traffic.

So instead you could just send "shares", which is a hash that meets the lowest difficulty (1).  Of course these aren't valid solutions, because the actual difficulty is much much higher than that, but they represent that you did some work, because it actually takes many hashes to luck out and hit a difficulty 1 solution.  So this cuts down on the traffic with the server.  If you have a fast miner, even this is too much traffic, so you can only send in difficulty 2 shares, difficulty 100 shares, etc.  As long as the pool knows you're only sending in these types of shares they can calculate how much hashing power you have, and what % of the reward you should get.

[Altoidnerd]

When a pool finds a block they need to divide the reward up between all the miners who helped.  So they need a way to track who helped and how much they helped.  Someone with 1GH/sec shouldn't get as much of a reward as someone with 1TH/sec.

They could have you submit each hash you calculate.  The 1GH/sec would then be sending 1 billion hashes to the pool per second, and the 1TH/sec miner would be sending 1 trillion hashes to the pool per second.  Each hash is 16 bytes, so this would be 16 terabytes of data per second sending back and forth to the pool.  Good luck with that.  Even if they only have you send the nonce, that's a crazy amount of traffic.

So instead you could just send "shares", which is a hash that meets the lowest difficulty (1).  Of course these aren't valid solutions, because the actual difficulty is much much higher than that, but they represent that you did some work, because it actually takes many hashes to luck out and hit a difficulty 1 solution.  So this cuts down on the traffic with the server.  If you have a fast miner, even this is too much traffic, so you can only send in difficulty 2 shares, difficulty 100 shares, etc.  As long as the pool knows you're only sending in these types of shares they can calculate how much hashing power you have, and what % of the reward you should get.

This is a great explanation.  +1

What are the displayed fractions for difficulty of shares found (running for example bfgminer or cgminer)? 

"bla bla, Accepted, 4/1

bla bla, Accepted, 1.5k/1 ... etc"

It's some metric but what exactly?

[cp1]

4/1 means it found a difficulty 4 share, but it only need a difficulty 1 share.  It counts as a difficulty 1 share still when you submit it.