Correcting the error in getnetworkhashrateps

I believe this is the best-possible estimate of current hashrate for an arbitrarily-small fixed time period t when given only the lowest hash seen in t.

L = \text{lowest hash seen in time t}

W = \text{work in t}

\lambda = \frac{W}{2^{256}}

\text{exponential CDF}(L) = 1 - e^{-\lambda L}

E = \text{error signal} = \text{CDF}(L) - 0.5

The error signal is the probability that the prior estimate of W was wrong. 0.5 is the median observation if the prior estimate was correct, so there would be no error. Use the error signal in the EMA equation.

h = \text{height of t time segments}

W_{h} = W_{h-1} \cdot e^{-\frac{E}{N}}

\text{Stdev} \approx \frac{W}{\sqrt{2N}} (if hashrate is constant and initial W_0 is correct.

W and L in my lambda are at h -1

N = “mean lifetime” of the EMA estimate in units of t. You choose N to get your desired stability / slowness of the estimate. Divide by t to get hashrate.

To simplify the equation, use e^{-x} \approx 1-x for small x = \frac{E}{N}:

W_{h} = W_{h-1} \cdot ( 1 + \frac{e^{-L \cdot W_{h-1}}}{N} - \frac{1}{2N})

The median L is expected to be ln(2) \cdot W_{h-1} which would be no correction. The smallest-possible L makes the largest-possible correction:

W_{h} = W_{h-1} \cdot ( 1 + \frac{1}{2N})

A large L can has a large correction, but an accidentally-large L isn’t possible like a small L. This is a spot check on my math and the legitimacy of the idea The idea comes from my search for the mathematically-perfect difficulty algorithm which similarly uses the exponential CDF of solvetimes to adjust difficulty every block and experiments have shown it is the best-known (fastest response time to changes in hashrate with the least variation).

hashrate = sum(work)/(time duration) from h - N to h gives a better estimate of hashrate at h -N/2. The EMA needs a starting W. If it starts at h-N The starting W_{h-N} could be obtained by sum(work) from h-\frac{3N}{2} to h-\frac{N}{2} and dividing by N.