Incentives and Game-Theoretic Considerations in Bitcoin Jonathan - - PowerPoint PPT Presentation

Jonathan Katz

Incentives and Game-Theoretic Considerations in Bitcoin

1

Jonathan Katz

“Bitcoin provides a rich playground in which to explore the effects of rational behavior”

2

Background

3

Basic game theory

• “Normal-form game”
• N players; each player Pi has a set of available

actions Ai

– A = Ai x … x AN is the set of outcomes

• Utility functions ui: A  R

– Encodes each party’s preferences: ui(a) > ui(a’) means that Pi prefers outcome a to a’ – Can also view as a (monetary) payoff

• Actions and utilities are common knowledge

4

Normal-form game

• Game is played by having each party Pi

simultaneously choose an action ai

• The “payoff” to Pi is ui(a1, …, aN)

5

Example

• Two-party games can be encoded as a matrix

Attend talk Enjoy Shanghai Prepare talk (10, 10) (-10, 5) Enjoy Shanghai (-10, -50) (5, 5)

6

Note

• Can also consider extensive-form games

where parties interact with each other over several rounds

• Any extensive-form game can be viewed as a

normal-form game by letting the actions be the parties’ strategies

7

Natural question

• What will happen when the game is played?
• If P1 knows the actions a2, …, aN the other

parties will play, P1 will play a best response

– I.e., an action a1 that maximizes u1(a1, …, aN)

• Given this actions by P1, each of the other

players will adjust their behavior accordingly

– Iterate…

8

Nash equilibrium

• Outcome a = (a1, …, aN) is “stable” if it is “self-

enforcing”

– I.e., even knowing what all other players are going to do, no Pi can profit by deviating – Formally: for all i and a’i: ui(a’i, a-i) ≤ ui(a)

• Such an outcome is called a Nash equilibrium

9

Nash equilibrium

• Another view
• Say each party Pi is told to play ai (by, e.g., a

protocol designer)

– Will they listen?

• Consider from perspective of Pi

– Assuming other parties play a-i, can Pi do better by deviating? – If no party can do better, then the protocol is in Nash equilibrium

10

Nash equilibrium

• Can also consider coalitions
• E.g., look at whether groups of parties can

profitably deviate

11

Nash equilibrium

• A game can have multiple Nash equilibria

– Protocol designer can influence which one is played

• A game may have no (pure-strategy) Nash

equilibrium

12

Mixed strategies

• Can consider randomized strategies
• Let si be a distribution over Ai

– E.g., a probabilistic strategy for Pi

• Given strategy vector s=(s1, …, sN), we can

define ui(s) = Exp[ui(a1, …, aN)], where each ai is sampled according to si

– Note: implicit assumption here that expected utility is all that matters

13

Mixed-strategy Nash equilibrium

• Strategy vector s = (s1, …, sN) is a Nash

equilibrium if for all i and all s’I it holds that ui(s’i, s-i) ≤ ui(s)

• Theorem (Nash): Every finite game has a Nash

equilibrium

• Note: theorem is untrue (in general) for

infinite games

14

Other equilibrium concepts?

• Stronger equilibrium concepts can also be

considered

• E.g., a strategy si is weakly dominated by s’i if
• 1. For all a-i, it holds that ui(si, a-i) ≤ ui(s’i, a-i)
• 2. For some a-i, it holds that ui(si, a-i) < ui(s’i, ai)
• Nash equilibria in which parties play weakly

dominated strategies are (arguably) unstable

15

Game theory and bitcoin

16

Malicious vs. rational behavior

• Fix a particular protocol…
• Traditional security proofs show that certain

properties hold for honest parties in the face

• f arbitrary deviations of others
• Game-theoretic analysis is incomparable

– Only need to consider profitable deviations – But may no longer be any honest parties!

17

Rational behavior in bitcoin

• Doesn’t provable security imply no profitable

deviations?

• Not exactly…

– May be profitable deviations that don’t violate security properties – May be deviations that don’t fit into the model

• No guarantee that anyone is honest!

– E.g., everyone may deviate if the protocol is weakly dominated

18

Rational behavior in bitcoin

• All aspects of bitcoin need to be considered

– Which transactions to include

• Protocol: all (above minimum transaction fee)

– Which transactions to forward

• Protocol: all (above minimum transaction fee)

– Which chain to mine on

• Protocol: longest chain; first block heard

– When to announce new blocks

• Protocol: immediately

– Transaction fees

19

A side note

• How to measure utility?

– In bitcoins? – In USD/RMB? – Other incentives outside the system?

• Some attacks that gain utility in bitcoin may

cause the value of bitcoin to crash!

20

Mining pools

21

Bitcoin mining (abstractly)

• (Assume for simplicity that difficulty is fixed)
• Repeatedly compute hashes

– Each hash “wins” with probability p – Normalize payout for winning hash to 1

• If miner can compute h hashes/year, then its

expected payout is ph/year

• Say electricity costs E/year

– If ph > E, profit?

22

Variance

• We only looked at payout in expectation
• Problem: variance is high!
• Winning is a Poisson process
• Expected blocks found in one year is ph, but

variance is also ph

– Normalized stddev = (ph)1/2/ph = 1/(ph)1/2

23

Variance in practice

• Expected time to win = 1/ph ≈ 4.7 years
• 36.7% probability of finding no blocks in a year

– And Poisson is memoryless, so chances do not increase afterward

• Without significant cash reserves, good

chance of going out of business…

24

A side note

• This demonstrates that looking at expected

utility only is not the right model

• Unfortunately, it is very difficult to deal with

this issue

– For starters, unclear what the “true” utility function looks like

• Varies person-to-person

– Analysis becomes hard

25

Solution: mining pools

