<div dir="auto"><div dir="auto">I&#39;m no BCH fan, but I agree with Scott that changes to the DAA may be of more than purely theoretical interest for BTC.  Anyway just for those interested, below is an algo I&#39;ve been playing with that adjusts difficulty every block, based only on the previous block&#39;s time and difficulty.  I tested it a bit and it seems to adapt to hashrate swings pretty well.</div><div dir="auto"><br></div><div dir="auto">weight_n = 1 - e^-(blocktime_n / 1 hr)    # 1 hr = exp moving avg window - too short?</div><div dir="auto">adj_n = (10 min / blocktime_n) - 1</div><div dir="auto"><span style="font-family:sans-serif">difficulty_(n+1) = difficulty_n * (1 + weight_n * adj_n)</span><br></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">It could also be tweaked to make the <i>historical</i> avg block time ~exactly 10 minutes, ie, to target &gt; 10 min if past blocks were &lt; 10 min.  This would, eg, make mapping future block numbers to calendar times much more exact.</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 3, 2017 7:24 AM, &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">The current DA is only sufficient if the coin has the highest<br>
hashpower. It&#39;s also just really slow.  If miners somehow stick with<br>
SegWit2x despite the higher rewards in defecting back to bitcoin, then<br>
bitcoin will have long block delays. High transaction fees will<br>
probably help them defect back to us. But if SegWit2x manages to be<br>
more comparable in price than BCH (despite the futures), hashpower<br>
could very well oscillate back and forth between the two coins,<br>
causing delays in both of them. The first one to hard fork to fix the<br>
difficulty problem will have a large advantage, as evidenced by what<br>
happens in alts.   In any event someday BTC may not be the biggest kid<br>
on the block and will need a difficulty algorithm that alts would find<br>
acceptable. Few alts use anything like BTC&#39;s because they are not able<br>
to survive the resulting long delays.   I am recommending BTC<br>
developers watch what happens as BCH goes live with a much better<br>
algorithm, in case BTC needs to hard fork for the same reason and<br>
needs a similar fix. Ignore the trolls.<br>
<br>
On Thu, Nov 2, 2017 at 7:39 PM, CryptAxe &lt;<a href="mailto:cryptaxe@gmail.com">cryptaxe@gmail.com</a>&gt; wrote:<br>
&gt; Is there an issue with the current difficulty adjustment algorithm? It&#39;s<br>
&gt; worked very well as far as I can tell. Introducing a new one seems pretty<br>
&gt; risky, what would the benefit be?<br>
&gt;<br>
&gt; On Nov 2, 2017 4:34 PM, &quot;Scott Roberts via bitcoin-dev&quot;<br>
&gt; &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Bitcoin cash will hard fork on Nov 13 to implement a new difficulty<br>
&gt;&gt; algorithm.  Bitcoin itself might need to hard fork to employ a similar<br>
&gt;&gt; algorithm. It&#39;s about as good as they come because it followed the<br>
&gt;&gt; &quot;simplest is best&quot; route. Their averaging window is probably<br>
&gt;&gt; significantly too long (N=144). It&#39;s:<br>
&gt;&gt;<br>
&gt;&gt; next_D = sum (past 144 D&#39;s) * T / sum(past 144 solvetimes)<br>
&gt;&gt;<br>
&gt;&gt; They correctly did not use max(timestamp) - min(timestamp) in the<br>
&gt;&gt; denominator like others do.<br>
&gt;&gt;<br>
&gt;&gt; They&#39;ve written the code and they&#39;re about to use it live, so Bitcoin<br>
&gt;&gt; will have a clear, simple, and tested path if it suddenly needs to<br>
&gt;&gt; hard fork due to having 20x delays for the next 2000 blocks (taking it<br>
&gt;&gt; a year to get unstuck).<br>
&gt;&gt;<br>
&gt;&gt; Details on it and the decision process:<br>
&gt;&gt; <a href="https://www.bitcoinabc.org/november" rel="noreferrer" target="_blank">https://www.bitcoinabc.org/<wbr>november</a><br>
&gt;&gt;<br>
&gt;&gt; It uses a nice median of 3 for the beginning and end of the window to<br>
&gt;&gt; help alleviate bad timestamp problems. It&#39;s nice, helps a little, but<br>
&gt;&gt; will also slow its response by 1 block.  They also have 2x and 1/2<br>
&gt;&gt; limits on the adjustment per block, which is a lot more than they will<br>
&gt;&gt; ever need.<br>
&gt;&gt;<br>
&gt;&gt; I recommend bitcoin consider using it and making it N=50 instead of 144.<br>
&gt;&gt;<br>
&gt;&gt; I have seen that any attempts to modify the above with things like a<br>
&gt;&gt; low pass filter, starting the window at MTP, or preventing negative<br>
&gt;&gt; timestamps will only reduce its effectiveness. Bitcoin&#39;s +12 and -6<br>
&gt;&gt; limits on the timestamps are sufficient and well chosen, although<br>
&gt;&gt; something a bit smaller than the +12 might have been better.<br>
&gt;&gt;<br>
&gt;&gt; One of the contenders to the above is new and actually better, devised<br>
&gt;&gt; by Degnr8 and they call it D622 or wt-144.It&#39;s a little better than<br>
&gt;&gt; they realize. It&#39;s the only real improvement in difficulty algorithms<br>
&gt;&gt; since the rolling average.  It gives a linearly higher weight to the<br>
&gt;&gt; more recent timestamps. Otherwise it is the same. Others have probably<br>
&gt;&gt; come across it, but there is too much noise in difficulty algorithms<br>
&gt;&gt; to find the good ones.<br>
&gt;&gt;<br>
&gt;&gt; # Degnr8&#39;s D622 difficulty algorithm<br>
&gt;&gt; # T=TargetTime, S=Solvetime<br>
&gt;&gt; # modified by zawy<br>
&gt;&gt; for i = 1 to N  (from oldest to most recent block)<br>
&gt;&gt;     t += T[i] / D[i] * i<br>
&gt;&gt;     j += i<br>
&gt;&gt; next i<br>
&gt;&gt; next_D = j / t * T<br>
&gt;&gt;<br>
&gt;&gt; I believe any modification to the above strict mathematical weighted<br>
&gt;&gt; average will reduce it&#39;s effectiveness. It does not oscillate anymore<br>
&gt;&gt; than regular algos and rises faster and drops faster, when needed.<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <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>
______________________________<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>