Upload
kathleen-beasley
View
216
Download
0
Embed Size (px)
Citation preview
On the Incentive Compatibility of Bitcoin & Cryptocurrency
Loi LuuJoint works with
Jason Teutsch, Raghav Kulkarni, Ratul Saha, Inian Parameshwaran, Aquinas Hobor & Prateek Saxena
National University of Singapore
2
Bitcoin is becoming more important
Total market: 4 Billion USDMore investment
– Venture Capital Funding for Bitcoin Startups Triples in 2014
– Growing 25% faster than the internet in its early years
More adoptions– Paypal, Microsoft, Dell– Bank of Lodon– Nasdaq and MAS interested in Blockchain
More academic research– Research in Bitcoin triples in 2014
2008 2009 2010 2011 2012 2013 20140
50
100
150
200
250
1 0 1 821
61
205
Number of Bitcoin research papers
3
Contents
Bitcoin’s backgroundIncentive-compatibility in
cryptocurrency protocol (CCS’ 15)Incentive-compatibility in Bitcoin
pooled mining protocol (CSF’ 15)
4
BITCOIN 101
Ideal Bank Account Functionality
Bank
Alice: $10Bob: $20
Ledger
Alice Bob
“Send $2 from my account to Bob.”
“You’ve got Money! $2
from Alice.”
Alice: $08Bob: $22
-2
+2
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
Bank
2. Implement the Bank as a multiparty computation
Alice Bob
Alice Bob
P1
P2
P5
P4
P3
(e.g., Paypal)
- Standard results in Byzantine fault- tolerance apply here, (e.g. Paxos)
- PKI is assumed
Slides from Andrew Miller
3. Suppose we have a magic token that chooses parties at random.
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
Alice Bob
? ?
?
?
?
*caveats
Slides from Andrew Miller
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
Alice Bob
? ?
?
?
?
Scratchd(puz, m): r ← {0,1}k; if H(puz || m || r) < 2k-d then return r
Slides from Andrew Miller
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 Bob
? ?
?
?
?
Slides from Andrew Miller
From Ideal Bank to Bitcoin in 5 Steps
• 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.
Slightly More Detail
Slides from Andrew Miller
Bitcoin system overview
BlockchainUsers
(generate TXs)
Miners(Validate TXs &
generate blocks)
TXs
TXs
Mining Bitcoins in 5 easy steps
1.Join the network, listen for transactionsa. Validate all proposed transactions
2.Listen for new blocks, maintain blockchaina. When a new block is proposed, validate it
3.Assemble a new valid block4.Find the nonce to make your block
valida. SHA256(BlkTemplate || Nonce) has D
leading zero bits, e.g.: 0000000000000000024f37840…
5.When find a valid blocka. Broadcast & hope it gets acceptedb. Receive reward
Bitcoin transaction
Input: PreviousTX: ID of previous transaction Index: 0 scriptSig: Sign(PubKey), PubKey
Output: Value: 5000000000 scriptPubKey: %take Signature and PubKey as params checkif Hash(PubKey) = Payee's ID, checkif Sign(PubKey) is valid
Specify the source of the
moneyProve of
eligibility to spend
Amount to send
Who to send to and what payee
has to do to spend
Logic of the transaction
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
Smart ContractTXs
INCENTIVE-COMPATIBILITY IN CRYPTOCURRENCY PROTOCOL
18
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
19
Steps to verify a block If block hash meets difficulty
– One SHA256 computationMerkle tree of TXs is correctly
constructed– O(No.OfTXs) SHA256 computations
If all TXs are valid– Depends on number of TXs– Logic in each TX
What would happen if verifying a block were not cheap?
Currently in a Bitcoin block:- N=500-700 TXs- Verifying a normal TX requires 1 signature, 1
SHA256- Thus, verifying a Merkle tree is cheap
20
Problem
Is cryptocurrency protocol incentive-compatible?– 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
21
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
22
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 executionIs this enough to prevent the attack?
23
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
24
RE attack in Ethereum
Intuition– The gas fee is credited to the block founder
• Attacker = block founder?
– gas_limit can be adjusted by minersThe attack
– Creates expensive smart contract SC– Sends a TX to activate SC– Include TX in his own block– Others have to run SC whenverifying his block– Attacker conducts the attackwith 0-fee
N = matrix_sizeA = N*N input matrixB = N*N input matrixif msg.data[0] = 1: C = get_matrix(msg.data[1]) if (C == A * B) //run O(N3) sendReward()
25
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
blocksTXs and computations may be incorrect
Miners also have incentive to skip block verification– Gain advantage in the next race– Avoid RE attackExisting cryptocurrency protocols are not incentive compatible
26
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.
27
CRYPTOCURRENCY AS A CONSENSUS VERIFIABILITY PROTOCOL
Our solution
28
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
29
Threat model: ε- rational miner
Def 1: Advantage of rational mineradv(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 verificationadv(blk) = =
Def 3:ε- rational miners are honest if• adv(blk) ≤εWblk
• deviate otherwise
30
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
31
Achieve ε-CV in existing cryptocurrencies
Goal: limitingεWblk work in verifying a block
Method: Limiting work in each TX to– 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 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?
32
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_sizeA = N*N input matrixB = N*N input matrixif msg.data[0] = 1: C = get_matrix(msg.data[1])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)
Each TX will check only one element
33
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
34
Case studies: Outsourced computation
Correct consensus verifiability– GCD computation of large numbers– Dot product
Approximate consensus verifiability– Matrix multiplication– Sorting– k-coloring
35
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
INCENTIVE-COMPATIBILITY IN POOLED MINING
37
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
Securing Bitcoin pool protocol is important!
0010X
0001X
0011X
0000X
38
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
Problem
39
Block Withholding Attack● A topic of hot debate
– “Withholding attacks don’t make financial sense — that’s easy to prove with math...”
● Even from a pool operator– “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
40
Contributions
Study the Bitcoin pooled mining protocol– Game theoretic approach, i.e. formulate
Bitcoin mining as a gameAnalyze the BWH attack
– The attack is profitable• Pool protocol is vulnerable
– Empirically evaluate the findings
41
BITCOIN MINING AS ACOMPUTATIONAL POWER SPLITTING GAME
Model
42
Find 0000X
25 BTCsFi
nd 0
000X
25 B
TCs
Fin
d 00
00X
25 BT
Cs
5 BTCs
Find 00Y
D=4d=2
Find 00Y
5 BTCs
Compete to get 25 BTCs
Free to distribute
power
43
• 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
Bitcoin as a Computational Power Splitting Game
N poolsPlayer: α
GAME NETWORK
PLAYER
αβ0P1
αβ1
P2
αβ2
…
αβn
Pn-1
αβi
Pn
44
BLOCK WITHHOLDING ATTACKCase study
45
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
0010X
0001X
Honest
0011X
0000X
0010Y
0001Y
BWH
0011Y
0000Y
46
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
+x -x
BWH attack
+X
-0.2X +0.8X
47
Simple example
25% 75%
Honest Scenario
Mining Power
Reward
Honest scenari
o
Attack scenari
o
Attacker 25% 25% 25.9%
Pool 75% 75% 74.1%
20% 75%
Attack Scenario
5%
21% 79%
Actual Mining Power Distribution
0%
21% 74.1%
Actual Reward Distribution
4.9%
attacker
Victim pool BWH attack
1 pool, α=25%
(β0, β1) = (0.8, 0.2)αβ0 = 20% αβ1 = 5%
20% 75%
Honest Scenario
5%
48
Analyze BWH attack using CPS gameCompute 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
49
Scenario: single attacker
It’s always profitable to BWH attack
There is a threshold on the attacking power
It’s more profitable to target big poolExists the optimal strategy to maximize
Extra rewar
d
Attacking portion
Victim pool’s size
Attacker’s power
50
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
51
Nash equilibrium
What is the best strategy for the miner?Consider two accessible pools
– The dominant strategy is to attack the otherThere is no pure strategy
– There is always a better move to win back
P1 P2
BWH from P2
BWH from P1
52
Does attack’s duration matters?
10 BTCs/ 10 mins
11 BTCs/ 12 mins
Does it actually profit?
• Short term• It depends
• Long term• Yes• Difficulty adjusts
11 BTCs/ 10 mins
53
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
54
Experimental resultsAttacker’s Power
Attack Scenario
Reward
25% One pool 25.66%
30% One pool 31.14%
45% One pool 46.9%
25% Multiple pools 26.49%
Relative difference: 1%
55
Discussion on Defenses
Assign same task to multiple minersChange 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 blocksA cheap and compatible solution to
prevent BWH attack is still an open problem
56
Conclusion
Security of pool protocols is an open research topic
Existing pool protocols are vulnerable to BWH attack– Game-based model to understand
incentive structureFuture work
– Defenses– Proof of security
58
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
59