<div dir="auto"><span style="font-family:sans-serif">Is there an issue with the current difficulty adjustment algorithm? It&#39;s worked very well as far as I can tell. Introducing a new one seems pretty risky, what would the benefit be?</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 2, 2017 4:34 PM, &quot;Scott Roberts via bitcoin-dev&quot; &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bitcoin cash will hard fork on Nov 13 to implement a new difficulty<br>
algorithm.  Bitcoin itself might need to hard fork to employ a similar<br>
algorithm. It&#39;s about as good as they come because it followed the<br>
&quot;simplest is best&quot; route. Their averaging window is probably<br>
significantly too long (N=144). It&#39;s:<br>
<br>
next_D = sum (past 144 D&#39;s) * T / sum(past 144 solvetimes)<br>
<br>
They correctly did not use max(timestamp) - min(timestamp) in the<br>
denominator like others do.<br>
<br>
They&#39;ve written the code and they&#39;re about to use it live, so Bitcoin<br>
will have a clear, simple, and tested path if it suddenly needs to<br>
hard fork due to having 20x delays for the next 2000 blocks (taking it<br>
a year to get unstuck).<br>
<br>
Details on it and the decision process:<br>
<a href="https://www.bitcoinabc.org/november" rel="noreferrer" target="_blank">https://www.bitcoinabc.org/<wbr>november</a><br>
<br>
It uses a nice median of 3 for the beginning and end of the window to<br>
help alleviate bad timestamp problems. It&#39;s nice, helps a little, but<br>
will also slow its response by 1 block.  They also have 2x and 1/2<br>
limits on the adjustment per block, which is a lot more than they will<br>
ever need.<br>
<br>
I recommend bitcoin consider using it and making it N=50 instead of 144.<br>
<br>
I have seen that any attempts to modify the above with things like a<br>
low pass filter, starting the window at MTP, or preventing negative<br>
timestamps will only reduce its effectiveness. Bitcoin&#39;s +12 and -6<br>
limits on the timestamps are sufficient and well chosen, although<br>
something a bit smaller than the +12 might have been better.<br>
<br>
One of the contenders to the above is new and actually better, devised<br>
by Degnr8 and they call it D622 or wt-144.It&#39;s a little better than<br>
they realize. It&#39;s the only real improvement in difficulty algorithms<br>
since the rolling average.  It gives a linearly higher weight to the<br>
more recent timestamps. Otherwise it is the same. Others have probably<br>
come across it, but there is too much noise in difficulty algorithms<br>
to find the good ones.<br>
<br>
# Degnr8&#39;s D622 difficulty algorithm<br>
# T=TargetTime, S=Solvetime<br>
# modified by zawy<br>
for i = 1 to N  (from oldest to most recent block)<br>
    t += T[i] / D[i] * i<br>
    j += i<br>
next i<br>
next_D = j / t * T<br>
<br>
I believe any modification to the above strict mathematical weighted<br>
average will reduce it&#39;s effectiveness. It does not oscillate anymore<br>
than regular algos and rises faster and drops faster, when needed.<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div></div>