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: <davidmanheim@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 57573CA6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2016 19:39:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com
[209.85.217.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9EE5A178
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Mar 2016 19:39:01 +0000 (UTC)
Received: by mail-lb0-f175.google.com with SMTP id k15so72764403lbg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 04 Mar 2016 11:39:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to;
bh=VrK15eSl8m0ML9Yp4N19qGZDg94iCU8bebhLmI4X4ic=;
b=zagXtu5F09WRD08zK5bAz/Y3uf0ihod6bD+Cb0CVy2IeQv2SrioKIs9/UhPCjuLhnn
ABKWQ0V1eGoAGXR4zwEijLNLiAYYhnCJayqrkIa8E269m2mNLecad7NonNifGjJT4Tjk
8DZgRknPR6nn2R590Rt/VOW18QDQnhyxoe8J7dOllRBYZkV0BAab87P3Ps0bgt8iIdFa
n8X6BjqDxpxF50ONRHFtZbhDee+bKFVUCpyBmeIT1xM1AkjLo+UWe1ZStH4buhRYGClX
f4lOYvBCXE66lmWtPRxF9hGMXi3nLHATdbxithFnB1IgJJbD0H1kLK8Syyx+lkfs3HIM
y1/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to;
bh=VrK15eSl8m0ML9Yp4N19qGZDg94iCU8bebhLmI4X4ic=;
b=VKCc0mPd1cuJNHj20xR08D82YoY3A6yW9u5ynjgz7qWrXGm7GMJPGquVpG2M/FzNxG
KleOpqTpvWiR6USdailyaHmd9Idn3CycKqQscpg51Ry51aytrsfOenaluN8P61wotMGS
gEUZzKY4Gq5MficFTLAeBnTLJZzkHUTgMWo5gPZx3VbkRhaFYSpdNyX0XClzZVlz8+Y6
p7w1NgiwRSuLnmVHm8AhGFqJKnp90kEkWnYbdyubh4s3ai15XCulqkpQJTOsGex9IkA5
RdmOyFXlQFcS8bKCE8fsTNVOFMM12EXtgXXojoqIfGmeczHXm/oEVvZ+uLbSlPf8KPmu
FIDg==
X-Gm-Message-State: AD7BkJIZ/fExzfx1HaP4d0Nh9s03ukDv6Cc4HiLNPw1qsrhFk4u4Hg719Q9IZzxpAOlXwegNtRN0QQwjEVsjGQ==
MIME-Version: 1.0
X-Received: by 10.112.180.5 with SMTP id dk5mr1127134lbc.86.1457120339868;
Fri, 04 Mar 2016 11:38:59 -0800 (PST)
Received: by 10.114.78.34 with HTTP; Fri, 4 Mar 2016 11:38:59 -0800 (PST)
Date: Fri, 4 Mar 2016 11:38:59 -0800
Message-ID: <CAMsFVXnfLf5L4oMCCnydNsUK2M9=KbAX5syV5x8iKgWHz=C_hQ@mail.gmail.com>
From: David Manheim <davidmanheim@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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 20:00:08 +0000
Subject: [bitcoin-dev] Proposing a (potentially less contentious) difficulty
drop solution
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: Fri, 04 Mar 2016 19:39:05 -0000
Hi all,
I've been following this discussion closely. Unlike most of the
developers, I'm more of an economist and game theorist than
cryptographer, and I wanted to suggest a possible compromise solution.
Brief review of discussion so far, as background;
There is a clear split in the discussion on the list about the costs
and benefits of a potential solution. Most of this is because of
implicit disagreement about the probability of a stalled blockchain at
the halving, and how a change would open the door to worries about
future changes. That said, as Paul Sztorc noted, "This
halving-difficulty-drop problem can, with some bad luck, get quite
disastrous, very quickly." If it doesn't happen, however, the
solutions proposed unfairly give a bonus to miners, and speeding up
the chain for a while - which also potentially increases the odds of
block-splits during that time.
Lukejr suggested that "it would need some way to avoid its early
activation outside of such an emergency (which could possibly be
detected in code, in this case)." That means it would fork after the
halving, if and only if there was a stall. The problem with this is to
detect it, and how to retarget, given asynchronous nodes. I don't
think this can be avoided nicely without either creating some
perverse incentives, or handing a large bonus to miners. Paul suggests
a very low retarget difficulty, which essentially gives a larger bonus
to miners until the next retarget; that's non-ideal. He also suggests
investigating dynamic retargeting, (This was proposed a while ago
here: http://www.truthcoin.info/blog/mining-heart-attack/ ) which
others note is unfairly changing the implicit contract.
The methods implemented by many altcoins with smooth / dynamic
retargeting are not really suitable directly - as noted, people didn't
sign up for dynamic retargeting, and there are stability issues. If
bitcoin's hash rate drops after the halving, it could be sudden and
drastic. Any solution I can foresee that prevents this leads to some
difficult to analyze incentives for the miners.
My proposal:
I think a simple solution splits the difference; a short temporary
dynamic difficulty retargeting after the halving. This allows for a
fix, while making it clear that the original ruless of bitcoin
shouldn't be discarded, and when they need to be altered, it will be a
minimal change. It also limits the period where perverse incentives
can exist, which minimizes their effects.
We don't know what difficultly is appropriate after the halving, but
can still allow a temporary dynamic difficult retargeting starting
then. Halving occurs at block 420,000; it will then be 1/3 of the way
to the next difficulty retarget. The remaining 1344 of those 2016
blocks can be used for a dynamic retarget, without changing the
schedule otherwise. The initial retarget difficulty would be 1/2 of
the previous one, as suggested by others, but it would very quickly
stabilize at the appropriate level, using essentially any dynamic
method - and so it would not stay low for long, unless necessary. One
potential downside is that the probability of a orphaned blocks
increases for a couple blocks. (That seems inevitable with any method
that might reduce difficulty and lead to faster block generation, but
by retargeting quickly, we limit that time frame.) At block 421344, it
reverts to using the current method - and that can use the entire last
2016 blocks, to smooth out the lower difficulty adjustment that
occurred.
(Conveniently, in the longer term, the same method could be used for
the 3 halvings after this one, with correspondingly shorter retarget
windows, since 210000 isn't divisible by 2016 - until we're down to
the 1.25btc coinbase reward, with 336 blocks until the next retarget.
The next halving could eliminate this; the coinbase reward would be
much less than mining fees by then, and halving difficulty would be
unneeded. This also means that the retarget about would be reduced in
the subsequent 2016 blocks each time, since the smaller retarget
window will still be averaged in with the earlier blocks.)
The only remaining question is what temporary retargeting method
should we use? I'm completely agnostic on this one, since I think it
doesn't make a huge difference, as long as there is a method chosen.
Short altcoin methods review, to make some options clear;
Smooth difficulty readjustment methods have been implemented by many
altcoins. The first of these seems to be Kimoto Gravity Well, which
does smoothing as follows; KGW = 1 + (0.7084 *
pow((double(PastBlocksMass)/double(144)), -1.228)); DigiByteCoin
tested this in the presence of discontinuities, and found it responded
too slowly. Instead, they created the so-called Digishield, which was
created explicitly to do smoothing in the presence of sudden shifts in
mining, without causing stalling - but uses much closer together
blocks to do so. See:
https://www.reddit.com/r/Digibyte/comments/1yn6t1/digibyte_v_20_code_name_digishield/
for more. Another such method is Heavycoin's temporal retargeting. Any
of these should be fine, since we don't need such fast response times.
I hope this is a useful potential compromise,
David Manheim
|
