On the Incentive Compatibility of
Bitcoin & Cryptocurrency
Loi Luu
Joint works with
Jason Teutsch, Raghav Kulkarni, Ratul Saha, Inian
Parameshwaran, Aquinas Hobor & Prateek Saxena
National University of Singapore
Bitcoin is becoming more important
 Total market: 4 Billion USD
Number of Bitcoin research papers
 More
investment
250
– Venture Capital Funding for Bitcoin Startups
205
Triples
in
2014
200
– Growing 25% faster than the internet in its early
150years
 More adoptions
100
– Paypal, Microsoft, Dell
61
– Bank of Lodon
50
– Nasdaq and MAS interested in21Blockchain
8
 More
academic research
0
1
0
1
2008
2009
2010triples
2011 in 2014
2012
– Research
in
Bitcoin
2013
2014
2
Contents
Bitcoin’s background
Incentive-compatibility in
cryptocurrency protocol (CCS’ 15)
Incentive-compatibility in Bitcoin pooled
mining protocol (CSF’ 15)
3
BITCOIN 101
4
Ideal Bank Account Functionality
Bank
“Send $2 from
my account to
Bob.”
Alice
Alice:
Bob:
$08
$10 -2
$22
$20 +2
Ledger
“You’ve got
Money! $2
from Alice.”
Bob
Ideal Bank properties
• Alice cannot spend money that she doesn’t have
• Bank cannot send the money without Alice’s acknowledgement
• Bank cannot keep the money without sending to Bob
• Bob should be able to spend the money
Slides from Andrew Miller
From Ideal Bank to Bitcoin in 5 Steps
1. Implement the Bank as a trusted third party
(e.g., Paypal)
Alice
Bank
Bob
2. Implement the Bank as a multiparty computation
P1
Alice
P2
P5
P3
P4
Slides from Andrew Miller
Bob
- Standard
results in
Byzantine faulttolerance apply
here, (e.g.
Paxos)
- PKI is assumed
From Ideal Bank to Bitcoin in 5 Steps
3. Suppose we have a magic token that chooses parties at
random.
?
Alice
?
?
?
Bob
?
Whoever has the token gets to broadcast *once*
• If t parties are malicious:
Pr[honest selected] = (n-t)/t
• Thm. If majority are honest, transaction log converges
Slides from Andrew Miller
*caveats
From Ideal Bank to Bitcoin in 5 Steps
4. Replace the token with computationally hard Puzzle
- Solvable by concurrent/independent participants
- No advantage over brute force
Scratchd(puz, m): r ← {0,1}k; if H(puz || m || r) < 2k-d then return r
?
Alice
Slides from Andrew Miller
?
?
?
?
Bob
From Ideal Bank to Bitcoin in 5 Steps
5. Finally, provide participation incentives
• give each “lottery winner” a reward
• also solves the problem of initial allocation
• Incentive compatible participation?
?
Alice
Slides from Andrew Miller
?
?
?
?
Bob
Slightly More Detail
• Ledger: state file, mapping amounts of BTC to pkeys
• Transactions: Signed instructions to modify the ledger
• Blockchain: Authenticated sequential log of transactions
Each solution is used as seed for the next puzzle challenge.
The solutions form linked lists (blockchains).
Thm. For all n, eventually converge on unique n-length chain.
Slides from Andrew Miller
Bitcoin system overview
Miners
(Validate TXs &
generate blocks)
TXs
TXs
Users
(generate TXs)
Blockchain
Mining Bitcoins in 5 easy steps
1. Join the network, listen for transactions
a. Validate all proposed transactions
2. Listen for new blocks, maintain blockchain
a. When a new block is proposed, validate it
3. Assemble a new valid block
4. Find the nonce to make your block valid
a. SHA256(BlkTemplate || Nonce) has D leading
zero bits, e.g.: 0000000000000000024f37840…
5. When find a valid block
a. Broadcast & hope it gets accepted
b. Receive reward
Bitcoin transaction
Specify the source
of the money
Prove of eligibility
to spend
Input:
PreviousTX: ID of previous transaction
Index: 0
scriptSig: Sign(PubKey), PubKey
Output:
Amount to send
Who to send to
and what payee
has to do to spend
Logic of the
transaction
Value: 5000000000
scriptPubKey: %take Signature and
PubKey as params
checkif Hash(PubKey) = Payee's ID,
checkif Sign(PubKey) is valid
Bitcoin script: supports limited operators
• Prevent DoS attack
• Easy to verify
• Limit the applications
Ethereum: Cryptocurrency with
Turing-complete script
• Can run arbitrary program on blockchain
– Enable more applications
• Introduce Smart Contract (SC)
– A public program that embeds contractual clauses
between parties
– Has its own address, local storage, etc.
– User triggers SC by sending a transaction
if msg.datasize==2:
return msg.data[0] +
msg.data[1]
if msg.datasize==1:
if SHA256(msg.data[0]) == contract.storage[1]:
send(reward, msg.sender)
Ethereum system overview
TXs
TXs
TXs
Smart
Contract
INCENTIVE-COMPATIBILITY IN
CRYPTOCURRENCY PROTOCOL
Incentive in Bitcoin protocol
Incentive for miners
– Block reward
– Transaction fees included in the block
There is no reward for block verifier!
– “When a new block is proposed, validate it”
People verify other’s block because
– They want to mine valid blocks
– For the “common good”
– Normally, its cheap
18
Steps to verify a block
 If block hash meets difficulty
