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
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
Return-Path: <daniele.pinna@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1C508CC9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2016 01:27:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com
[209.85.213.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F17B413F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2016 01:27:42 +0000 (UTC)
Received: by mail-vk0-f42.google.com with SMTP id e6so39078915vkh.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Mar 2016 17:27:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=ZqkccuGYVGpN4YXAGZHLZsvE5FmnGAgSO+S87WZDmqQ=;
b=JGXsjbMYt1SEVZizGFetVOdj1GFDoRGAr7sQGVdh0mmCGwi65x3Kmn2eC7U9NndI6D
ToMeD7SHPxWTKfeq8lxPLahpC4b/H2y+cCNeKJYKFN7YJ8inOBfBXcHXEMiZJxH2RxQl
VTqhAMRA3ImLrGWuaasT4NRxQ39dOx3+SltjeTEBgjeArn+T4wVuzoy1HtlpuS/kkWJI
TLkpv1JmkUIQTDkAcaSmaXRpTY/WF/WZfudsVHpxmW6ZTdj2pd1iSUhG+lPmPs1cqlRs
r7tQR9DpvgrFRva8x20P3zkZulZ2/zfnc3BIq9lt7SduUxehCyCs63mrcBfQr1chwtos
1uOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=ZqkccuGYVGpN4YXAGZHLZsvE5FmnGAgSO+S87WZDmqQ=;
b=J8wj8rekFNqzC65CXWsA5DGV6k4tcTIydOGcOoM9cNYrcHKIQvRO7BNhWHgR5RJS55
4NdPZ/mL5cTi1ilphhVSKpAE7MhCucfvqrb2fh2LYNTYdJJpfUb3tZ9eVl/fVToJ1NEs
ljmuTpK3enE+xf1Ywa/5ceY2CW+ZsQ/d007rQ3KSessajPx9t7Fp/HPK+SceArT6LIXT
P9H8KGvvqQ+asSlAF902sdtY+l+V4QUhFfpBo4OvPe6g6W04EFFzx8QvAJ9JJMzQmHW4
l+XwQ/+HfvZ282G64Q8RlqKqQLzQCXyNnuVWb8NL05/goclez+kRxdCHw5rZYTdcyMnu
h34A==
X-Gm-Message-State: AD7BkJKIhoOD4Hyn7JMfEtIai/gY8X+dlwLHOFj+vzNRkYl2ZTkGLMqa3O3StnJOiLyEsuyQvPhry984Ck2XFw==
X-Received: by 10.31.133.7 with SMTP id h7mr28826366vkd.32.1457486862027; Tue,
08 Mar 2016 17:27:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.106.65 with HTTP; Tue, 8 Mar 2016 17:27:22 -0800 (PST)
In-Reply-To: <mailman.6363.1457481624.1673.bitcoin-dev@lists.linuxfoundation.org>
References: <mailman.6363.1457481624.1673.bitcoin-dev@lists.linuxfoundation.org>
From: Daniele Pinna <daniele.pinna@gmail.com>
Date: Wed, 9 Mar 2016 02:27:22 +0100
Message-ID: <CAEgR2PFByXpd5C7X2NUJYt+UE3ji6dd6M5LfZGQvg-QQV7fLnw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114123c6ad12b9052d939ae2
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 09 Mar 2016 05:44:06 +0000
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 10, Issue 13
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 09 Mar 2016 01:27:44 -0000
--001a114123c6ad12b9052d939ae2
Content-Type: text/plain; charset=UTF-8
This seems unnecessarily complicated ("don't use cannon to kill mosquito"
kind of thing). If the community were interested in a realtime hashrate
rebalancing proposal one could simply adjust difficulty at each new block
using the current method.
If faster relaxation in case of adversity is required, it suspect that it
would suffice to perform a weighted average of the previous 2016 blocks
instead of the standard averaging that is currently done. It should be
possible to find an optimal weighting based on historical interblock timing
data. I look into it over the next couple of days.
dpinna
> ------------------------------
>
> Message: 3
> Date: Tue, 8 Mar 2016 22:05:07 +0000
> From: Bob McElrath <bob_bitcoin@mcelrath.org>
> To: Dave Hudson <dave@hashingit.com>
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
> Message-ID: <20160308220507.GA4388@mcelrath.org>
> Content-Type: text/plain; charset=us-ascii
>
> Dave Hudson via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote:
> > I think the biggest question here would be how would the difficulty
> > retargeting be changed? Without seeing the algorithm proposal it's
> difficult
> > to assess the impact that it would have, but my intuition is that this is
> > likely to be problematic.
>
> I have no comment on whether this will be *needed* but there's a simple
> algorithm that I haven't seen any coin adopt, that I think needs to be: the
> critically damped harmonic oscillator:
>
> http://mathworld.wolfram.com/CriticallyDampedSimpleHarmonicMotion.html
>
> In dynamical systems one does a derivative expansion. Here we want to
> find the
> first and second derivatives (in time) of the hashrate. These can be
> determined
> by a method of finite differences, or fancier algorithms which use a
> quadratic
> or quartic polynomial approximation. Two derivatives are generally all
> that is
> needed, and the resulting dynamical system is a damped harmonic oscillator.
>
> A damped harmonic oscillator is basically how your car's shock absorbers
> work.
> The relevant differential equation has two parameters: the oscillation
> frequency
> and damping factor. The maximum oscillation frequency is the block rate.
> Any
> oscillation faster than the block rate cannot be measured by block times.
> The
> damping rate is an exponential decay and for critical damping is twice the
> oscillation frequency.
>
> So, this is a zero parameter, optimal damping solution for a varying
> hashrate.
> This is inherently a numeric approximation solution to a differential
> equation,
> so questions of approximations for the hashrate enter, but that's all.
> Weak
> block proposals will be able to get better approximations to the hashrate.
>
> If solving this problem is deemed desirable, I can put some time into
> this, or
> direct others as to how to go about it.
>
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and
> wrong."
> -- H. L. Mencken
>
>
--001a114123c6ad12b9052d939ae2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>This seems unnecessarily complicated ("don't use cannon to kill m=
osquito" kind of thing). If the community were interested in a realtim=
e hashrate rebalancing proposal one could simply adjust difficulty at each =
new block using the current method. <br><br>If faster relaxation in case of=
adversity is required, it suspect that it would suffice to perform a weigh=
ted average of the previous 2016 blocks instead of the standard averaging t=
hat is currently done. It should be possible to find an optimal weighting b=
ased on historical interblock timing data. I look into it over the next cou=
ple of days.<br></div><div><br></div><div>dpinna</div><div><br></div><div><=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 8 Mar 2016 22:05:07 +0000<br>
From: Bob McElrath <<a href=3D"mailto:bob_bitcoin@mcelrath.org">bob_bitc=
oin@mcelrath.org</a>><br>
To: Dave Hudson <<a href=3D"mailto:dave@hashingit.com">dave@hashingit.co=
m</a>><br>
Cc: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm<br>
Message-ID: <<a href=3D"mailto:20160308220507.GA4388@mcelrath.org">20160=
308220507.GA4388@mcelrath.org</a>><br>
Content-Type: text/plain; charset=3Dus-ascii<br>
<br>
Dave Hudson via bitcoin-dev [<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>] wrote:<br>
> I think the biggest question here would be how would the difficulty<br=
>
> retargeting be changed?=C2=A0 Without seeing the algorithm proposal it=
's difficult<br>
> to assess the impact that it would have, but my intuition is that this=
is<br>
> likely to be problematic.<br>
<br>
I have no comment on whether this will be *needed* but there's a simple=
<br>
algorithm that I haven't seen any coin adopt, that I think needs to be:=
the<br>
critically damped harmonic oscillator:<br>
<br>
=C2=A0 =C2=A0 <a href=3D"http://mathworld.wolfram.com/CriticallyDampedSimpl=
eHarmonicMotion.html" rel=3D"noreferrer" target=3D"_blank">http://mathworld=
.wolfram.com/CriticallyDampedSimpleHarmonicMotion.html</a><br>
<br>
In dynamical systems one does a derivative expansion.=C2=A0 Here we want to=
find the<br>
first and second derivatives (in time) of the hashrate.=C2=A0 These can be =
determined<br>
by a method of finite differences, or fancier algorithms which use a quadra=
tic<br>
or quartic polynomial approximation.=C2=A0 Two derivatives are generally al=
l that is<br>
needed, and the resulting dynamical system is a damped harmonic oscillator.=
<br>
<br>
A damped harmonic oscillator is basically how your car's shock absorber=
s work.<br>
The relevant differential equation has two parameters: the oscillation freq=
uency<br>
and damping factor.=C2=A0 The maximum oscillation frequency is the block ra=
te.=C2=A0 Any<br>
oscillation faster than the block rate cannot be measured by block times.=
=C2=A0 The<br>
damping rate is an exponential decay and for critical damping is twice the<=
br>
oscillation frequency.<br>
<br>
So, this is a zero parameter, optimal damping solution for a varying hashra=
te.<br>
This is inherently a numeric approximation solution to a differential equat=
ion,<br>
so questions of approximations for the hashrate enter, but that's all.=
=C2=A0 Weak<br>
block proposals will be able to get better approximations to the hashrate.<=
br>
<br>
If solving this problem is deemed desirable, I can put some time into this,=
or<br>
direct others as to how to go about it.<br>
<br>
--<br>
Cheers, Bob McElrath<br>
<br>
"For every complex problem, there is a solution that is simple, neat, =
and wrong."<br>
=C2=A0 =C2=A0 -- H. L. Mencken<br><br></blockquote></div></div></div>
--001a114123c6ad12b9052d939ae2--
|
