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

2. Bitcoin is becoming more important  Total market: 4 Billion USD  More investment – Venture Capital Funding for Bitcoin Startups Triples in 2014 Venture Capital Funding for Bitcoin Startups Triples in 2014 – Growing 25% faster than the internet in its early years 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 Research in Bitcoin triples in 2014 2

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

4. BITCOIN 101 4

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

6. 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 AliceBob AliceBob P1P2 P5 P4 P3 (e.g., Paypal) - Standard results in Byzantine fault- tolerance apply here, (e.g. Paxos) - PKI is assumed Slides from Andrew Miller

7. 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 AliceBob ?? ? ? ? *caveats Slides from Andrew Miller From Ideal Bank to Bitcoin in 5 Steps

8. 4. Replace the token with computationally hard Puzzle - Solvable by concurrent/independent participants - No advantage over brute force AliceBob ?? ? ? ? Scratch d (puz, m): r ← {0,1} k ; if H(puz || m || r) < 2 k-d then return r Slides from Andrew Miller From Ideal Bank to Bitcoin in 5 Steps

9. 5. Finally, provide participation incentives give each “lottery winner” a reward also solves the problem of initial allocation Incentive compatible participation? AliceBob ?? ? ? ? Slides from Andrew Miller From Ideal Bank to Bitcoin in 5 Steps

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

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

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

13. Finding a valid block H( ) 25.0 → A coinbase: 0x0000...00 transaction mrkl_root: H( ) prev:H( ) mrkl_root: H( ) hash: 0x0000 nonce: 0x7a83 prev:H( ) hash: hash: 0x3485... hash: 0x6a1f... nonce: 0x0000... nonce: 0x0001... hash: 0xc9c8... nonce: 0x0002... hash: 0x300c... nonce: 0xffff... hash: nonce: 0x0000... 25.0 → A coinbase: 0x0000...01 All changed hash: 0xd0c7... nonce: 0x0001... hash: 0x0224... 25.0 → A coinbase: 0x3df5...65 hash: 0x0000... nonce: 0xf77e... Slides from Arvind Narayanan

14. 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 money Prove 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

15. 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)

16. Ethereum system overview TXs Smart Contract TXs

17. INCENTIVE-COMPATIBILITY IN CRYPTOCURRENCY PROTOCOL

18. Incentive in Bitcoin protocol 18  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 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 19 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 20

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 21

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 execution 22 Is 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-2292CVE-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

24. 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 24 N = matrix_size A = N*N input matrix B = N*N input matrix if msg.data[0] = 1: C = get_matrix(msg.data[1]) if (C == A * B) //run O(N 3 ) 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 blocks  TXs and computations may be incorrect  Miners also have incentive to skip block verification – Gain advantage in the next race – Avoid RE attack 25 Existing cryptocurrency protocols are not incentive compatible

26. The problem is real and immediate 26 -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. -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 27

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 – W blk : 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

29. Threat model: ε - rational miner Def 1: Advantage of rational miner adv(f) = W f - W df – W f : amount of work that verifying f() requires – W df : amount of work in deviated protocol – Generally adv(f) = W f – O(1) 29 Def 2 Advantage to skip block verification adv(blk) = = Def 3: ε - rational miners are honest if adv(blk) ≤ ε W blk deviate otherwise

30. Incentivize correct consensus verifiability Def 4: ε - consensus verifiability is a CV that requires at most ε W blk in verifying a block 30 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 ε W blk 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 31 How about applications that require more than ε W blk 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 32 N = matrix_size A = N*N input matrix B = N*N input matrix if 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 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 33

34. Case studies: Outsourced computation  Correct consensus verifiability – GCD computation of large numbers – Dot product  Approximate consensus verifiability – Matrix multiplication – Sorting – k-coloring 34

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 35

36. 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 37 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 38

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 poola damage of 200, 000 USD 39 Our findings -The attack does profit the attacker -Applicable to all cryptocurrencies 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 game  Analyze the BWH attack – The attack is profitable Pool protocol is vulnerable – Empirically evaluate the findings 40

41. BITCOIN MINING AS A COMPUTATIONAL POWER SPLITTING GAME Model 41

42. Find 0000X 25 BTCs Find 0000X 25 BTCs Find 0000X 25 BTCs 5 BTCs Find 00Y 42 D=4 d=2 D=4 d=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 P i – Get reward U i from pool i Player’s goal is to maximize Bitcoin as a Computational Power Splitting Game  N pools  Player: α GAME NETWORK PLAYER αβ 0 P1P1 P1P1 αβ 1 P2P2 P2P2 αβ 2 … … αβ n P n-1 αβ i PnPn PnPn 43

44. BLOCK WITHHOLDING ATTACK Case study 44

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 45 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 46 +x -x BWH attack +X+X -0.2X +0.8X

47. Simple example 25% 75% Honest Scenario Mining Power Reward Honest scenario Attack scenario Attacker25% 25.9% Pool75% 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 47 1 pool, α =25% (β 0, β 1 ) = (0.8, 0.2) αβ 0 = 20% αβ 1 = 5% 20% 75% Honest Scenario 5%

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

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 pool  Exists the optimal strategy to maximize 49 Extra reward 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 50

51. 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 51 P1 P2 BWH from P2 BWH from P1

52. Does attack’s duration matters? 52 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 53

54. Experimental results 54 Relative difference: 1%

55. 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 55 A 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 structure  Future work – Defenses – Proof of security 56

57. Thank you Q&A Email: loiluu@comp.nus.edu.sgloiluu@comp.nus.edu.sg 57 LTCBTC

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 58

59. 59