• Many miners join together, split the payoffs

proportional to their hash power

• Analysis (assuming correct behavior):

– Say miner i computes hi hashes/year – Pool computes H = h1 + … hN hashes/year – Pool gets expected payoff pH per year – Miner i gets expected payoff pH * (hi/H) = phi – (Ignore fees here)

• No better in expectation, but better variance

26

Payouts?

• Problem: pool operator does not know each

miner’s exact hash power

• Solution: miners also find “partial solutions”

(shares) that are full solutions with some probability, and send these to the operator

– These allow for an estimate of their hash power

• There is a tradeoff between the added

variance and the extra work for verification

• How to implement?

27

Pay-per-share

• Operator pays miner for each share
• Lower variance for the miner
• Higher variance for the pool operator

– May put the pool operator out of business…

28

Proportional

• When the pool finds a block, divide reward

proportionately to number of shares submitted by each miner in the current round

– Round = time since last block found by the pool

• No risk for pool operator

29

Incentive compatibility?

• Will miners continue to mine for the pool?
• Will miners report solutions immediately?

30

“Pool hopping”

• Shares are worth more in short rounds than in

long rounds

 At any point in time, better to mine for the pool with the fewest found shares since the last block (or mine solo, if all pools are experiencing long rounds)

31

“Pool hopping”

• Can show that it is worth mining in a pool only

until the number of shares is ≈44% of the expected value

• So in equilibrium (assuming instantaneous

movement between pools), all miners would instantly jump to the pool that just found a solution, mine until 44% of the expected shares are found, and then stop participating

32

Withholding solutions

• Say miner i finds a solution, but has reported

fewer-than-expected shares so far in the current round

– Better for that miner to withhold the solution until it can submit more shares

33

Pay-per-last-N-shares

• When solution found, pay 1/N to miners who

found each of the last N shares

– Note that a share may receive payouts multiple times, but expected value per share is still p – Large N reduces the variance, but increases the time for (full) payout

• Deters pool-hopping!

34

“Miners’ dilemma”

• One mining pool can attempt to “sabotage”

another

– Often in unexpected ways…

35

“Miners’ dilemma”

• Consider two pools with hash power h1 and

h2, respectively

– For simplicity, assume total hash power of the network is h = h1 + h2 (but this is not essential)

• If both honest, pool 1 gets h1/h of the revenue

and pool 2 gets h2/h of the revenue

36

Sabotage!

• Say pool 1 sends loyal miners with hash power

x to pool 2

– These miners will generate proofs of work, but will withhold solutions!

• Now pool 1 has hash power h1 - x but pool 2

still has (effective) hash power h2

– Total power reduced to h – x – Network adjusts to keep revenue rate unchanged

37

Sabotage!

• Revenue of pool 1?

– (h1-x)/(h-x) fraction of the revenue from solutions it finds – x/(h2+x) of the revenue from pool 2 – I.e., total revenue (h1-x)/(h-x) + x/(h2+x) * h2/(h-x) – This is larger than h1/h for x > 0!

38

Miners’ dilemma

• In equilibrium, both pools attack each other!
• Both pools worse off…
• Similar to prisoners’ dilemma

39

Prisoners’ dilemma

Don’t confess Confess Don’t confess (0, 0) (-2, 1) Confess (1, -2) (-1,-1)

40

Miners’ dilemma

• Extends to multiple pools as well

41

Real-world example?

• May-June 2014, Eligius pool detected a block-

withholding attack

– Claimed 300 BTC of damage

• Unclear if motivation was “miners’ dilemma”
• r simply driving miners to a competing pool

42

Are mining pools desirable?

• Appear to violate the “spirit” of bitcoin
• End up concentrating a lot of power among

small number of groups

– Ghash.IO controlled > 50% at one point – As we will see, problems can arise even once one party controls < 50% of hash power

• Is this inherent?

43

Outsourceable puzzles

• Bitcoin enables pools because
• 1. Pool operators can outsource puzzle-solving to

miners

• 2. There is an easy way for miners to prove that

they are trying to find valid blocks

• 3. Miners cannot “steal” valid blocks they find
• I.e., bitcoin’s puzzle is (very) outsourceable!

44

Non-outsourceable puzzles?

• Can we design puzzles that are not so

amenable to outsourcing?

• Weak non-outsourceability (intuitively):

– If solving the puzzle is outsourced to a miner and the miner finds a solution, then the miner can “steal” the solution for itself

45

Weak nonoutsourceability

• Basic idea:

– Ensure that solving a puzzle bound to some public key requires knowledge of the corresponding private key – This means that any miner solving a puzzle can also spend the coins associated with that puzzle!

46

Weak nonoutsourceability

• Construct Merkle tree with root d
• Repeat:

– Choose nonce r – Compute h=H(puz, r, d); use h to select q leaves from the tree l1, …, lq – Check if H(puz, r, l1, …, lq) < 2-D

• To sign transaction t:

– Compute h’=H(puz,t,d) and use h’ to select q’ unrevealed leaves

47

Strong nonoutsourceability

• Potential problem: may be out-of-band ways

to ensure that miners do not steal puzzles

• Solution: strong nonoutsourceability

– Make sure that a “stolen” solution is indistinguishable from an honestly generated solution

• Can achieve generically from weak

nonoutsourceability using ZK proofs

48

References

• Rosenfeld, “Analysis of Bitcoin Pooled Mining Reward

Systems”

• Schrijvers et al., “Incentive Compatibility of Bitcoin

Mining Reward Functions”

• Eyal, “The Miner’s Dilemma”
• Miller et al., “Notoutsourceable Scratch-Off Puzzles

to Discourage Bitcoin Mining Coalitions”

49

Thank you!

50