– One SHA256 computation
 Merkle tree of TXs is correctly constructed
– O(No.OfTXs) SHA256 computations
 If all TXs are valid
– Depends on number of TXs
– Logic
each TXblock:
Currently
in in
a Bitcoin
- N=500-700 TXs
- Verifying a normal TX requires 1 signature, 1 SHA256
- Thus, verifying a Merkle tree is cheap
What would happen if verifying a block
were not cheap?
19
Problem
Is cryptocurrency protocol incentivecompatible?
– Incentivize miners to verify block?
– Are honest miners vulnerable?
Finding: Cryptocurrency protocol is not
incentive compatible
– Miners are vulnerable to resource
exhaustion attack
– Rational miners have incentive to skip
verifying block
20
Contribution
 Establish that cryptocurrency protocol is not
incentive compatible
– Verifier’s dilemma
 Formalize the cryptocurrency consensus protocol
– Understand the incentive structure
Propose an incentive compatible solution
– Techniques to deploy proposed solution in existing
cryptocurrency
– Case studies: Outsourced computation applications
21
Resource exhaustion (RE) attack
 Attacker creates block that requires long time &
much resource to verify
– Bitcoin: Block that has many TXs
– Ethereum: TX that has infinite loop
 Damage
– Attacker gets higher chance in finding next blocks
– DoS attack other miners
 Existing mitigations
– Bitcoin: Limit block size ~ 1 MB
• Limit no. of TXs
– Ethereum
• Gas fee charged as the amount of opcodes executed
– Make REA expensive for attacker
• Gas_limit to limit block execution
Is this enough to prevent the attack?
22
RE attack in Bitcoin
 Intuition: Bitcoin limits the blocksize, but not
the number of opcodes
– Expensive opcode ~ easy opcode
• SHA256, CheckSig, etc
– What if a TX requires 10000 signatures
verification?
 The attack: CVE-2013-2292
– Attacker includes multiple OP_Checksig in a
block-size TX
– Miners have to hash 19.1 GB to verify
• Take relatively 190 seconds CPU-time
• Expected time to find a block is only 10 mins
23
RE attack in Ethereum
 Intuition
– The gas fee is credited to the block founder
• Attacker = block founder?
– gas_limit can be adjusted by miners
 The attack
