On the Incentive Compatibility of Bitcoin & Cryptocurrency

1. On the Incentive Compatibility of Bitcoin & Cryptocurrency LoiLuu Joint works with Jason Teutsch, RaghavKulkarni,RatulSaha, InianParameshwaran, Aquinas Hobor & PrateekSaxena National University of Singapore

2. Bitcoin is becoming more important • Total market: 4 Billion USD • More 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 • Nasdaqand MAS interested in Blockchain • More academic research • Research in Bitcoin triples in 2014

3. Contents • Bitcoin’s background • Incentive-compatibility in cryptocurrency protocol (CCS’ 15) • Incentive-compatibility in Bitcoin pooled mining protocol (CSF’ 15)

4. bitcoin 101

5. Ideal Bank Account Functionality Bank Alice: $10 Bob: $20 Alice:$08 Bob: $22 -2 +2 “Send $2 from my account to Bob.” “You’ve got Money! $2 from Alice.” Ledger 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

6. 2. Implement the Bank as a multiparty computation From IdealBank to Bitcoin in 5 Steps 1. Implement the Bank as a trusted third party (e.g., Paypal) Alice Bob Bank - Standard results in Byzantine fault- tolerance apply here, (e.g. Paxos) - PKI is assumed P1 P2 Alice Bob P5 P3 P4 Slides from Andrew Miller

7. From IdealBank to Bitcoin in 5 Steps 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

8. From IdealBank to Bitcoin in 5 Steps 4. Replace the token with computationallyhardPuzzle - 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 Bob ? ? ? Slides from Andrew Miller

9. From IdealBank 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

10. 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

11. Bitcoin system overview Miners (Validate TXs & generate blocks) TXs TXs Blockchain Users (generate TXs)

12. Mining Bitcoins in 5easy steps • Join the network, listen for transactions • Validate all proposed transactions • Listen for new blocks, maintain blockchain • When a new block is proposed, validate it • Assemble a new valid block • Find the nonce to make your block valid • SHA256(BlkTemplate || Nonce) has D leading zero bits, e.g.: 0000000000000000024f37840… • When find a valid block • Broadcast & hope it gets accepted • Receive reward

13. Bitcoin transaction Input: PreviousTX: ID of previous transaction Index: 0 scriptSig: Sign(PubKey), PubKey Output: Value: 5000000000 scriptPubKey: %take Signature and PubKeyas params checkifHash(PubKey) = Payee's ID, checkifSign(PubKey) is valid Specify the source of the money Prove of eligibility to spend Amount to send Who to send to and what payee has to do to spend • Bitcoin script: supports limited operators • Prevent DoS attack • Easy to verify • Limit the applications Logic of the transaction

14. 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 ifmsg.datasize==2: returnmsg.data[0] + msg.data[1] ifmsg.datasize==1: if SHA256(msg.data[0]) == contract.storage[1]: send(reward, msg.sender)

15. Ethereum system overview TXs TXs Smart Contract TXs

16. Incentive-compatibility in cryptocurrency protocol

17. 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 in each TX • 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 What would happen if verifying a block were not cheap?

19. 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

20. Contribution • Establish that cryptocurrency protocol is not incentive compatible • Verifier’s dilemma • Formalize the cryptocurrencyconsensus 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 • Include TX in his own block • Others have to run SC when verifying his block • Attacker conducts the attack with 0-fee N = matrix_size A = N*N input matrix B = N*N input matrix ifmsg.data[0] = 1: C = get_matrix(msg.data[1]) if (C == A * B) //run O(N3) sendReward()

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 3:ε- rational miners are honest if • adv(blk) ≤εWblk • deviate otherwise • Def 2 Advantage to skip block verification • adv(blk) = =

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εWblkwork 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 εWblkwork 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 ifmsg.data[0] = 1: C = get_matrix(msg.data[1]) ifmsg.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

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

36. 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 “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 Eligiuspool • 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 aComputational power splitting game

41. D=4 d=2 Compete to get 25 BTCs Find 0000X 25 BTCs Find 0000X Find 0000X 25 BTCs 25 BTCs Find 00Y Find 00Y 5 BTCs 5 BTCs Free to distribute power

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 GAME NETWORK P1 Pn P2 … Pn-1 αβ0 αβ2 αβi αβ1 αβn PLAYER

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 5% 5% BWH attack Victim pool attacker Attack Scenario Honest Scenario Honest Scenario 75% 75% 75% 20% 20% 25% (β0, β1) = (0.8, 0.2) αβ0 = 20% αβ1 = 5% 0% 1 pool, α=25% 21% 79% Actual Mining Power Distribution 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 Attacking portion • It’s always profitable to BWH attack • There is a threshold on the attacking power • It’s more profitable to target big pool • Exists the optimal strategy to maximize Extra reward Victim pool’s size Attacker’s power

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