Presentation by Stefan Dziembowski, associate professor and leader of Cryptology and Data Security Group University of Warsaw. In BIU workshop on Bitcoin. Covered exclusively by vpnMentor.com
Networking in the Penumbra presented by Geoff Huston at NZNOG
ย
Mining pools and attacks
1. Mining Pools and Attacks
Stefan Dziembowski
University of Warsaw
Workshop on Bitcoin, Introduction to Cryptocurrencies,
Kfar Maccabiah, Ramat Gan, Israel, June 6-7, 2016
3. Mining pools
Miners create cartels called
the mining pools
This allows them to reduce the variance of their
income.
4. Note
283,494,086 GHash / s
1,700 GHash / s
The hashrate of the Achilles Labs AM-1700
miner (1095 USD)
The total hashrate of the
Bitcoin system as of 5.11.2014
number of
blocks in 1
year
The user has to wait on average over 3 years to mine a block
(even if the difficulty does not increase!)
โ 166,761 = 3.17 โ (365 โ 24 โ 6)
5. The general picture
The mining pools are operated centrally or are designed in a
p2p way.
Some of the mining pools charge fees for their services.
In other words:
โข the expected revenue from pooled mining is slightly lower
than the expected revenue from solo mining,
โข but the variance is significantly smaller.
Tricky part: how to prevent cheating by miners? How to reward
the miners?
E.g. if the operator got 25 BTC from mining then he will share
25 BTC โ fee among them
(and keep the fee to himself)
7. How to design a mining pool?
Simple idea:
mining pool
operator
miner
a list of transactions ๐ ๐ข and
a hash ๐(๐๐ข)
this includes a coinbase
transaction transferring
the reward to ๐ฉ๐ค.
๐ฉ๐ค
tries to find
๐ง๐จ๐ง๐๐ such that
๐ ๐ง๐จ๐ง๐๐, ๐ ๐๐ข , ๐ ๐ข
starts with ๐ง zeros
current hardness
parameter
if he finds such ๐ง๐จ๐ง๐๐ then
he sends it to the operator
once ๐ง๐จ๐ง๐๐ is found by
some of the pool members
each of them is rewarded
proportionally to his
work.
Problem
How to verify how
much work a miner
really did?
8. A solution: โProportional methodโ
mining pool
operator
miner
a list of transactions๐ ๐ขand a hash ๐(๐๐ข)
tries to find
๐ง๐จ๐ง๐๐ such that
๐ ๐ง๐จ๐ง๐๐, ๐ ๐๐ข , ๐ ๐ข
starts with ๐ง zeros
if he finds such a ๐ง๐จ๐ง๐๐ then he
sends it to the operator
he also submits the โpartial
solutionsโ, i.e. values
๐ง๐จ๐ง๐๐ such that
๐ ๐ง๐จ๐ง๐๐, ๐ ๐๐ข , ๐ ๐ข
starts with ๐งโฒ zeros
๐งโฒ
โช ๐ง
The โamount of workโ is measured by the number of โpartial
solutionsโ submitted.
9. Works if the miners donโt change the pools
๐ถ ๐
๐ถ ๐
๐ถ ๐
๐ถ ๐
โ proportional to ๐ถ ๐
โ proportional to ๐ถ ๐
โ proportional to ๐ถ ๐
โ proportional to ๐ถ ๐
time
proportion of computing power
probability of that this pool wins: ๐ถ ๐ + ๐ถ ๐ + ๐ถ ๐ + ๐ถ ๐
pool
members
submitted shares
reward for ๐๐ in case it wins: ๐๐๐ ๐๐ โ
๐ถ ๐
๐ถ ๐+๐ถ ๐+๐ถ ๐+๐ถ ๐
๐๐
expected reward
for ๐๐: ๐๐๐ ๐๐ โ ๐ถ ๐
10. What if the miners change pools?
๐ถ ๐
๐ถ ๐
๐ถ ๐
๐ถ ๐
time
๐๐
start a new pool
Now the expected revenue of ๐๐ is a sum of
โข ๐ถ ๐ (from the new pool)
โข plus the revenue from the old pool.
11. A problem with the proportional
method: โPool hoppingโ
It is profitable to escape from pools with lots of shares
submitted.
(since such pools have a lot of โmouths to feedโ there)
12. A solution: do not rewarding each share
equally
Example: Slushโs method
Use a scoring function that assigns to each share a score ๐ฌ.
Then assign rewards proportionally to the score.
Slushโs scoring function: ๐ = ๐๐ฑ๐ฉ
๐
๐
.
Intuitively: this gives advantage to miners who joined late.
time since the
beginning of this
โroundโ
some constant
13. Another solution: โPay-per-shareโ
The operator pays per each partial solution no matter if
he managed to extend the chain.
mining pool
operator
miner
partial solution
reward
Major drawback: risky for the operator.
He needs to have some reserves to cover the potential losses.
14. Other methods
Score-based: Geometric method, Double geometric method,
Pay-per-last-N-shares,
Improved pay-per-share: Maximum pay-per-share, Shared
maximum pay-per-share, Equalized , Shared maximum pay-
per-share,
(see [Meni Rosenfeld, Analysis of Bitcoin Pooled Mining
Reward Systems, 2011], [Okke Schrijvers, Joseph
Bonneau, Dan Boneh, and Tim Roughgarden, Incentive
Compatibility of Bitcoin Mining Pool Reward Functions])
...
15. How secure are these methods
We can assume that the mining pool operator is
honest, since he has a reputation.
Much harder to avoid: attacks from malicious miners.
We discuss two of them:
โข โsabotageโ,
โข โlie-in-waitโ.
Both of them are based on withholding certain blocks.
a bit similar to the selfish-
mining attack on Bitcoin
that we discuss later
16. A โSabotageโattack on mining pools
Submit only the partial solutions.
mining pool
operator
partial solution
rewardcomplete solution dishonest
miner
Results:
โข the pool looses money
โข the dishonest miner doesnโt earn anything (also looses a small amount)
Adversaryโs goal: make the mining pool bankrupt
(e.g. he owns a competing pool).
It is rumored that in June 2014 such an attack was executed against the
mining pool Eligius. Estimated loses: 300 BTC.
17. Another attack: โlie-in-waitโ
Once you find a solution for ๐๐ (say):
1. wait with submitting it
2. mine only for ๐๐
3. submit the solution to ๐๐ after
some time.
It can be formally shown that this is
profitable (see [Rosenfeld, 2011])
Mine for
several
mining pools:
1/3 computing power mining pool ๐๐
mining pool ๐๐
mining pool ๐๐
Intuition: ๐๐ is a very
likely winner
18. Can we have a mining pool without an
operator?
(remember: the operators typically charge a fee).
Answer: yes, using the
Peer-to-peer mining pools.
19. Peer-to-peer mining pools
General idea: the miners create a
blockchain with hardness parameter
๐งโฒ โช ๐ง on top of the last block ๐๐ข.
Every ๐๐ข
๐
, ๐๐ข
๐
, โฆ is a valid extension of
๐๐ข (except that the hardness may be
smaller than ๐ง).
The parameter ๐งโฒ is chosen is such a
way that a new block appears often
(say: once per 30 sec.)
๐๐ข
๐๐ ๐๐
๐๐
๐๐ข
๐
๐๐ข
๐
๐๐ข
๐
๐ง โ current hardness
parameter
Hence: this has to be
done using some
other fields in the
block
(fortunately: blocks
have space for this).
20. How is it done technically?
Bitcoin blocks contain fields that can be used to store H(๐๐ข
๐ฃ
)โs.
H
๐๐ข:
โฆ
โฆ
โฆ
๐๐ข
๐
:
H
nonce
H(Bi)
trans.
๐๐ข
๐
:
nonce
H(Bi)
trans.
H(๐๐ข
๐
)
H
๐๐ข
๐
:
nonce
H(Bi)
trans.
H(๐๐ข
๐
)
21. Finally someone will find a block that
extends ๐๐ข according to Bitcoin rules.
๐๐ข
๐๐ ๐๐ ๐๐ค
๐๐ข
๐
๐๐ข
๐
๐๐ข
๐ค. . . ๐๐ข+๐=:
๐๐ข
๐ค
enters the main
Bitcoinโs blockchain
as ๐๐ข+๐
ends with ๐ง zeros
call it โfinalโ
22. How to divide the revenue from mining?
๐๐ข
๐๐ ๐๐
๐๐
๐๐ข
๐
๐๐ข
๐
๐๐ข
๐
includes in
๐๐ข
๐
a
payment to
๐๐
includes in
๐๐ข
๐
a
payment to
๐๐ and ๐๐
if this is missing then other
pool members will not mine
on top of this block
Note: the miner does not know in advance if his block will be final.
He has to choose the payment information beforehand.
24. Possible attack goals
โข double spending,
โข get more money from mining
than you should,
โข โshort sellingโ โ bet that the
price of BTC will drop and then
destroy the system (to make the
price of BTC go to zero),
โข someone (government?)
interested in shutting Bitcoin
downโฆ
โGoldfinger
attackโ
Note: this can
be done e.g. by
a spectacular
fork that lasts
just for a few
hoursโฆ
25. What we do (not) know about Bitcoinโs
security?
1. Technical errors
2. Features/problems
3. Conceptual errors
4. Potential threats
5. Problems with key storage
26. Some notable cases of programming errors
โข a block 74638 (Aug 2010) contained a transaction with two
outputs summing to over 184 billion BTC โ this was
because of an integer overflow in Bitcoin software
(solved by a software update and a โmanual forkโ)
one double spending observed (worth 10.000 USD).
โข a fork at block 225430 (March 2013) caused by an error in
the software update of Bitcoin Core
(lasted 6 hours, solved by reverting to an older version of
the software)
Moral: nothing can be really โcompletely distributedโ.
Sometimes human intervention is neededโฆ
27. Transaction Malleability
T2 = (User P1 sends 1 BTC from T1 to P2 signature of P1 on [T2])
Hash
Hash(T2)
Problem: transactions are identified by their hashes
TxId =
Hence one can change TxId by mauling the signature:
(User P1 sends 1 BTC from T1 to P2 ๐) (User P1 sends 1 BTC from T1 to P2 ๐โ)
28. How to do it?
Other methods also existsโฆ
๐ = (r,s)
is a valid signature on
M w.r.t. pk
๐โฒ = (r, -s (mod N))
is a valid signature on
M w.r.t. pk
Bitcoin uses ECDSA signatures. Hence:
29. What can the adversary do?
transaction T mauled T
miners
[Andrychowicz et al 2015]: very easy to perform in practice.
30. Is it a problem?
Often: NO
(the mauled transaction is semantically equivalent to the
original one)
When things can go wrong?
โข Bitcoin contracts
โข buggy software
31. Claimed attack on MtGox
deposits 1 BTC
withdraws 1 BTC
transaction
T = โMtGox sends 1 BTC to Aโ
A
transaction
Tโ = mauled transaction T
blockt blockt+1 blockt+2 blockt+3
Since MtGox cannot see a
transaction with TxId Hash(T) in
the blockchain.
Thus it concludes that the
transaction did not happen.
(so A can double spend)
[Decker and Wattenhofer, ESORICS 2014]: this is probably not true.
32. What we do (not) know about Bitcoinโs
security?
1. Technical errors
2. Features/problems
3. Conceptual errors
4. Potential threats
5. Problems with key storage
33. One obvious problem: lack of anonymity
Can sometimes be de-anonymized:
[Meiklejohn et al., A fistful of bitcoins: characterizing
payments among men with no names, 2013]
1 BTC 1 BTC
can be linked
1BTC
1 BTC 1 BTC
Heuristic solution:
1BTC
35. Drawbacks of the hardware mining
1. Makes the whole process ``non-democraticโ.
2. Easier to attack by very powerful adversary?
3. Excludes some applications (mining a as
โmicropaymentโโ).
?
36. Advantages of the hardware mining
โข Security against botnets.
โข Makes the miners interested in the long-term
stability of the system.
How โlong termโ?
Remember that the total hashrate can
go up almost 100x in one yearโฆ
37. Risk associated to pooled mining
June 2014: the Ghash.io pool got > 50% of the total
hashpower.
Then this percentage went downโฆ
38. Observation
What we were promised:
โdistributed currency independent from the central
banksโ
What we got (in June 2014):
โcurrency controlled by a single companyโโฆ
39. A problem
Individual miners lost control over which blocks they mine.
For example in the Stratum protocol (commonly used by
mining pools):
miners cannot choose Bitcoin transactions on their own
From mining.bitcoin.cz/stratum-mining:
โIn my experience 99% of real miners donโt care about
transaction selection anyway, they just want the highest possible
block reward. At this point they share the same interest with pool
operator, so thereโs no real reason to complicate mining protocol just
for those 1% who want to create custom blocks for the pool.โ
40. How to break Bitcoin?
1. Start a number of mining pools with a negative fee.
2. Wait until you get >50% of the total hashrate.
Will the miners join?
they just want the
highest possible block
rewardโฆ
41. What is really our security assumption?
โAs long as a majority of
CPU power is controlled by
nodes that are not
cooperating to
attack the network, they'll
generate the longest chain
and outpace attackersโ
we proposed a peer-to-
peer network using proof-
of-work to record a public
history of transactions that
quickly becomes
computationally
impractical for an
attacker to change if
honest nodes control a
majority of CPU power
1. No cartel controls the majority of the computing power,
or
2. The majority of participants is 100% honest.
?
42. In order for the Bitcoin to work we need a
following (strong) assumption:
The majority behaves honestly even if it has incentives not to
do so.
Is it realistic?
enthusiast:
sceptics:
Yes, since the majority is
interested in maintaining the
system
No, since this is not how
capitalism worksโฆ
(e.g.: tragedy of the commons)
44. Conjecture
Maybe the only reason why nobody broke Bitcoin
yet is that nobody was really interested in doing it?
45. How to analyze it?
Use a game-theoretic model.
See:
[Joseph Bonneau, Edward W. Felten, Steven
Goldfeder, Joshua A. Kroll and Arvind Narayanan,
Why buy when you can rent? Bribery attacks on
Bitcoin consensus, 2014]
47. What we do (not) know about Bitcoinโs
security?
1. Technical errors
2. Features/problems
3. Conceptual errors
4. Potential threats
5. Problems with key storage
48. Easy to see
An adversary that controls majority of computing
power can always break the system.
blocki
blocki+1
blocki+2 blockโi+2
blocki+3
blocki+4
blockโi+3
blockโi+4
blockโi+5
pays using
transaction T
T
Eventually this
branch becomes
longer so he can
โcancel Tโ and
double spend.
49. It turns out that even a dishonest
minority can attack Bitcoin...
Selfish mining
Ittay Eyal, Emin Gun Sirer Majority is not Enough: Bitcoin Mining is
Vulnerable
Basic idea: when you mine a new block keep it to yourself (also called
block withholding strategy).
Goal: make the honest miners waste their effort at mining blocks that
will never make it to the chain.
Observe
โข the proportion of the blocks that you mine will be higher than it
should be,
โข hence: you will earn more than your share of computing power
(since Bitcoin adjusts the difficulty)
50. Why is it bad?
If there is a strategy that is more beneficial than the
honest strategy then miners have an incentive to
misbehave (โBitcoin is not incentive compatibleโ)
(recall that with the honest strategy every miner whose
computing power is an ๐ถ-fraction of the total computing
power gets an ๐ถ-fraction of the revenue)
Moreover: the larger ๐ถ is the more beneficial this strategy is.
Therefore: the miners have incentives to join a large pool that
uses this strategy.
fraction of revenuefraction of computing power
51. A simplifying assumption (for a
moment)
What happens when there is a fork?
Bitcoin specification:
โfrom two chains of equal length mine on the first one that you receivedโ.
Assume that the adversary is always first (e.g. he puts a lot
of โfake nodesโ that act as sensors).
52. An observation
Assume that the adversary does
not broadcast the new block that
he found (and mines on it
โprivatelyโ).
Two things can happen:
1. the adversary manages to
extend his โprivate block
chainโ by one more block, or
2. the โhonest usersโ manage
to find an alternative
extension.
blocki
blocki+1
blocki+2
blockโi+2
blocki+3
In this case the adversary
quickly publishes his block
so he looses nothing
53. If the adversary is lucky then he obtains
advantage over the honest miners.
blocki
blocki+1
blockโi+2 blocki+2
blocki+3
blocki+4
blocki+5
blockโi+3
blockโi+4
blockโi+5
he publishes his chain if the
โpublic chainโ equalizes with it
the reward for these
blocks goes to him
Note: this works even if the adversary has minority of computing power.
54. Full attack
The assumption that โthe adversary is always firstโ may
look unrealistic.
Eyal and Sirer show a modification of this strategy that
works without this assumption.
๐ธ โ probability that an honest user chooses adversaryโs
block
๐ถ โ fraction of adversaryโs computing power
We present it on next slides.
55. Note
๐ธ โ probability that an honest user chooses adversaryโs block
๐ถ โ fraction of adversaryโs computing power
the probability that the adversary
wins if there is a fork is equal to
๐ถ + ๐ โ ๐ถ ๐ธ
the adversary
extends the
chain
an honest
miners extend
the chain
they extend
adversaryโs chain
they extend the
โhonestโ chain
prob. ๐ถ
prob. ๐ โ ๐ถ
prob. ๐ธ
prob. ๐ โ ๐ธ
Why? denote it ๐น
56. At the beginning of the attack we have:
initial state: someone mined a new block and everyone
is trying to extend it
state ๐
First step: if the adversary finds a new block โ he keeps
it private.
57. the honest miners
also find a block
adversary finds
another block on
top of his old one
the adversary
published his
block ASAP
โhonest blockโ
won
โadversaryโs blockโ
won
state ๐
prob. ๐ โ ๐ถ prob. ๐ถ
prob. ๐ โ ๐น prob. ๐น
state ๐
state ๐โฒ
state ๐ state ๐
state ๐
the adversary
found a new
block
58. From state ๐:
state ๐
state ๐
the adversary
publishes his
chain ASAP
state ๐
prob. ๐ถ
prob. ๐ โ ๐ถ
59. In general for ๐ โฅ ๐
state ๐
๐
state ๐:
โthe adversary has
advantage ๐ over the
honest minersโ
60. This leads to the following state
machine:
state ๐
state ๐โฒ
state ๐ state ๐ state ๐ state ๐ . . .
๐ถ ๐ถ ๐ถ ๐ถ
๐ โ ๐ถ๐ โ ๐ถ๐ โ ๐ถ๐ โ ๐ถ
๐ถ
๐ โ ๐ถ๐
61. This converges to some stationary
distribution ๐ฉ ๐, ๐ฉ ๐โฒ, ๐ฉ ๐, ๐ฉ ๐, ๐ฉ ๐, โฆ
We can find it using the theory of Markov chains
๐ฉ ๐
๐ฉ ๐โฒ
๐ฉ ๐ ๐ฉ ๐ ๐ฉ ๐ ๐ฉ ๐ . . .
๐ถ ๐ถ ๐ถ ๐ถ
๐ โ ๐ถ๐ โ ๐ถ๐ โ ๐ถ๐ โ ๐ถ
๐ถ
๐ โ ๐ถ๐
62. How to calculate adversaryโs revenue?
state ๐
state ๐โฒ
state ๐ state ๐ state ๐ state ๐ . . .
+๐ +๐ +๐ +๐
(โ)
โ = +๐ iff the adversary โwon a forkโ.
This happens with probability ๐น.
Look when the adversary โearns a blockโ:
Hence the expected revenue of the adversary is equal to:
๐น โ ๐ ๐โฒ + ๐ถ โ ๐ ๐ + ๐ถ โ ๐ ๐ + โฏ
63. The final result
Eyal and Sirer calculate this, and show that their
strategy works as long as ฮฑ >
๐โ๐ธ
๐ โ๐๐ธ
They also show that the larger ๐ถ is the more beneficial
this strategy is.
ฮฑ
๐ธ
64. How to fix it?
One simple idea to make ๐ธ =
๐
๐
:
Instruct the miners to mine on a random chain
(in case they receive to equal ones)
65. Another clever attack
Lear Bahack Theoretical Bitcoin Attacks with less
than Half of the Computational Power
The โDifficulty Raising Attackโ โ exploits the way the
difficulty is adjusted in Bitcoin.
66. What we do (not) know about Bitcoinโs
security?
1. Technical errors
2. Features/problems
3. Conceptual errors
4. Potential threats
5. Problems with key storage
68. In the future the opposite problem can
happen
When the mining reward becomes negligible, we can
experience:
Tragedy of the commons:
adding a transaction costs nothing, so the miners will not
be able to keep the transaction fees high.
69. Another question
Verification of blocks takes time.
Maybe itโs cheaper not to verify?
(โverifier's dilemmaโ)
(more relevant to Ethereum)
See [Luu, Teutsch, Kulkarni, Saxena, Demystifying
incentives in the consensus computer, ACM CCS
2015].
Recall that verification
includes checking all
transactions
70. Yet another question
What happens if someone posts a transaction T with
a very high fee (say 100 BTC)?
blocki+1block1
blocki+2
for them itโs more
profitable to mine on
the old block
71. What we do (not) know about Bitcoinโs
security?
1. Technical errors
2. Features/problems
3. Conceptual errors
4. Potential threats
5. Problems with key storage
72. A practical problem: How to store the
bitcoins?
โข storing in plaintext on the PC โ bad idea (malware attacks)
โข encrypting with a password โ susceptible to the dictionary
attacks
โข better: split the key between several devices. Two options:
โข use the โmultisignature feature of Bitcoin
โข use secret sharing and the MPCs
โข store on the USB memory โ also susceptible to malware (once
connected to the PC).
โข use a smarter device โ more secure,
especially if it has a display:
73. ยฉ2016 by Stefan Dziembowski. Permission to make digital or hard copies of part or
all of this material is currently granted without fee provided that copies are made
only for personal or classroom use, are not distributed for profit or commercial
advantage, and that new copies bear this notice and the full citation.