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
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1XiA2R-0001PG-EM
for bitcoin-development@lists.sourceforge.net;
Sat, 25 Oct 2014 22:42:23 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.170 as permitted sender)
client-ip=209.85.217.170; envelope-from=melvincarvalho@gmail.com;
helo=mail-lb0-f170.google.com;
Received: from mail-lb0-f170.google.com ([209.85.217.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XiA2P-0005Yj-69
for bitcoin-development@lists.sourceforge.net;
Sat, 25 Oct 2014 22:42:23 +0000
Received: by mail-lb0-f170.google.com with SMTP id u10so4111705lbd.29
for <bitcoin-development@lists.sourceforge.net>;
Sat, 25 Oct 2014 15:42:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.37.104 with SMTP id x8mr4654308laj.74.1414276934492;
Sat, 25 Oct 2014 15:42:14 -0700 (PDT)
Received: by 10.112.1.234 with HTTP; Sat, 25 Oct 2014 15:42:14 -0700 (PDT)
In-Reply-To: <544C1FBA.8030901@jrn.me.uk>
References: <CAE28kUS-uDbd_Br3H5BxwRm1PZFpOwLhcyyZT9b1_VfRaBC9jw@mail.gmail.com>
<544C1FBA.8030901@jrn.me.uk>
Date: Sun, 26 Oct 2014 00:42:14 +0200
Message-ID: <CAKaEYhJSLj2nvQEUeTwJv8YULrSk4CHXLEF7d5iMOHvApFpB2Q@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Ross Nicoll <jrn@jrn.me.uk>
Content-Type: multipart/alternative; boundary=089e0160b5f44b69610506470256
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
(melvincarvalho[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: 1XiA2P-0005Yj-69
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 22:42:23 -0000
--089e0160b5f44b69610506470256
Content-Type: text/plain; charset=UTF-8
On 26 October 2014 00:10, Ross Nicoll <jrn@jrn.me.uk> wrote:
> I'd suggest looking at how Dogecoin's mining schedule has worked out, for
> how halvings tend to actually affect the market. Part of Dogecoin's design
> was that it would halve very quickly (around every 75 days, in fact), so
> it's essentially illustrating worst case scenario.
>
Yes that is an interesting data point, but it's really hard to find
comparables to doge, and most of its hashing is now merge mined with
litecoin. Comparing doge to btc may be a case of apples and oranges.
>
>
> Firstly, miners do not all move/shut down as a batch. Some will stay out
> of loyalty/apathy/optimism, so there's a jolt to hashrate when the rewards
> drop, and then a drift towards a steady-state. In most cases, the hardware
> costs vastly exceed the running costs, so while they may never see ROI due
> to the reward change, there's no benefit in stopping mining either.
>
> On the other side, mining hardware update cycles are extremely aggressive,
> and newer hardware runs much faster. Further, those with newer hardware are
> likely to have the best hashrate to power ratio, and be less likely to turn
> off or rent out their hardware.
>
> So, in theory there may be an uncomfortable period where the hashrate
> drops, but I would expect that drop to be much less than 50%, that most
> hardware that's turned off is not cost-effective to rent out, and that
> newer hardware being launched would push the hashrate back up again within
> a sensible timeframe.
>
> Ross
>
>
>
> On 25/10/2014 19:06, Alex Mizrahi wrote:
>
> # 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.
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e0160b5f44b69610506470256
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 26 October 2014 00:10, Ross Nicoll <span dir=3D"ltr"><<a href=3D"=
mailto:jrn@jrn.me.uk" target=3D"_blank">jrn@jrn.me.uk</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
I'd suggest looking at how Dogecoin's mining schedule has worke=
d
out, for how halvings tend to actually affect the market. Part of
Dogecoin's design was that it would halve very quickly (around ever=
y
75 days, in fact), so it's essentially illustrating worst case
scenario.<br></div></blockquote><div><br></div><div>Yes that is an inte=
resting data point, but it's really hard to find comparables to doge, a=
nd most of its hashing is now merge mined with litecoin.=C2=A0 Comparing do=
ge to btc may be a case of apples and oranges.<br></div>=C2=A0<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
Firstly, miners do not all move/shut down as a batch. Some will stay
out of loyalty/apathy/optimism, so there's a jolt to hashrate when
the rewards drop, and then a drift towards a steady-state. In most
cases, the hardware costs vastly exceed the running costs, so while
they may never see ROI due to the reward change, there's no benefit
in stopping mining either.<br>
<br>
On the other side, mining hardware update cycles are extremely
aggressive, and newer hardware runs much faster. Further, those with
newer hardware are likely to have the best hashrate to power ratio,
and be less likely to turn off or rent out their hardware.<br>
<br>
So, in theory there may be an uncomfortable period where the
hashrate drops, but I would expect that drop to be much less than
50%, that most hardware that's turned off is not cost-effective to
rent out, and that newer hardware being launched would push the
hashrate back up again within a sensible timeframe.<span class=3D"HOEnZ=
b"><font color=3D"#888888"><br>
<br>
Ross</font></span><div><div class=3D"h5"><br>
<br>
<br>
<div>On 25/10/2014 19:06, Alex Mizrahi
wrote:<br>
</div>
</div></div><blockquote type=3D"cite"><div><div class=3D"h5">
<div dir=3D"ltr">
<div># Death by halving</div>
<div><br>
</div>
<div>## Summary<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>## A simple model</div>
<div><br>
</div>
<div>Let's define miner'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 transaction 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 same, then mining is no longer profitable after the
halving.</div>
<div><br>
</div>
<div>Indeed, suppose the revenue after the halving is R' =3D R/=
2.</div>
<div>=C2=A0 =C2=A0MIM =3D (R-C_e)/R < 0.5</div>
<div>=C2=A0 =C2=A0R/2 < C_e.</div>
<div><br>
</div>
<div>=C2=A0 =C2=A0R' =3D R/2 < C_e.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>~~~</div>
<div><br>
</div>
<div>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.=C2=A0</div>
<div>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.</div>
<div>But, first, let's analyze significance of 'loss of
hashpower'.</div>
<div><br>
</div>
<div>## Catastrophic loss of hashpower</div>
<div><br>
</div>
<div>Bitcoin security model relies on assumption that a
malicious actor cannot acquire more than 50% of network's
current hashpower.</div>
E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Base=
d
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.
<div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div>(Although hashpower marketplaces exist:=C2=A0<a href=3D"http=
s://nicehash.com/" target=3D"_blank">https://nicehash.com/</a> they aren=
9;t
particularly popular.)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Alternatively, the attacker might buy obsolete mining
equipment from people who are no longer interested in
mining.</div>
<div><br>
</div>
<div>## Taking into account the Bitcoin price</div>
<div><br>
</div>
<div>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 change=
s
of the Bitcoin price,</div>
<div><br>
</div>
<div>## Changes in difficulty</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>We 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's consider an equilibrium break-even situation where
unprofitable mining devices were turned off, thus resulting in
the change in electricity expenditures: `C_e' =3D r * C_e`. a=
nd
average MIM after the halving `MIM' =3D 0`. In this case:</di=
v>
<div><br>
</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's evaluate this formulate 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, al=
l
miners can remain mining.</div>
<div>2. If `MIM =3D 0.25`, then `r =3D 1/(2*0.75) =3D 0.66`, the le=
ast
efficient miners consuming 33% of total electricity costs will
drop out.</div>
<div>3. If `MIM =3D 0.1`, then `r =3D 1/(2*0.9) =3D 0.55`, total
electricity costs drop by 45%.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>## MIM estimation</div>
<div><br>
</div>
<div>OK, what MIM do we expect 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
electricity 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>
</div>
<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 > 1.</div>
<div><br>
</div>
<div>Computing f is somewhat challenging even for a concrete
device, as it's useful lifetime is unknown.</div>
<div><br>
</div>
<div>Let's do some guesstimation:</div>
<div><br>
</div>
<div>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`.</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>## Conclusions</div>
<div><br>
</div>
<div>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%.</div>
<div>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.</di=
v>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><span class=3D""><pre>-----------------------------------=
-------------------------------------------
</pre>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Bitcoin-development mailing list
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a>
</pre>
</span></blockquote>
<br>
</div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>
--089e0160b5f44b69610506470256--
|