– Creates expensive smart contract SC
– Sends a TX to activate SC
N = matrix_size
– Include TX in his own block A = N*N input matrix
– Others have to run SC when B = N*N input matrix
if msg.data[0] = 1:
verifying his block
C = get_matrix(msg.data[1])
– Attacker conducts the attack if (C == A * B) //run O(N3)
sendReward()
with 0-fee
24
Verifier’s dilemma
Miners do not know whether to verify a
block
– Verify and be vulnerable to RE attack
– Not verify and mine on top of invalid blocks
TXs and computations may be incorrect
Miners also have incentive to skip block
verification
– Gain advantage in the next race
– Avoid RE attack
Existing cryptocurrency protocols are
not incentive compatible
25
The problem is real and immediate
- 5% miners mine an invalid block
- ~Half the network hash rate was mining without fully
validating blocks
- Build new blocks on top of that invalid block.
26
Our solution
CRYPTOCURRENCY AS A
CONSENSUS VERIFIABILITY
PROTOCOL
27
Consensus verifiability model
 A consensus verifiability (CV) protocol
–
–
–
–
G: Problem giver asks a solution for f(x)
P: Prover proves that he has a solution s
V: Verifier verifies if s=f(x) is correct
Wblk: work that V always does to get reward
 Bitcoin as a CV
– G: sender decides what receiver has to do to spend
– P: receiver proves the ownership of the address
– V: verify if receiver’s signature is valid
 CV in Ethereum
– G can define more expressive problem f()
– V may have to do more work
28
Threat model: ε- rational miner
Def 1: Advantage of rational miner
adv(f) = Wf - Wdf
– Wf: amount of work that verifying f() requires
– Wdf: amount of work in deviated protocol
– Generally adv(f) = Wf – O(1)
Def 2 Advantage to skip block verification
adv(blk) = å adv( fi ) - O(1) =
i£N
åW
fi
- O(1)
i£N
Def 3:ε- rational miners are honest if
• adv(blk) ≤εWblk
• deviate otherwise
29
Incentivize correct consensus verifiability
Def 4:ε- consensus verifiability is a CV that
requires at most εWblk in verifying a block
Lemma 1:ε- consensus verifiability is incentive
compatible w.r.t ε- rational miners
εvalue
• Represents the acceptable “common good” work
• Not straightforward to estimate, depends on
• Net-worth of applications
• The network properties
• The incentive mechanism
• Individual miner’s beliefs
30
Achieve ε-CV in existing cryptocurrencies
 Goal: limitingεWblk work in verifying a block
eWblk
 Method: Limiting work in each TX to wtx =
N0
– In Ethereum
• Leveraging the gas function G(W)
– Determine the upper bound on the gas required to do W work
• Only allows TXs requiring less than
G(wtx ) gas
– In Bitcoin
• Introduce TX size
• Bound number of expensive opcodes
• Only allow standard TXs
How about applications that require more than
εWblk work computation?
31
Porting more applications to ε-CV:
Correct consensus verifiability
Split verification work into smaller TXs
– Each TX fits in ε-CV model
– Advantage of rational miners is bounded
– Correctness guaranteed
– Latency may be high
N = matrix_size
A = N*N input matrix
B = N*N input matrix
Each TX will
if msg.data[0] = 1:
check only
C = get_matrix(msg.data[1])
one element
if msg.data[0] > 1:
i, j = get_index(msg.data)
check_if (C[i][j] == A[i][] * B[][j]) //require to run O(N)
32
Porting more applications toε-CV:
Approximate consensus verifiability
 Sacrifice correctness to achieve low latency
with probabilistic checking
–  reduce number of samples, thus TXs and latency
–  can only guarantee correctness to a certain extent
 Intuition
– if a solution y’ is deemed correct  y’ ~ f(x)
 Goal
