Topic: [LTC] Question About Difficulty Rating (Read 1214 times)

Your expected return, during a run of 2016 blocks (about 3 days) is:

expected_return = 50 LTC/block * 24 blocks/hour * your_hashrate / network_hashrate

To be clear, this network hashrate is the software's estimate of the network hashrate over the course of the previous 2016-block run.  It doesn't actually store that though, it stores "nBits", which is commonly reported as a floating-point difficulty number, such that:

network_hashrate = difficulty * 2^32 / 150s

so you can simplify that first equation down to:

expected_litecoins_per_hour = your_hashrate_in_kH_per_s / difficulty * 0.0419

or, to within 1%, expected_litecoins_per_day = your_hashrate_in_kH_per_s / difficulty

Again, this difficulty is nailed down at the start of each 2016-block run, and the equation holds for the rest of the run, regardless of changes to your hashrate during the run.

So written this way, the trick is predicting future difficulty changes.  The most direct way is to keep an eye on the block generation rate and run through the difficulty recalculation algorithm yourself, which is quite simple.  At the end of each 2016-block streak, it looks at the time it took to generate all those blocks, and divides 2016 by it to work out the actual block generation rate, then adjusts the old difficulty linearly to compensate for the error.  Effectively it picks a difficulty which would have made the previous 2016-block run complete in the right amount of time.

For example, take the 153-difficulty sequence which ended this morning:

Last block time: 2013-04-06 01:10:35
Last block of previous run: 2013-04-03 10:39:05
Total time for 2016 blocks: 3751.5 minutes
Average time per block: 1.86 minutes
Drift factor: 2.5 / 1.86 = 1.34
New difficulty: 1.34 * 153 = 205

If you're running this calculation yourself before the end of a run, e.g. using the last 100 blocks as a guide, then make sure the sequence of blocks you use all have the same difficulty value (i.e. they don't cross a 2016-block boundary).  You can use this calculation to get unstable short-term readings or more stable medium-term readings, depending how many blocks you look at.  The best estimate for the next difficulty will come from using all of the blocks since the start of the current 2016-block run.

In the end though statistics can help you find trends in past data, but guessing the future is up to the economists.  Economics is about models, not truth, and there's no one correct model.  So this is about as far as you can go with strict equations.

instead of a share requiring say 75k hashes, it would require 150k hashes.. hence "half the rate"

the share would then pay say .004 ltc each instead of .002 ltc each.

exact same income, just different way of getting there.

now the network difficulty (8.8 currently on LTC and 2.86 million on BTC) is something different.......

Sorry, I'm not understanding. The pool is limiting my hash rate?

The difficulty you are referring to is PER SHARE difficulty. This exists in BTC as well, its just not highly utilized yet. The difficulty 1 share has X hashes required to solve.. a difficulty 2 share takes 2x hashes (you do shares at half the rate but each one is worth double). This reduces bandwidth and server load.

you do shares at half the rate but each one is worth double

They don't. In pools each hash submitted meets the minimum difficulty requirement equivalent to when LTC launched. The "winning" hash meets the difficulty criteria and then a block is then generated and each of the miners in that pool proportionally get a % of the 50 LTC based on how many shares they submitted. This is for PPS pools.

In the first months after the launch of Litecoin, most pools used a share difficulty of 2-16 or 2-15. They could have used even lower values, but there was no point in doing that.

If so, then how is it possible that different pools use different difficulty settings? How can they "set" the difficulty if it is determined by a formula of miners to hashing power...?