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
|
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 78CCCBCE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Mar 2016 16:08:14 +0000 (UTC)
X-Greylist: delayed 00:19:45 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 2A878190
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Mar 2016 16:08:12 +0000 (UTC)
Received: from host86-158-172-81.range86-158.btcentralplus.com
([86.158.172.81]:58492 helo=[192.168.1.82])
by heron.directrouter.co.uk with esmtpsa
(TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86)
(envelope-from <dave@hashingit.com>)
id 1ab90i-001486-CP; Wed, 02 Mar 2016 15:48:24 +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: <201603021456.15820.luke@dashjr.org>
Date: Wed, 2 Mar 2016 15:48:21 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E6E8EFD-2BC0-47F6-8005-5A63821C4276@hashingit.com>
References: <201603021456.15820.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.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, 02 Mar 2016 16:10:01 +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, 02 Mar 2016 16:08:14 -0000
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.
Probabilistically the network sees surprisingly frequent swings of =
+/-20% in terms of the block finding rate on any given day, while the =
statistical noise over a 2016 block period can be more than +/-5%. Any =
change would still have to require a fairly significant period of time =
before there would be a reasonable level of confidence that the hash =
rate really had fallen as opposed to just seeing statistical noise =
(http://hashingit.com/analysis/29-lies-damned-lies-and-bitcoin-difficultie=
s and http://hashingit.com/analysis/28-reach-for-the-ear-defenders).
How long would be required to deem that the hash rate had dramatically =
fallen? Would such a change be a one-time event or would it be =
ever-present?
If we were to say that if the hash rate dropped 50% in one day (which =
could, of course be a 30% real drop and 20% variance) and the difficulty =
was retargeted to 50% lower then that would have to be matched with a =
similar rapid retarget if it were to increase by a similar amount. =
Failing to do this both ways this would introduce an economic incentive =
for large miners to suppress the difficulty and gain dramatically larger =
numbers of block rewards. The current fixed block count per difficulty =
change prevents this because the daily losses while suppressing hashing =
outweigh the potential gains when it's re-added.
Cheers,
Dave
> On 2 Mar 2016, at 14:56, Luke Dashjr via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> We are coming up on the subsidy halving this July, and there have been =
some=20
> concerns raised that a non-trivial number of miners could potentially =
drop off=20
> the network. This would result in a significantly longer block =
interval, which=20
> also means a higher per-block transaction volume, which could cause =
the block=20
> size limit to legitimately be hit much sooner than expected. =
Furthermore, due=20
> to difficulty adjustment being measured exclusively in blocks, the =
time until=20
> it adjusts to compensate would be prolonged.
>=20
> For example, if 50% of miners dropped off the network, blocks would be =
every=20
> 20 minutes on average and contain double the transactions they =
presently do.=20
> Even double would be approximately 850-900k, which potentially bumps =
up=20
> against the hard limit when empty blocks are taken into consideration. =
This=20
> situation would continue for a full month if no changes are made. If =
more=20
> miners drop off the network, most of this becomes linearly worse, but =
due to=20
> hitting the block size limit, the backlog would grow indefinitely =
until the=20
> adjustment occurs.
>=20
> To alleviate this risk, it seems reasonable to propose a hardfork to =
the=20
> difficulty adjustment algorithm so it can adapt quicker to such a =
significant=20
> drop in mining rate. BtcDrak tells me he has well-tested code for this =
in his=20
> altcoin, which has seen some roller-coaster hashrates, so it may even =
be=20
> possible to have such a proposal ready in time to be deployed =
alongside SegWit=20
> to take effect in time for the upcoming subsidy halving. If this =
slips, I=20
> think it may be reasonable to push for at least code-readiness before =
July,=20
> and possibly roll it into any other hardfork proposed before or around =
that=20
> time.
>=20
> I am unaware of any reason this would be controversial, so if anyone =
has a=20
> problem with such a change, please speak up sooner rather than later. =
Other=20
> ideas or concerns are of course welcome as well.
>=20
> Thanks,
>=20
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
