summaryrefslogtreecommitdiff
path: root/10/08fd18253a035b21c18082b9695c4a3ba880c4
blob: cdcbd351fca4a2371234650513df126dd33d034f (plain)
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
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <alex.mizrahi@gmail.com>) id 1Xi5jb-00018U-Tv
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 Oct 2014 18:06:39 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.45 as permitted sender)
	client-ip=209.85.218.45; envelope-from=alex.mizrahi@gmail.com;
	helo=mail-oi0-f45.google.com; 
Received: from mail-oi0-f45.google.com ([209.85.218.45])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Xi5ja-0005ro-Bg
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 Oct 2014 18:06:39 +0000
Received: by mail-oi0-f45.google.com with SMTP id i138so1675480oig.4
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 25 Oct 2014 11:06:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.208.10 with SMTP id h10mr1666125oig.89.1414260392826;
	Sat, 25 Oct 2014 11:06:32 -0700 (PDT)
Received: by 10.202.168.142 with HTTP; Sat, 25 Oct 2014 11:06:32 -0700 (PDT)
Date: Sat, 25 Oct 2014 21:06:32 +0300
Message-ID: <CAE28kUS-uDbd_Br3H5BxwRm1PZFpOwLhcyyZT9b1_VfRaBC9jw@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113cead2559f5c05064328bf
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(alex.mizrahi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Xi5ja-0005ro-Bg
Subject: [Bitcoin-development] death by halving
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 25 Oct 2014 18:06:40 -0000

--001a113cead2559f5c05064328bf
Content-Type: text/plain; charset=UTF-8

# Death by halving

## Summary

If miner's income margin are less than 50% (which is a healthy situation
when mining hardware is readily available), we might experience
catastrophic loss of hashpower (and, more importantly, catastrophic loss of
security) after reward halving.

## A simple model

Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the
total revenue miner receives over a period of time, and C_e is the cost of
electricity spent on mining over the same period of time. (Note that for
the sake of simplicity we do not take into account equipment costs,
amortization and other costs mining might incur.)

Also we will assume that transaction fees collected by miner are negligible
as compared to the subsidy.

Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy
halving and bitcoin and electricity prices stay the same, then mining is no
longer profitable after the halving.

Indeed, suppose the revenue after the halving is R' = R/2.
   MIM = (R-C_e)/R < 0.5
   R/2 < C_e.

   R' = R/2 < C_e.

If revenue after halving R' doesn't cover electricity cost, a rational
miner should stop mining, as it's cheaper to acquire bitcoins from the
market.

~~~

Under these assumptions, if the majority of miners have MIM less than 0.5,
Bitcoin is going to experience a significant loss of hashing power.
But are these assumptions reasonable? We need a study a more complex model
which takes into account changes in bitcoin price and difficulty changes
over time.
But, first, let's analyze significance of 'loss of hashpower'.

## Catastrophic loss of hashpower

Bitcoin security model relies on assumption that a malicious actor cannot
acquire more than 50% of network's current hashpower.
E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double
Spending_ paper which shows that as long as the malicious actor controls
only a small fraction of total hashpower, attacks have well-define costs.
But if the attacker-controlled hashrate is higher than 50%, attacks become
virtually costless, as the attacker receives double-spending revenue on top
of his mining revenue, and his risk is close to zero.

Note that the simple model described in the aforementioned paper doesn't
take into account attack's effect on the bitcoin price and the price of the
Bitcoin mining equipment. I hope that one day we'll see more elaborate
attack models, but in the meantime, we'll have to resort to hand-waving.

Consider a situation where almost all available hashpower is available for
a lease to the highest bidder on the open market. In this case someone who
owns sufficient capital could easily pull off an attack.

But why is hashpower not available on the market? Quite likely equipment
owners are aware of the fact that such an attack would make Bitcoin
useless, and thus worthless, which would also make their equipment
worthless. Thus they prefer to do mining for a known mining pools with good
track record.
(Although hashpower marketplaces exist: https://nicehash.com/ they aren't
particularly popular.)

Now let's consider a situation where mining bitcoins is no longer
profitable and the majority of hashpower became dormant, i.e. miners turned
off their equipment or went to mine something else. In this case equipment
is already nearly worthless, so people might as well lease it to the
highest bidder, thus enabling aforementioned attacks.

