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
|
Return-Path: <dave@dtrt.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2DEE2CCE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Mar 2016 19:35:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.dtrt.org (mail.dtrt.org [207.192.75.234])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A76D912A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Mar 2016 19:35:35 +0000 (UTC)
Received: from harding by mail.dtrt.org with local (Exim 4.72)
(envelope-from <dave@dtrt.org>)
id 1abCYV-0000Co-Fd; Wed, 02 Mar 2016 14:35:31 -0500
Date: Wed, 2 Mar 2016 14:34:33 -0500
From: "David A. Harding" <dave@dtrt.org>
To: Gregory Maxwell <greg@xiph.org>
Message-ID: <20160302193433.GA5990@localhost.localdomain>
References: <201603021456.15820.luke@dashjr.org>
<20160302171418.GA5312@localhost.localdomain>
<CAAS2fgQVreFoLiHf8NhHLbT8wpSBO4WHHRU10q6Fe=3johhaoA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAS2fgQVreFoLiHf8NhHLbT8wpSBO4WHHRU10q6Fe=3johhaoA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
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 19:54:03 +0000
Cc: Bitcoin Dev <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 19:35:36 -0000
On Wed, Mar 02, 2016 at 05:53:46PM +0000, Gregory Maxwell wrote:
> What you are proposing makes sense only if it was believed that a very
> large difficulty drop would be very likely.
>
> This appears to be almost certainly untrue-- consider-- look how long
> ago since hashrate was 50% of what it is now, or 25% of what it is
> now-- this is strong evidence that supermajority of the hashrate is
> equipment with state of the art power efficiency.
To avoid duplication of looking up this statistic among readers, here
are the various recent difficulties:
$ for i in $( seq 0 2016 60000 ) ; do echo -n $i blocks ago:' ' ; bitcoin-cli getblock $( bitcoin-cli getblockhash $(( 400857 - i )) ) | jshon -e difficulty ; done | column -t
0 blocks ago: 163491654908.95929
2016 blocks ago: 144116447847.34869
4032 blocks ago: 120033340651.237
6048 blocks ago: 113354299801.4711
8064 blocks ago: 103880340815.4559
10080 blocks ago: 93448670796.323807
12096 blocks ago: 79102380900.225983
14112 blocks ago: 72722780642.54718
16128 blocks ago: 65848255179.702606
18144 blocks ago: 62253982449.760818
20160 blocks ago: 60883825480.098282
22176 blocks ago: 60813224039.440353
24192 blocks ago: 59335351233.86657
26208 blocks ago: 56957648455.01001
28224 blocks ago: 54256630327.889961
30240 blocks ago: 52699842409.347008
32256 blocks ago: 52278304845.591682
34272 blocks ago: 51076366303.481934
36288 blocks ago: 49402014931.227463
38304 blocks ago: 49692386354.893837
40320 blocks ago: 47589591153.625008
42336 blocks ago: 48807487244.681381
44352 blocks ago: 47643398017.803436
46368 blocks ago: 47610564513.47126
48384 blocks ago: 49446390688.24144
50400 blocks ago: 46717549644.706421
52416 blocks ago: 47427554950.6483
54432 blocks ago: 46684376316.860291
56448 blocks ago: 44455415962.343803
58464 blocks ago: 41272873894.697021
<50% of current hash rate was last seen roughly six retarget periods (12
weeks) ago and <25% of current hash rate was last seen roughly 29 periods
(58 weeks) ago.
I think that's reasonably strong evidence for your thesis given that
the increases in hash rate from the introduction of new efficient
equipment are likely partly offset by the removal from the hash rate of
lower efficiency equipment, so the one-year tail of ~25% probably means
that less than 25% of operating equipment is one year old or older.
However, it is my understanding that most mining equipment can be run at
different hash rates. Is there any evidence that high-efficiency miners
today are using high clock speeds to produce more hashes per ASIC than
they will after halving? Is there any way to guess at how many fewer
hashes they might produce?
> If a pre-programmed ramp and drop is set then it has the risk of
> massively under-setting difficulty; which is also strongly undesirable
> (e.g. advanced inflation and exacerbating existing unintentional
> selfish mining)
Maybe I'm not thinking this through thoroughly, but I don't think it's
possible to significantly advance inflation unless the effective hash
rate increases by more than 300% at the halving. With the proposal
being replied to, if all mining equipment operation before the
halving continued operating after it, the effective increase would be
200%. That doubling in effective hash rate would've been offset in
advance through a reduction in the effective hash rate in the weeks
before the halving.
Exacerbated unintentional selfish mining is a much more significant
concern IMO, even if it's only for a short retarget period or two. This
is especially the case given the current high levels of centralization
and validationless mining on the network today, which we would not want
to reward by making those miners the only ones effectively capable of
creating blocks until difficulty adjusted. I had not thought of this
aspect; thank you for bringing it up.
> and that is before suggesting that miners voluntarily take a loss of
> inflation now.
Yes, I very much don't like that aspect, which is why I made sure to
mention it.
> So while I think this concern is generally implausible; I think it's
> prudent to have a difficulty step patch (e.g. a one time single point
> where a particular block is required to lower bits a set amount) ready
> to go in the unlikely case the network is stalled.
I think having that code ready in general is a good idea, and a one-time
change in nBits is sounds like a good and simple way to go about it.
Thank you for your insightful reply,
-Dave
|
