Added "ema" algos (exp moving avg)

[jacob-eliosoff]

No description provided.

[dgenr8]

Thanks @jacob-eliosoff! In my rough tests so far, ema-1d performs very strongly.

It usually has a better blocktime median (closer to 415s) than the other algorithms, and lower stddev and max. The mean seems consistently slightly low (around 585s). For some reason, the other algorithms have always done best on this measure.

Of the three versions, ema-1d looks best to me. ema-3h has high-frequency oscillations even in the default scenario (for example /mining.py -s default -a ema-3h -r 660). More concerning, in the corresponding -s fxramp scenario , the amplitude of the difficulty noise is significant. Do you see the same when you chart it?

[jacob-eliosoff]

I'm on the road now but can have a look later in the week... The algo's basic idea is simple. It treats the target as a stored estimate of (ie, exponential moving avg of) recent hashrate. Then every block time we see is a small update to that EMA: eg, when we see a 2-minute block, that suggests hashrate during those 2 minutes was ~5x higher than we expected. Of course the "3h" refers to the EMA period, so ema-3h means: set the difficulty to produce 10-min blocks, assuming upcoming hashrate = avg hashrate "over the last 3 hrs" (in the gradual EMA sense). Most of the algo's behavior can be inferred from this. Shorter EMA windows -> faster adjustment to hashrate changes, but also more bouncing around. I'd expect the mean to be on the low side in tests where hashrate increased overall. If hashrate goes up no more than down I'd expect a ~600s avg, so I might have a bug of some kind there.

[jacob-eliosoff]

I had a quick look at the numbers for ema-3h under the default and fxramp scenarios, but nothing jumps out at me - what ideally would you want to look different? You can make difficulty bounce around less by choosing a longer EMA window (like 1d or heck, 1w); the tradeoff is it will adapt more slowly - eg, if a bunch of miners leave, blocks could take a long time (à la BTC) to drop back to 10 minutes. This seems like a fundamental, inevitable tradeoff.

Also I'm seeing a 590-610 mean for all my tests regardless of EMA window, so hopefully the low ones you saw were a blip...

[zawy12]

I'm also seeing less than +/- 1% error for all windows when hashrate is constant. If the initial difficulty is off from the correct difficulty, then the mean will be wrong unless you calculate it after D has stabilized.

My "correction" to Degnr8's wt to a true weighted harmonic mean appears just as good.

Yes, smaller windows recover from attacks faster at the expense of being more unstable. An unstable difficulty is not a drawback for constant miners and if the D is not off by more than 30%, then accidental delays (30% longer) should not be a problem. The 3-hr window gives the kind of response verses tradeoff that I think is good.

The only problem with N=144 for these algos is if the price drops 30% in a day: maybe 80% of the miners will leave, causing 72 blocks to average 3.75 times longer to solve. I have argued against N=144 based on alts have to fork when N=300, but I don't know the details of that N=300 code. Logically I see no problem with it except that difficulty will be half a day behind market price.