Alternatively, the attacker might buy obsolete mining equipment from people
who are no longer interested in mining.

## Taking into account the Bitcoin price

This is largely trivial, and thus is left as an exercise for the reader.
Let's just note that the Bitcoin subsidy halving is an event which is known
to market participants in advance, and thus it shouldn't result in
significant changes of the Bitcoin price,

## Changes in difficulty

Different mining devices have different efficiency. After the reward
halving mining on some of these devices becomes unprofitable, thus they
will drop out, which will result in a drop of mining difficulty.

We can greatly simplify calculations if we sum costs and rewards across all
miners, thus calculating average MIM before the halving: `MIM = 1 - C_e/R`.

Let's consider an equilibrium break-even situation where unprofitable
mining devices were turned off, thus resulting in the change in electricity
expenditures: `C_e' = r * C_e`. and average MIM after the halving `MIM' =
0`. In this case:

    r * C_e = R/2
    C_e / R = 1/2r
    (1 - MIM) = 1/2r
    r = 1/(2*(1-MIM))

Let's evaluate this formulate for different before-halving MIM:

1. If `MIM = 0.5`, then `r = 1/(2*0.5) = 1`, that is, all miners can remain
mining.
2. If `MIM = 0.25`, then `r = 1/(2*0.75) = 0.66`, the least efficient
miners consuming 33% of total electricity costs will drop out.
3. If `MIM = 0.1`, then `r = 1/(2*0.9) = 0.55`, total electricity costs
drop by 45%.

We can note that for the before-halving MIM>0, r is higher than 1/2, thus
less than half of total hashpower will drop out.

The worst-case situation is when before-halving MIM is close to zero and
mining devices, as well as cost of electricity in different places, are
nearly identical, in that case approximately a half of all hashpower will
drop out.

## MIM estimation

OK, what MIM do we expect in the long run? Is it going to be less than 50%
anyway?

We can expect that people will keep buying mining devices as long as it is
profitable.

Break-even condition: `R - C_e - P = 0`, where P is the price of a mining
device, R is the revenue it generates over its lifetime, and C_e is the
total cost of required electricity over its lifetime. In this case, `R =
C_e + P`, and thus:

    MIM = 1 - C_e / (C_e + P)

`f = C_e / P` is a ratio of the cost of electricity to the cost of
hardware, `C_e = f * P`, and thus

    MIM = 1 - f * P / (f * P + P) = 1 - f / (f + 1) = 1 / (1 + f)

MIM is less than 0.5 when f > 1.

Computing f is somewhat challenging even for a concrete device, as it's
useful lifetime is unknown.

Let's do some guesstimation:

Spondoolies Tech's SP35 Yukon unit consumes 3.5 KW and costs $4000. If it's
useful lifetime is more than 2 years and a cost of KWh is $0.1, the total
expenditures on electricity will be at least $6135, thus for this device we
have `f > 6135/4000 > 1.5`.

If other devices which will be sold on the market will have similar specs,
we will have MIM lower than 0.5. (Well, no shit.)

## Conclusions

Reward halving is a deficiency in Bitcoin's design, but there is some hope
it won't be critical: in the equilibrium break-even situation hashpower
drop is less than 50%.
Hashrate might drop by more than 50% immediately after the halving (and
before difficulty is updated), thus a combination of the halving and slow
difficulty update pose a real threat.

--001a113cead2559f5c05064328bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div># Death by halving</div><div><br></div><div>## Summar=
y<br></div><div><br></div><div>If miner&#39;s income margin are less than 5=
0% (which is a healthy situation when mining hardware is readily available)=
, we might experience catastrophic loss of hashpower (and, more importantly=
, catastrophic loss of security) after reward halving.</div><div><br></div>=
<div>## A simple model</div><div><br></div><div>Let&#39;s define miner&#39;=
s income margin as `MIM =3D (R-C_e)/R`, where R is the total revenue miner =
receives over a period of time, and C_e is the cost of electricity spent on=
 mining over the same period of time. (Note that for the sake of simplicity=
 we do not take into account equipment costs, amortization and other costs =
mining might incur.)</div><div><br></div><div>Also we will assume that tran=
saction fees collected by miner are negligible as compared to the subsidy.<=
/div><div><br></div><div>Theorem 1. If for a certain miner MIM is less than=
 0.5 before subsidy halving and bitcoin and electricity prices stay the sam=
