Mark Freidenbach presented a low-pass filter idea for difficulty adjustment back in 2016 in this video and implemented it on Freicoin (which is now kind of dead). I immediately thought this was a bad idea (when I saw it in 2017) because there is no "noise" to be filtered. All the data points (solvetimes) are (exponentially) random, but relevant, not the result of noise from a an external forcing function that needs to be filtered. The EMA algorithm correctly converts the non-noise randomness back to linear data points. In the video, Mark and a questioner seem to think a higher-order filter would be better, but they would have the same problem. In a grander sense 2nd order calculations do not apply to difficulty because there is no mass-like variable with an inertia-like quality in difficulty as it is in physical systems (which I discuss in the PID controller for difficulty issue). Low pass filtering can apply to difficulty because on-off mining is a persistent problem in small coins, and that's akin to a radio picking up a click of static if a nearby large surge of current occurs. But that's not what the Freicoin algorithm is trying to address. Several of my algorithms do just the opposite of a low pass-filter: they increase difficulty as quickly as possible if an increase in hashrate occurs.
Lengthy Side Note: Electrical Signal Analogy to Hashrate
Simply taking a longer average is a low-pass filter, same as putting a coke inductor in series on a laptop's power cord (or a capacitor in parallel for the DC output of a power supply). Inductors and capacitors in these cases are storing energy, and difficulty is doing something very similar: measuring a true energy that is proportional to a number of hashes that occurred over it's averaging period. So the difficulty coming out is smoother. My fast-response add-ons to difficulty such as LWMA-3 or 4, fuzzy LWMA, and dynamic LWMA are even more like the inductor and capacitor but in a very different way: rather than trying to get difficulty to be smooth, they try to get solvetimes smooth. The sudden increase in difficulty is like the "ohmic reactance" of inductors and capacitors ("reactance" is the more general form of ohms of resistance, resistance to voltage change in capacitors and resistance to current change in inductance). The best analogy is somethinhashes are electrons and therefore hashrate is current and therefore responding with a higher difficulty to higher hashrate more quickly is like a larger inductor in series with the wire (network). Inductors are 1st order filters and 2nd order is warranted. In algorithms I used non-linear functions to detect and respond to the non-linear sudden hashrate changes which is high order.
The Algorithm
It looks at the past 144 blocks (1 day at T=600 seconds) and attempts to adjust once every 9 blocks. Not adjusting every block makes no sense. It seems to make it revert to its +/- 5% adjustment limits half the time, causing a bad sawtooth pattern, always above it's target solvetime.
The filter was supposed to assign weights to different solvetimes:
Y-axis is the weight and the x-axis are solvetimes. It gives more weight to near-average solvetimes (or maybe solvetimes closer to target) and less weight to high and low solvetimes. Below this plot was a plot of the frequency response where the low "frequencies" were allowed to pass through while the high frequencies were blocked. He said "low frequencies which represent the long term averages are passed through unchanged." I can't make sense of this or how the weighting factors of the first plot could lead to the "frequency" response of the second.
The weights are used to affect difficulty like this"
Mark Freidenbach presented a low-pass filter idea for difficulty adjustment back in 2016 in this video and implemented it on Freicoin (which is now kind of dead). I immediately thought this was a bad idea (when I saw it in 2017) because there is no "noise" to be filtered. All the data points (solvetimes) are (exponentially) random, but relevant, not the result of noise from a an external forcing function that needs to be filtered. The EMA algorithm correctly converts the non-noise randomness back to linear data points. In the video, Mark and a questioner seem to think a higher-order filter would be better, but they would have the same problem. In a grander sense 2nd order calculations do not apply to difficulty because there is no mass-like variable with an inertia-like quality in difficulty as it is in physical systems (which I discuss in the PID controller for difficulty issue). Low pass filtering can apply to difficulty because on-off mining is a persistent problem in small coins, and that's akin to a radio picking up a click of static if a nearby large surge of current occurs. But that's not what the Freicoin algorithm is trying to address. Several of my algorithms do just the opposite of a low pass-filter: they increase difficulty as quickly as possible if an increase in hashrate occurs.
Lengthy Side Note: Electrical Signal Analogy to Hashrate Simply taking a longer average is a low-pass filter, same as putting a coke inductor in series on a laptop's power cord (or a capacitor in parallel for the DC output of a power supply). Inductors and capacitors in these cases are storing energy, and difficulty is doing something very similar: measuring a true energy that is proportional to a number of hashes that occurred over it's averaging period. So the difficulty coming out is smoother. My fast-response add-ons to difficulty such as LWMA-3 or 4, fuzzy LWMA, and dynamic LWMA are even more like the inductor and capacitor but in a very different way: rather than trying to get difficulty to be smooth, they try to get solvetimes smooth. The sudden increase in difficulty is like the "ohmic reactance" of inductors and capacitors ("reactance" is the more general form of ohms of resistance, resistance to voltage change in capacitors and resistance to current change in inductance). The best analogy is somethinhashes are electrons and therefore hashrate is current and therefore responding with a higher difficulty to higher hashrate more quickly is like a larger inductor in series with the wire (network). Inductors are 1st order filters and 2nd order is warranted. In algorithms I used non-linear functions to detect and respond to the non-linear sudden hashrate changes which is high order.
The Algorithm It looks at the past 144 blocks (1 day at T=600 seconds) and attempts to adjust once every 9 blocks. Not adjusting every block makes no sense. It seems to make it revert to its +/- 5% adjustment limits half the time, causing a bad sawtooth pattern, always above it's target solvetime.
The filter was supposed to assign weights to different solvetimes:
Y-axis is the weight and the x-axis are solvetimes. It gives more weight to near-average solvetimes (or maybe solvetimes closer to target) and less weight to high and low solvetimes. Below this plot was a plot of the frequency response where the low "frequencies" were allowed to pass through while the high frequencies were blocked. He said "low frequencies which represent the long term averages are passed through unchanged." I can't make sense of this or how the weighting factors of the first plot could lead to the "frequency" response of the second.
The weights are used to affect difficulty like this"
For example, if solvetimes are faster, next_D will be increased more, so the direction of correction is correct.