– Ensure y’ differs from f(x) by at most δbits with at
least prob. of p (say, 99%)
• At mostδbits in y’ have different property required in f(x)
with prob. ≥p
• y’ is computed from x with prob. ≥p
33
Case studies: Outsourced computation
Correct consensus verifiability
– GCD computation of large numbers
– Dot product
Approximate consensus verifiability
– Matrix multiplication
– Sorting
– k-coloring
34
Conclusion
 Bitcoin and existing cryptocurrencies are not
incentive-compatible
– Verifier’s dilemma
– Consensus computation may be done incorrectly
 Formalize the consensus protocol
– Understand the incentive structure
– Propose incentive compatible solutions
 Techniques to deploy large applications in the
proposed solutions
– Achieve correctness
– Achieve performance
35
INCENTIVE-COMPATIBILITY IN
POOLED MINING
Pooled mining
 Mining: Requires huge computational power
– Hardware investment: >100 millions USD
– Miners have to wait for years!
 Delegation of computational power via pooled
mining
– Pooled supervisor distributes work and reward
– Miners find share
• Find Nonce to have d (<D)
leading zeros
– Eg: 000000123fa…
• Shares are meaningful to pool only
 More than 90% are pool miners
– Pool miners get frequent reward
0011X
0010X
0001X
0000X
Securing Bitcoin pool protocol is important!
37
Problem
Is Bitcoin pooled mining protocol
secure?
– Miner’s reward
computational power?
– Following the protocol
best outcome?
Intuitive answer: Yes
– Hash inversion is cryptographically hard
This work
– Shows an attack to make a million USD per
month
38
Block Withholding Attack
●
A topic of hot debate
–
●
Even from a pool operator
–
●
“Withholding attacks don’t make financial
sense — that’s easy to prove with math...”
“Basically in no way has an accurate model of
the network shown withholding to be more
profitable than legitimate mining...”
Still happen in practice
–
The attack caused a damage of 200, 000
USD to Eligius pool
Our findings
- The attack does profit the attacker
- Applicable to all cryptocurrencies
39
Contributions
Study the Bitcoin pooled mining protocol
– Game theoretic approach, i.e. formulate
Bitcoin mining as a game
Analyze the BWH attack
– The attack is profitable
• Pool protocol is vulnerable
– Empirically evaluate the findings
40
Model
BITCOIN MINING AS A
COMPUTATIONAL POWER SPLITTING GAME
41
Compete to get
25 BTCs
D=4
d=2
Find 0000X
25 BTCs
Free to
distribute power
5 BTCs
42
Bitcoin as a Computational Power Splitting
Game
 N pools
 Player: α
• Player action: Pick =(β0, β1, β2 ,…, βn)
– Use αβ0 to compete independently
– Contribute αβi to pool Pi
– Get reward Ui from pool i
• Player’s goal is to maximize R = åUi
GAME NETWORK
P1
P2
αβ1
αβ0
αβ2
…
Pn-1
Pn
αβi
PLAYER
αβn
43
Case study
BLOCK WITHHOLDING ATTACK
44
Block Withholding Attack
●
●
Only submit “normal” shares
–
Reduces pool’s reward and other miners’ reward
–
Pool has to pay the attacker for his shares
Hard to detect
–
Finding a block is probabilistic
Honest
BWH
0011X
0011Y
0010X
0010Y
0001X
0001Y
0000X
0000Y
45
BWH attack is profitable
Intuition: Bitcoin is a zero-sum game
– Coins supply is constant
– The loss in the victim pool is picked up by
other pools
BWH attack
+x
+
X
-x
-0.2X
+0.8X
46
Simple example
attacker
BWH attack
5%
Victim pool
75%
20%
25%
75%
Attack Scenario
Honest Scenario
5%
1 pool, α=25%
(β0, β1) = (0.8, 0.2)
αβ0 = 20% αβ1 = 5%
0%
75%
20%
79%
21%
Honest Scenario
Mining
Power
Actual Mining Power Distribution
Reward
Honest
Attack
scenario scenario
Attacker
25%
25%
25.9%
Pool
75%
75%
74.1%
4.9%
21%
74.1%
Actual Reward Distribution
47
Analyze BWH attack using CPS game
Compute the reward of the attacker
– Before vs after the attack in each pool
– Infer attacking rules
Consider different scenarios
– Single attacker, single pool
– Single attacker, multiple pools
– Multiple attackers
48
Scenario: single attacker
Extra
reward
ab (p - b1 )
DR =
p(1- ab1 )
1
Victim
pool’s size
Attacking
portion
Attacker’s
power
 It’s always profitable to BWH attack
