From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] death by halving
Date: Sat, 25 Oct 2014 21:06:32 +0300 [thread overview]
Message-ID: <CAE28kUS-uDbd_Br3H5BxwRm1PZFpOwLhcyyZT9b1_VfRaBC9jw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 6786 bytes --]
# 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.
[-- Attachment #2: Type: text/html, Size: 8193 bytes --]
next reply other threads:[~2014-10-25 18:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-25 18:06 Alex Mizrahi [this message]
2014-10-25 18:12 ` [Bitcoin-development] death by halving Jeff Garzik
2014-10-25 18:22 ` Alex Mizrahi
2014-10-25 18:31 ` Jeff Garzik
2014-10-25 19:08 ` Alex Mizrahi
2014-10-25 19:16 ` Gavin Andresen
2014-10-25 19:53 ` Alex Mizrahi
2014-10-25 21:50 ` Melvin Carvalho
2014-10-28 20:17 ` Ferdinando M. Ametrano
[not found] ` <CAAS2fgSiz-XRVQ4V+KbrTUWG4=g=WGf8c-pF4b4fFnfyU9HOqQ@mail.gmail.com>
2014-10-28 20:36 ` [Bitcoin-development] Fwd: " Gregory Maxwell
2014-10-28 20:57 ` Alex Mizrahi
2014-10-28 21:19 ` Jérémie Dubois-Lacoste
2014-10-28 21:43 ` Gregory Maxwell
2014-10-28 22:43 ` Ferdinando M. Ametrano
2014-10-29 14:34 ` [Bitcoin-development] Death by halving (pro-active proposals) Sergio Lerner
2014-10-29 17:25 ` Jeff Garzik
2014-10-28 21:23 ` [Bitcoin-development] Fwd: death by halving Ferdinando M. Ametrano
2014-10-28 21:34 ` Neil
2014-10-28 21:44 ` Ferdinando M. Ametrano
2014-10-28 22:00 ` Thomas Zander
2014-10-28 22:38 ` Ferdinando M. Ametrano
2014-10-28 21:57 ` Christophe Biocca
2014-10-25 20:27 ` [Bitcoin-development] " Adam Back
2014-10-25 20:43 ` Thomas Zander
2014-10-25 20:28 ` Thomas Zander
2014-10-25 20:49 ` Alex Mizrahi
2014-10-25 21:51 ` Alexander Leishman
2014-10-25 22:10 ` Ross Nicoll
2014-10-25 22:42 ` Melvin Carvalho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE28kUS-uDbd_Br3H5BxwRm1PZFpOwLhcyyZT9b1_VfRaBC9jw@mail.gmail.com \
--to=alex.mizrahi@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox