MIME-Version: 1.0
In-Reply-To: <CADtTMvn8=uqCwwtvrqjLuN_6ADt+65YpEffSqnBozmWXWO--9A@mail.gmail.com>
References: <CADtTMvn8=uqCwwtvrqjLuN_6ADt+65YpEffSqnBozmWXWO--9A@mail.gmail.com>
From: CryptAxe <cryptaxe@gmail.com>
Date: Thu, 2 Nov 2017 16:39:41 -0700
Message-ID: <CAF5CFkhTU9j6wWv+-wKkCaX65fwZSYsMNGf_nAwb+vwPtsbkYQ@mail.gmail.com>
To: Scott Roberts <wordsgalore@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045c37a0a02a13055d0880e2"
Subject: Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm
Precedence: list

--f403045c37a0a02a13055d0880e2
Content-Type: text/plain; charset="UTF-8"

Is there an issue with the current difficulty adjustment algorithm? It's
worked very well as far as I can tell. Introducing a new one seems pretty
risky, what would the benefit be?

On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin cash will hard fork on Nov 13 to implement a new difficulty
> algorithm.  Bitcoin itself might need to hard fork to employ a similar
> algorithm. It's about as good as they come because it followed the
> "simplest is best" route. Their averaging window is probably
> significantly too long (N=144). It's:
>
> next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)
>
> They correctly did not use max(timestamp) - min(timestamp) in the
> denominator like others do.
>
> They've written the code and they're about to use it live, so Bitcoin
> will have a clear, simple, and tested path if it suddenly needs to
> hard fork due to having 20x delays for the next 2000 blocks (taking it
> a year to get unstuck).
>
> Details on it and the decision process:
> https://www.bitcoinabc.org/november
>
> It uses a nice median of 3 for the beginning and end of the window to
> help alleviate bad timestamp problems. It's nice, helps a little, but
> will also slow its response by 1 block.  They also have 2x and 1/2
> limits on the adjustment per block, which is a lot more than they will
> ever need.
>
> I recommend bitcoin consider using it and making it N=50 instead of 144.
>
> I have seen that any attempts to modify the above with things like a
> low pass filter, starting the window at MTP, or preventing negative
> timestamps will only reduce its effectiveness. Bitcoin's +12 and -6
> limits on the timestamps are sufficient and well chosen, although
> something a bit smaller than the +12 might have been better.
>
> One of the contenders to the above is new and actually better, devised
> by Degnr8 and they call it D622 or wt-144.It's a little better than
> they realize. It's the only real improvement in difficulty algorithms
> since the rolling average.  It gives a linearly higher weight to the
> more recent timestamps. Otherwise it is the same. Others have probably
> come across it, but there is too much noise in difficulty algorithms
> to find the good ones.
>
> # Degnr8's D622 difficulty algorithm
> # T=TargetTime, S=Solvetime
> # modified by zawy
> for i = 1 to N  (from oldest to most recent block)
>     t += T[i] / D[i] * i
>     j += i
> next i
> next_D = j / t * T
>
> I believe any modification to the above strict mathematical weighted
> average will reduce it's effectiveness. It does not oscillate anymore
> than regular algos and rises faster and drops faster, when needed.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--f403045c37a0a02a13055d0880e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><span style=3D"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=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Nov 2, 2017 4:34 PM, &quot;Scott Roberts via bitcoin-dev&quo=
t; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">Bitcoin cash will hard fork on Nov 13 to implement a =
new difficulty<br>
algorithm.=C2=A0 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=3D144). It&#39;s:<br>
<br>
next_D =3D 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 Bitco=
in<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=3D"https://www.bitcoinabc.org/november" rel=3D"noreferrer" target=
=3D"_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<b=
r>
will also slow its response by 1 block.=C2=A0 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=3D50 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<b=
r>
since the rolling average.=C2=A0 It gives a linearly higher weight to the<b=
r>
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=3DTargetTime, S=3DSolvetime<br>
# modified by zawy<br>
for i =3D 1 to N=C2=A0 (from oldest to most recent block)<br>
=C2=A0 =C2=A0 t +=3D T[i] / D[i] * i<br>
=C2=A0 =C2=A0 j +=3D i<br>
next i<br>
next_D =3D 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<b=
r>
than regular algos and rises faster and drops faster, when needed.<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div></div>

--f403045c37a0a02a13055d0880e2--