Enhancements to ETTS

[jamescowens]

A very spirited discussion on Discord on 4/28/2019 has come up with good ideas to further enhance calculation and display of ETTS from the foundational work done in 3.7.12.0. Thanks to Discord users HoWnixT and osandstedt for some really good ideas and discussion... Here is a distillation...

1. Consider using an exponentially decaying average approach for the underlying difficulty calculation, potentially with a half-life of 7 days: w(t) ~ exp(-ln(2)/7 * t) where w(t) is the averaging weight and t is in days. This means 97% of the weight captured in a month. Probably will require a new approach to storing running difficulties to reduce calculation overhead (because this would be over approximately 960 * 30 blocks if computed from scratch every time).

2. Consider displaying ETTS as a frequency rather than time to prevent the "countdown" syndrome, where people believe the estimate is a "countdown." This would be done in the following manner:

Choose a unit shift breakpoint number... the initial choice is 3 for the frequency breakpoint for unit change.

So if the frequency f=1/ETTS (in 1/days) is (reading the lowest line that satisfies)...

'>= 3/day, display "Wallet estimated to stake f times per day."
'< 3/day, display "Wallet estimated to stake f * 7 times per week."
'< 3/week, display "Wallet estimated to stake f * 30 times per month."
'< 3/month, display "Wallet estimated to stake f * 90 times per quarter."
'< 3/quarter, display "Wallet estimated to stake f * 365 times per year."`

Some examples.

ETTS = 0.10 days -> f = 10: "Wallet estimated to stake 10 times per day."
ETTS = 0.5 days -> f = 2: "Wallet estimated to stake 14 times per week."
ETTS = 6 days -> f = 1/6: "Wallet estimated to stake 5 times per month."
ETTS = 30 days -> f = 1/30: "Wallet estimated to stake 3 times per quarter."
ETTS = 120 days -> f = 1/120: "Wallet estimated to stake 3 times per year."

3. When moving to a frequency based approach it may be better to go back to a confidence level that corresponds to the "mean", which is 1 - 1/e = 63.2%, rather than use 80%, so that the frequency estimated corresponds with what the wallet would see historically.

[jamescowens]

The implementation I did in #1611 is very similar to the write-up I did above. I use a threshold for unit change of 1.0 instead of 3, and allow up to two decimal places of precision.