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

57

Thank you

Q&AEmail: loiluu@comp.nus.edu.sg

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

59