From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 38A6994B for ; Thu, 2 Nov 2017 23:39:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F36E483 for ; Thu, 2 Nov 2017 23:39:43 +0000 (UTC) Received: by mail-wr0-f169.google.com with SMTP id u40so1038432wrf.10 for ; Thu, 02 Nov 2017 16:39:43 -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; bh=ymqaDtNlkTab7BmIlkuL30GlmAJVvXfixmv+TqTbn3U=; b=WeoYEyBF2ctoeqD0Fqkqdr2616RSc2aa8qUS1Xnlla/ZKlGMTBwskHbKtY7U4SgsLF GHrQLa3c7UhooHDfrM82nyw4Hxn+WSjgnxEBb8AdQ2MDZU2iI1mKn48mXGAL0F1ElGDu edp7Z2U035g7SCRSwx2Z1cotvNJwUKo7jgZidkM3lrvMckrjUiYsO/AYaLxmOp2xATJs eJCiJ+yfpEn9kNV2p+dxR0SGb/11Q78iYWMIzYKkUzBI8Sai7Py0QV9DnWrEGj6Om7bX KLEug5mt853i6K++Dy58a9miACZNf/cTzMJbWHae8xd9gYS7WilouGdPETbN5eE+qv32 F/zQ== 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; bh=ymqaDtNlkTab7BmIlkuL30GlmAJVvXfixmv+TqTbn3U=; b=n1hDdlyIVXVSe6cok2wvw5+1vv82GyyC+5lLBdmn3qFELAFZzmoQD+1zFTC0RFtt4n 7E6J2ZMuXeXkPY7ZILMwKJGuRrbCQz2/+6fa+6/wuJnzpZdZejASImhdHECgNQn2Pdwy 3+/ERG5XVnj6DsDLHxAZeMQjND3L/TTPZX2yqUM0b/bxlpiTx9/oYe7MeCcBwTFweTbY xXmP83KuhHuz1b3qPY6I4ZZtF8PS3817Bvzmd14Ll9eSfQ0TnJFoomoN6h4nJG2phRmj n/RpAlPXxaxHMMuGVb1X4GDPBHkRZvQ/yzuDCxX2GGGypruazbT4k+/ZCBjfhGtnQYl4 1f1w== X-Gm-Message-State: AMCzsaVMdcvDYKcpeCQ9J3KOfXImXFrqqQayxZl2/MPbW1BhXp02uP33 fyv+k4rNNZqUzB7u8Rcis6CgSu7/wj/OIvz57+zGnQ== X-Google-Smtp-Source: ABhQp+SeyeMapyvM9nFPwa7NbJQ78vIKesneMdLwstMzLA54HxAImWYhOkCj+JEqjprErEodRwyDysrF8tNJqhdwAEQ= X-Received: by 10.223.195.110 with SMTP id e43mr4037594wrg.219.1509665982653; Thu, 02 Nov 2017 16:39:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.196.79 with HTTP; Thu, 2 Nov 2017 16:39:41 -0700 (PDT) Received: by 10.28.196.79 with HTTP; Thu, 2 Nov 2017 16:39:41 -0700 (PDT) In-Reply-To: References: From: CryptAxe Date: Thu, 2 Nov 2017 16:39:41 -0700 Message-ID: To: Scott Roberts , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="f403045c37a0a02a13055d0880e2" 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: Thu, 02 Nov 2017 23:40:35 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 23:39:45 -0000 --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
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&quo= t; <bitcoin-dev= @lists.linuxfoundation.org> wrote:
Bitcoin cash will hard fork on Nov 13 to implement a = new difficulty
algorithm.=C2=A0 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=3D144). It's:

next_D =3D 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 Bitco= in
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.=C2=A0 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=3D50 instead of 144.<= br>
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.=C2=A0 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=3DTargetTime, S=3DSolvetime
# modified by zawy
for i =3D 1 to N=C2=A0 (from oldest to most recent block)
=C2=A0 =C2=A0 t +=3D T[i] / D[i] * i
=C2=A0 =C2=A0 j +=3D i
next i
next_D =3D 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--