path: root/e4/b8a58c5b63d9f302dd451866cdf80a43ca137b

Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3C1F794B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  4 Nov 2017 03:37:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com
	[209.85.215.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DD17355D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  4 Nov 2017 03:37:09 +0000 (UTC)
Received: by mail-lf0-f46.google.com with SMTP id w21so5146874lfc.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 03 Nov 2017 20:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=U15tploejis+rRCUDKptE/zmjYH4VNXvqUxef21n7ms=;
	b=CtYg33qsF1yWgACSjkDHl9l7A/STUZ4gtCSzI4FZfzOek5Kvbq6qDyBFnRjoQji5CL
	psCXUjc7BnasBhsPgEioyRo4IX2Sk4q9kiQ/Fm6W/ohpw/ePxxLygH9ZdSvwx5oQSR6p
	kJ8Q+Iklk+o9nB7A2vkeXUuqOpFQQDuytm7TfdbY4EAtWpV2r5hgyaxjztzFjEFXOLS/
	QjNoy2efDDPYr7OseFbfnsH2vUnxRU/nQO4boXNOU+GMLC2wSGS/qUVXkGXpqAz2QVi/
	M81bKWOnWtCOBy0g6KM3Xgy1UGQV0hKI5VMBM79Mg0qxhBk42q1R8Xh7nXuIsH4jwNRp
	VxZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=U15tploejis+rRCUDKptE/zmjYH4VNXvqUxef21n7ms=;
	b=re+KVSq4mq51uHyYxzVTOhZsDJ8qstpSkui1yhsW91g5X+8A0twQ4wrHZnJNe0gFBB
	rePsUavC+6RgzKqlOVEmTco90HqpzJMm5b8NuthbWs78hA1Vkyx8BeYHDQbfQgzUBmlm
	1+kh1MEGkxxKNqWIY7KeUH+p9hnJKf9nL9nUry0LtMnEh4TqHmxW5XvFUHFpRNRQTQz+
	mWV0Kemlgm/Ck0zFwW7zKJOD8d/Np5gmii5OjtzvXutXjn3B3j2WAei6C9Ua7u2dLYt/
	qx3+aYjztuK//2oK/cxVRxIZEtVmKbvtyscdfX30Ri5sQdbxHCn+xNZ4HqkiwbZtL5X/
	EALQ==
X-Gm-Message-State: AJaThX58X182iVCRW0o8tGqCsSh37fBX96yNbte6rvKbrnvw9u5L3rBE
	EoLkyncZSRBIKpt8rvJ9nTbbx2tZWB+XCLuPl+4=
X-Google-Smtp-Source: ABhQp+QRlJmrYJtkZ7+OJ61XzGcKMLJkRjnbfN9LNxhRz7Q7cilZC4Ij/01GawGT+0NouygQN4P+KgzOwF0F4vhoAvA=
X-Received: by 10.25.78.10 with SMTP id c10mr3398758lfb.4.1509766628307; Fri,
	03 Nov 2017 20:37:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.168.7 with HTTP; Fri, 3 Nov 2017 20:37:06 -0700 (PDT)
Received: by 10.25.168.7 with HTTP; Fri, 3 Nov 2017 20:37:06 -0700 (PDT)
In-Reply-To: <CADtTMvmffNZMrrxvBjc=_4+LDRvvXJuz84bFCESgB5LjCGnpKg@mail.gmail.com>
References: <CADtTMvn8=uqCwwtvrqjLuN_6ADt+65YpEffSqnBozmWXWO--9A@mail.gmail.com>
	<CAF5CFkhTU9j6wWv+-wKkCaX65fwZSYsMNGf_nAwb+vwPtsbkYQ@mail.gmail.com>
	<CADtTMvmffNZMrrxvBjc=_4+LDRvvXJuz84bFCESgB5LjCGnpKg@mail.gmail.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Fri, 3 Nov 2017 23:37:06 -0400
Message-ID: <CAAUaCyjzAHDndcWr07hbVrXS5Y8Cz7Dq_B7p7NqZ7i0VS=fM7Q@mail.gmail.com>
To: Scott Roberts <wordsgalore@gmail.com>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c1cdd8c92faea055d1fef89"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 04 Nov 2017 05:25:21 +0000
Subject: Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Nov 2017 03:37:11 -0000

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

I'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've been playing with that adjusts difficulty
every block, based only on the previous block's time and difficulty.  I
tested it a bit and it seems to adapt to hashrate swings pretty well.

weight_n = 1 - e^-(blocktime_n / 1 hr)    # 1 hr = exp moving avg window -
too short?
adj_n = (10 min / blocktime_n) - 1
difficulty_(n+1) = difficulty_n * (1 + weight_n * adj_n)

It could also be tweaked to make the *historical* avg block time ~exactly
10 minutes, ie, to target > 10 min if past blocks were < 10 min.  This
would, eg, make mapping future block numbers to calendar times much more
exact.


On Nov 3, 2017 7:24 AM, "Scott Roberts via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The current DA is only sufficient if the coin has the highest
> hashpower. It's also just really slow.  If miners somehow stick with
> SegWit2x despite the higher rewards in defecting back to bitcoin, then
> bitcoin will have long block delays. High transaction fees will
> probably help them defect back to us. But if SegWit2x manages to be
> more comparable in price than BCH (despite the futures), hashpower
> could very well oscillate back and forth between the two coins,
> causing delays in both of them. The first one to hard fork to fix the
> difficulty problem will have a large advantage, as evidenced by what
> happens in alts.   In any event someday BTC may not be the biggest kid
> on the block and will need a difficulty algorithm that alts would find
> acceptable. Few alts use anything like BTC's because they are not able
> to survive the resulting long delays.   I am recommending BTC
> developers watch what happens as BCH goes live with a much better
> algorithm, in case BTC needs to hard fork for the same reason and
> needs a similar fix. Ignore the trolls.
>
> On Thu, Nov 2, 2017 at 7:39 PM, CryptAxe <cryptaxe@gmail.com> wrote:
> > 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto"><div dir=3D"auto">I&#39;m no BCH fan, but I agree with Sc=
ott that changes to the DAA may be of more than purely theoretical interest=
 for BTC.=C2=A0 Anyway just for those interested, below is an algo I&#39;ve=
 been playing with that adjusts difficulty every block, based only on the p=
revious block&#39;s time and difficulty.=C2=A0 I tested it a bit and it see=
ms to adapt to hashrate swings pretty well.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">weight_n =3D 1 - e^-(blocktime_n / 1 hr)=C2=A0 =C2=A0 #=
 1 hr =3D exp moving avg window - too short?</div><div dir=3D"auto">adj_n =
=3D (10 min / blocktime_n) - 1</div><div dir=3D"auto"><span style=3D"font-f=
amily:sans-serif">difficulty_(n+1) =3D difficulty_n * (1 + weight_n * adj_n=
)</span><br></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">=
<br></span></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">I=
t could also be tweaked to make the <i>historical</i> avg block time ~exact=
ly 10 minutes, ie, to target &gt; 10 min if past blocks were &lt; 10 min.=
=C2=A0 This would, eg, make mapping future block numbers to calendar times =
much more exact.</span></div><div dir=3D"auto"><span style=3D"font-family:s=
ans-serif"><br></span></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Nov 3, 2017 7:24 AM, &quot;Scott Roberts via bitcoin-de=
v&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">The current DA is only sufficient if the coin ha=
s the highest<br>
hashpower. It&#39;s also just really slow.=C2=A0 If miners somehow stick wi=
th<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.=C2=A0 =C2=A0In any event someday BTC may not be the bigges=
t 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.=C2=A0 =C2=A0I 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=3D"mailto:cryptaxe@gma=
il.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 pre=
tty<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=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@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 difficult=
y<br>
&gt;&gt; algorithm.=C2=A0 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 prob=
ably<br>
&gt;&gt; significantly too long (N=3D144). It&#39;s:<br>
&gt;&gt;<br>
&gt;&gt; next_D =3D sum (past 144 D&#39;s) * T / sum(past 144 solvetimes)<b=
r>
&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 (takin=
g 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=3D"https://www.bitcoinabc.org/november" rel=3D"noreferrer"=
 target=3D"_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 litt=
le, but<br>
&gt;&gt; will also slow its response by 1 block.=C2=A0 They also have 2x an=
d 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=3D50 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 negativ=
e<br>
&gt;&gt; timestamps will only reduce its effectiveness. Bitcoin&#39;s +12 a=
nd -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, dev=
ised<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 alg=
orithms<br>
&gt;&gt; since the rolling average.=C2=A0 It gives a linearly higher weight=
 to the<br>
&gt;&gt; more recent timestamps. Otherwise it is the same. Others have prob=
ably<br>
&gt;&gt; come across it, but there is too much noise in difficulty algorith=
ms<br>
&gt;&gt; to find the good ones.<br>
&gt;&gt;<br>
&gt;&gt; # Degnr8&#39;s D622 difficulty algorithm<br>
&gt;&gt; # T=3DTargetTime, S=3DSolvetime<br>
&gt;&gt; # modified by zawy<br>
&gt;&gt; for i =3D 1 to N=C2=A0 (from oldest to most recent block)<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0t +=3D T[i] / D[i] * i<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0j +=3D i<br>
&gt;&gt; next i<br>
&gt;&gt; next_D =3D j / t * T<br>
&gt;&gt;<br>
&gt;&gt; I believe any modification to the above strict mathematical weight=
ed<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=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><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>

--94eb2c1cdd8c92faea055d1fef89--