$b1 < p : D R > 0
 There is a threshold on the attacking power
D R > 0 Û b1 < p
 It’s more profitable to target big pool
 Exists the optimal strategy to maximize D R
49
Other scenarios
There are other dishonest miners
– It’s possibly profitable
– Depends on how much the pool is
“contaminated”
Attacking multiple pools
– Attacks as many as possible
– Exists the optimal strategy
50
Nash equilibrium
 What is the best strategy for the miner?
 Consider two accessible pools
– The dominant strategy is to attack the other
 There is no pure strategy
– There is always a better move to win back
BWH
from P1
BWH
from P2
P1
P2
51
Does attack’s duration matters?
Does it actually
profit?
1111BTCs/
BTCs/1210mins
mins
10 BTCs/ 10 mins
• Short term
• It depends
• Long term
• Yes
• Difficulty adjusts
52
Evaluate our results
●
●
Use “official” Bitcoin client, popular pool
mining software
–
Run on cloud-based Amazon EC2
–
Burning up to 70,000 CPU core-hours
Essential to
–
check the correctness of our result
–
show our CPS model is faithful
53
Experimental results
Attacker’s
Power
Attack Scenario
Rewar
d
25%
One pool
25.66%
30%
One pool
31.14%
45%
One pool
46.9%
25%
Multiple pools
26.49%
Relative difference: 1%
100%
90%
0
0
0
0.1
0
0
0
0
0.09
0.08
0.15
0.14
0
Unknown
28%
0.20
70%
60%
0
0.1
0.09
0.08
50%
40%
26%
0.08
0.07
0.13
24%
0
0.2
30%
0.18
0.17
0.15
0.14
A acker Reward
Propo on of mining power
80%
30%
KNC
Ghash
Discus
Fish
A acker
0.13
20%
22%
Reward
1
10%
0.6
0.64
0.67
0.62
0.64
0.53
0%
20%
Before
a ack
1st
change
2nd
3rd
4th
5th
change change change change
6th
change
54
Discussion on Defenses
Assign same task to multiple miners
Change pay-off scheme
– pay more to shares which are valid blocks
Change Bitcoin protocol to support
pooled mining natively
– Make share become oblivious to miner
• only pool supervisor knows which shares are
valid blocks
A cheap and compatible solution to prevent
BWH attack is still an open problem
55
Conclusion
 Security of pool protocols is an open
research topic
Existing pool protocols are vulnerable to
BWH attack
– Game-based model to understand incentive
structure
Future work
– Defenses
– Proof of security
56
Thank you
Q&A
Email: loiluu@comp.nus.edu.sg
BTC
LTC
57
Related work
 BWH attack
– [Rosen11] Analysis of bitcoin pooled mining reward systems
• Attack is not profitable
– [CoBa14] On subversive miner strategies and block
withholding attack in bitcoin digital currency
• Attack does profit, but analysis is incorrect
– [Eyal15] The miner’s dilemma
• Arrives at same findings, but from pool perspective
• No experimental evaluation
• Concurrent work
 Other Bitcoin attacks
– [Rosen11]
• Pool hopping, Lie in wait attack
– [EyalSi13] Majority is not enough: Bitcoin mining is vulnerable
• Selfish mining attack
58
59