1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
Return-Path: <cryptaxe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 38A6994B
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Nov 2017 23:39:43 +0000 (UTC)
Received: by mail-wr0-f169.google.com with SMTP id u40so1038432wrf.10
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <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"
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 <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: 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
<div dir=3D"auto"><span style=3D"font-family:sans-serif">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?</span></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev&quo=
t; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev=
@lists.linuxfoundation.org</a>> 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's about as good as they come because it followed the<br>
"simplest is best" route. Their averaging window is probably<br>
significantly too long (N=3D144). It's:<br>
<br>
next_D =3D sum (past 144 D'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've written the code and they'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'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'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's a little better than<br>
they realize. It'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'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'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--
|