e, then mining is no longer profitable after the halving.</div><div><br></d=
iv><div>Indeed, suppose the revenue after the halving is R&#39; =3D R/2.</d=
iv><div>=C2=A0 =C2=A0MIM =3D (R-C_e)/R &lt; 0.5</div><div>=C2=A0 =C2=A0R/2 =
&lt; C_e.</div><div><br></div><div>=C2=A0 =C2=A0R&#39; =3D R/2 &lt; C_e.</d=
iv><div><br></div><div>If revenue after halving R&#39; doesn&#39;t cover el=
ectricity cost, a rational miner should stop mining, as it&#39;s cheaper to=
 acquire bitcoins from the market.</div><div><br></div><div>~~~</div><div><=
br></div><div>Under these assumptions, if the majority of miners have MIM l=
ess than 0.5, Bitcoin is going to experience a significant loss of hashing =
power.=C2=A0</div><div>But are these assumptions reasonable? We need a stud=
y a more complex model which takes into account changes in bitcoin price an=
d difficulty changes over time.</div><div>But, first, let&#39;s analyze sig=
nificance of &#39;loss of hashpower&#39;.</div><div><br></div><div>## Catas=
trophic loss of hashpower</div><div><br></div><div>Bitcoin security model r=
elies on assumption that a malicious actor cannot acquire more than 50% of =
network&#39;s current hashpower.</div>E.g. there is a table in Rosenfeld&#3=
9;s _Analysis of Hashrate-Based Double Spending_ paper which shows that as =
long as the malicious actor controls only a small fraction of total hashpow=
er, attacks have well-define costs. But if the attacker-controlled hashrate=
 is higher than 50%, attacks become virtually costless, as the attacker rec=
eives double-spending revenue on top of his mining revenue, and his risk is=
 close to zero.<div><div><br></div><div>Note that the simple model describe=
d in the aforementioned paper doesn&#39;t take into account attack&#39;s ef=
fect on the bitcoin price and the price of the Bitcoin mining equipment. I =
hope that one day we&#39;ll see more elaborate attack models, but in the me=
antime, we&#39;ll have to resort to hand-waving.</div><div><br></div><div>C=
onsider a situation where almost all available hashpower is available for a=
 lease to the highest bidder on the open market. In this case someone who o=
wns sufficient capital could easily pull off an attack.</div><div><br></div=
><div>But why is hashpower not available on the market? Quite likely equipm=
ent owners are aware of the fact that such an attack would make Bitcoin use=
less, and thus worthless, which would also make their equipment worthless. =
Thus they prefer to do mining for a known mining pools with good track reco=
rd.</div><div>(Although hashpower marketplaces exist:=C2=A0<a href=3D"https=
://nicehash.com/" target=3D"_blank">https://nicehash.com/</a> they aren&#39=
;t particularly popular.)</div><div><br></div><div>Now let&#39;s consider a=
 situation where mining bitcoins is no longer profitable and the majority o=
f hashpower became dormant, i.e. miners turned off their equipment or went =
to mine something else. In this case equipment is already nearly worthless,=
 so people might as well lease it to the highest bidder, thus enabling afor=
ementioned attacks.</div><div><br></div><div>Alternatively, the attacker mi=
ght buy obsolete mining equipment from people who are no longer interested =
in mining.</div><div><br></div><div>## Taking into account the Bitcoin pric=
e</div><div><br></div><div>This is largely trivial, and thus is left as an =
exercise for the reader. Let&#39;s just note that the Bitcoin subsidy halvi=
ng is an event which is known to market participants in advance, and thus i=
t shouldn&#39;t result in significant changes of the Bitcoin price,</div><d=
iv><br></div><div>## Changes in difficulty</div><div><br></div><div>Differe=
nt mining devices have different efficiency. After the reward halving minin=
g on some of these devices becomes unprofitable, thus they will drop out, w=
hich will result in a drop of mining difficulty.</div><div><br></div><div>W=
e can greatly simplify calculations if we sum costs and rewards across all =
miners, thus calculating average MIM before the halving: `MIM =3D 1 - C_e/R=
`.</div></div><div><br></div><div>Let&#39;s consider an equilibrium break-e=
ven situation where unprofitable mining devices were turned off, thus resul=
ting in the change in electricity expenditures: `C_e&#39; =3D r * C_e`. and=
 average MIM after the halving `MIM&#39; =3D 0`. In this case:</div><div><b=
