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
|
Return-Path: <dave@hashingit.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BAD7C2A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2016 18:30:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from heron.directrouter.co.uk (heron.directrouter.co.uk
[89.145.69.228])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA37F198
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Mar 2016 18:30:22 +0000 (UTC)
Received: from host81-151-121-25.range81-151.btcentralplus.com
([81.151.121.25]:53690 helo=[192.168.1.82])
by heron.directrouter.co.uk with esmtpsa
(TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_1)
(envelope-from <dave@hashingit.com>)
id 1adisG-0022HS-7u; Wed, 09 Mar 2016 18:30:20 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dave Hudson <dave@hashingit.com>
In-Reply-To: <20160308220507.GA4388@mcelrath.org>
Date: Wed, 9 Mar 2016 18:30:19 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <26355E0C-1DDC-4CBD-A044-788C9C135EA6@hashingit.com>
References: <201603021456.15820.luke@dashjr.org>
<5E6E8EFD-2BC0-47F6-8005-5A63821C4276@hashingit.com>
<20160308220507.GA4388@mcelrath.org>
To: Bob McElrath <bob_bitcoin@mcelrath.org>
X-Mailer: Apple Mail (2.3112)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - heron.directrouter.co.uk
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hashingit.com
X-Get-Message-Sender-Via: heron.directrouter.co.uk: authenticated_id:
dave@hashingit.com
X-Authenticated-Sender: heron.directrouter.co.uk: dave@hashingit.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
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 18:39:10 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
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 18:30:23 -0000
A damping-based design would seem like the obvious choice (I can think =
of a few variations on a theme here, but most are found in the realms of =
control theory somewhere). The problem, though, is working working out =
a timeframe over which to run the derivative calculations.
The problem is the measurement of the hashrate, which is pretty =
inaccurate at best because even 2016 events isn't really enough (with a =
completely constant hash rate running indefinitely we'd see difficulty =
swings of up to +/- 5% even with the current algorithm). In order to =
meaningfully react to a major loss of hashing we'd still need to be =
considering a window of probably 2 weeks.
My other concern is that if we allow quick retargets to lower =
difficulties then that seems likely to expose the chain to being gamed. =
I'd need to think about this some more, but a few scenarios I was =
thinking about earlier this week appeared to risk making some types of =
selfish mining strategies quite a lot more profitable.
With all this said though I'll be very surprised if there's a huge drop =
in the hash rate come July. The hash rate has jumped up by almost 70% =
in the last 6 to 7 months and that implies some pretty serious =
investments by miners who are quite aware of the halving. My guess is =
that quite a lot of the baseline 30% has also been replaced in the same =
cycle. These same miners were mining with a coin price around $250 last =
year so in terms of profitability I'm pretty sure that one around $400 =
won't be a huge concern.
I'm sure that there will be some very public "I'm done with mining" =
announcements from a few smaller miners come July, but I suspect the =
bulk of the network will have a relatively small blip and continue on =
its way.
Cheers,
Dave
> On 8 Mar 2016, at 22:05, Bob McElrath <bob_bitcoin@mcelrath.org> =
wrote:
>=20
> 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.
>=20
> 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:
>=20
> =
http://mathworld.wolfram.com/CriticallyDampedSimpleHarmonicMotion.html
>=20
> 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. =20
>=20
> 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.
>=20
> 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.
>=20
> If solving this problem is deemed desirable, I can put some time into =
this, or
> direct others as to how to go about it.
>=20
> --
> Cheers, Bob McElrath
>=20
> "For every complex problem, there is a solution that is simple, neat, =
and wrong."
> -- H. L. Mencken=20
>=20
|