r></div><div>=C2=A0 =C2=A0 r * C_e =3D R/2</div><div>=C2=A0 =C2=A0 C_e / R =
=3D 1/2r</div><div>=C2=A0 =C2=A0 (1 - MIM) =3D 1/2r</div><div>=C2=A0 =C2=A0=
 r =3D 1/(2*(1-MIM))</div><div><br></div><div>Let&#39;s evaluate this formu=
late for different before-halving MIM:</div><div><br></div><div>1. If `MIM =
=3D 0.5`, then `r =3D 1/(2*0.5) =3D 1`, that is, all miners can remain mini=
ng.</div><div>2. If `MIM =3D 0.25`, then `r =3D 1/(2*0.75) =3D 0.66`, the l=
east efficient miners consuming 33% of total electricity costs will drop ou=
t.</div><div>3. If `MIM =3D 0.1`, then `r =3D 1/(2*0.9) =3D 0.55`, total el=
ectricity costs drop by 45%.</div><div><br></div><div>We can note that for =
the before-halving MIM&gt;0, r is higher than 1/2, thus less than half of t=
otal hashpower will drop out.</div><div><br></div><div>The worst-case situa=
tion is when before-halving MIM is close to zero and mining devices, as wel=
l as cost of electricity in different places, are nearly identical, in that=
 case approximately a half of all hashpower will drop out.</div><div><br></=
div><div>## MIM estimation</div><div><br></div><div>OK, what MIM do we expe=
ct in the long run? Is it going to be less than 50% anyway?</div><div><br><=
/div><div>We can expect that people will keep buying mining devices as long=
 as it is profitable.</div><div><br></div><div>Break-even condition: `R - C=
_e - P =3D 0`, where P is the price of a mining device, R is the revenue it=
 generates over its lifetime, and C_e is the total cost of required electri=
city over its lifetime. In this case, `R =3D C_e + P`, and thus:</div><div>=
<br></div><div>=C2=A0 =C2=A0 MIM =3D 1 - C_e / (C_e + P)</div><div><br></di=
v><div>`f =3D C_e / P` is a ratio of the cost of electricity to the cost of=
 hardware, `C_e =3D f * P`, and thus</div><div><br></div><div>=C2=A0 =C2=A0=
 MIM =3D 1 - f * P / (f * P + P) =3D 1 - f / (f + 1) =3D 1 / (1 + f)</div><=
div><br></div><div>MIM is less than 0.5 when f &gt; 1.</div><div><br></div>=
<div>Computing f is somewhat challenging even for a concrete device, as it&=
#39;s useful lifetime is unknown.</div><div><br></div><div>Let&#39;s do som=
e guesstimation:</div><div><br></div><div>Spondoolies Tech&#39;s SP35 Yukon=
 unit consumes 3.5 KW and costs $4000. If it&#39;s useful lifetime is more =
than 2 years and a cost of KWh is $0.1, the total expenditures on electrici=
ty will be at least $6135, thus for this device we have `f &gt; 6135/4000 &=
gt; 1.5`.</div><div><br></div><div>If other devices which will be sold on t=
he market will have similar specs, we will have MIM lower than 0.5. (Well, =
no shit.)</div><div><br></div><div>## Conclusions</div><div><br></div><div>=
Reward halving is a deficiency in Bitcoin&#39;s design, but there is some h=
ope it won&#39;t be critical: in the equilibrium break-even situation hashp=
ower drop is less than 50%.</div><div>Hashrate might drop by more than 50% =
immediately after the halving (and before difficulty is updated), thus a co=
mbination of the halving and slow difficulty update pose a real threat.</di=
v></div>

--001a113cead2559f5c05064328bf--