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

Jonathan Katz

Incentives and Game-Theoretic Considerations in Bitcoin

1

Background

2

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

3

Normal-form game

• Game is played by having each party Pi

simultaneously choose an action ai

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

4

Example

• Two-party games can be encoded as a matrix

Attend talk Enjoy Hong Kong Prepare talk (10, 10) (-10, 5) Enjoy Hong Kong (-10, -50) (5, 5)

5

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

6

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…

7

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

8

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

9

Nash equilibrium

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

profitably deviate

10

Nash equilibrium

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

equilibrium

11

Mixed strategies

• Can consider randomized/mixed 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

12

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 (with possibly mixed strategies)

• Note: theorem is untrue (in general) for

infinite games

13

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

14

Notes

• A game can have multiple Nash equilibria

– In general, unclear which will be adopted – Protocol designer influences which one is played

• Fundamental assumptions of game theory

include:

– Utility functions are well defined – Only expected utility matters

• These may not hold in real life!

15

Jonathan Katz

(Shanghai Winter School on Cryptocurrency and Blockchain Technologies, 2017)

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

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, so no honest parties

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

– When to announce new blocks

• Protocol: immediately

– Transaction fees (not specified by protocol)

19

A side note

• How to measure utility?

– In bitcoins? – In USD/HKD/Euro? – Other incentives outside the system?

• Some attacks that gain utility in bitcoin may

cause the value of bitcoin to crash!

– “Macroeconomic” analysis of cryptocurrency is wide open

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 for an average miner ≈

4.7 years

• 36.7% probability of finding no blocks in a year

– 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 lower variance

26

Payouts?

• Problem: pool operator does not know each

miner’s exact hash power

• Solution: miners also find “partial solutions”

(shares), 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 (i.e.,

when solution found quickly) than long rounds

⇒ At any point in time, better to mine for the pool with the fewest shares found since the last block (or mine solo, if all pools are having 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 shares, 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…

– Extends to multiple pools as well

• Similar to prisoners’ dilemma

39

Prisoners’ dilemma

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

40

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

41

Are mining pools desirable?

• Violates the decentralized “spirit” of bitcoin
• Ends 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?

42

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!

43

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

44

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!

45

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

46

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

47

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”

48

Bitcoin mining (“selfish mining”)

49

“Selfish mining”

• Can a miner do better by (temporarily)

withholding solutions from the blockchain?

50

“Selfish mining”

• Assume miner has α fraction of the total

mining power

• Say this miner just found a block
• If it behaves honestly, it gets payoff 1

51

“Selfish mining”

• What if it withholds?

– It will mine on the block it knows – Other miners continue to mine on old block

52

“Selfish mining”

• With probability α:
• Can hope for a payoff of 2…

53

“Selfish mining”

• With probability 1-α:
• Release block; mine on own block

– Probability its block is chosen is (1+ α)/2

• Still has good probability of getting payoff 1

54

“Selfish mining”

• Can do better using a different strategy:

– If the private branch is ahead of the public branch by two blocks, keep mining on private branch – If public branch gets to one behind private branch, publish all private blocks to maintain lead

55

“Selfish mining”

• States labeled with lead of private branch over

public branch

• 0=single public chain;

0’=two public chains (fork)

56

Revenue for transitions (example)

• Was two (public) branches of length 1; miner

finds block on its own chain

– Miner publishes both blocks, gets revenue 2 – Occurs with probability α

State 0’ State 0

57

Revenue for transitions (example)

• Was two (public) branches of length 1; others

find block on miner’s chain

– Miner gets revenue 1, others get revenue 1 – Occurs with probability (1-α)γ

State 0’ State 0

58

Revenue for transitions (example)

• Was two (public) branches of length 1; others

find block on other chain

– Others get revenue 2 – Occurs with probability (1-α)(1-γ)

State 0’ State 0

59

“Selfish mining”

• Analyzing the steady state of this Markov

chain, can compute probabilities of each state

⇒ Calculate ratio of expected revenue for miner,

• thers

60

“Selfish mining”

• Theorem: miner does better using this

strategy if ½ > α > (1-γ)/(3-2γ)

• Conclusion: better to withhold even for α < ½!

61

Is this a problem?

• May lead to protocol breakdown if everyone

follows this strategy

– At a minimum, it decreases the effective hash rate

• Indicates potential for (malicious) forking

– Double spending – Reject other miners’ blocks, or other transactions

62

Recent work

• Extend analysis to two (or more) competing

selfish miners

• Observe interesting dynamics as a function of

their relative hash power…

– … but, fundamentally, the problem of selfish mining remains

63

Open questions

• This work shows that following the protocol is

not a Nash equilibrium for p large enough

– What are the Nash equilibria in that case?

• Analyze incomplete-information version

(which is the setting of the original selfish mining work)

• Design new protocols that are N.E. (and have
• ther good properties)

64

Open questions

• Does selfish mining occur in practice?

– What might constitute evidence for selfish mining?

• If so, what are the consequences?

– Can selfish mining be “punished” be others?

• If not, why not?

65

Additional payments

66

Quick examples

• All our previous discussion of selfish mining

assumed payoff was only due to mining new blocks

• Ignored payoff due to transaction fees
• Ignored payoff due to double spending!
• Ignored potential for side payments

67

“Decoys”

• Attacker publishes a “puzzle” (say, on

Ethereum) that has some payoff

• Get miners to spend some of their work on

solving this puzzle

• Gives attacker an edge in mining new blocks!

68

“Decoys”

• Attacker publishes a puzzle

– Time to solve = time to find new block – Puzzle payoff/payoff for new block = α/(1-α)

• What is the rational response?

– In Nash equilibrium, each processor will puzzle- solve α-fraction of the time, and mine new blocks (1-α)-fraction of the time

69

“Decoys”

• Analysis:

– Say miner has q-fraction of mining power – If it devotes α’-fraction of its power to the puzzle, its expected payoff is α * α’q/(α’q + α(1-q)) + (1-α) * (1- α’q)/(1- α’q + (1- α)(1-q)) – Maximizing gives α’=α

70

“Decoys”

• By setting parameters appropriately, attacker

who controls p-fraction of hash power can ensure that they now control a majority of the hash power devoted to mining

– Can fork the chain and double spend!

71

“Whale transaction”

• Similarly, attacker can incentivize miners to

mine on a non-longest chain by including a transaction with an anomalously large transaction fee

– Can be done so that it allows attacker to double spend! – Net profit for the attacker

72

References I

• Eyal, “Majority is not Enough: Bitcoin Mining is

Vulnerable”

• Nayak et al., “Stubborn Mining: Generalizing Selfish

Mining and Combining with an Eclipse Attack”

• Sapirshtein et al., “Optimal Selfish Mining Strategies

in Bitcoin”

• Kiayias et al., “Blockchain Mining Games”

73

References II

• Teutsch et al., “When Cryptocurrencies Mine Their

Own Business”

• Liao and Katz, “Incentivizing Blockchain Forks via

Whale Transactions”

• Luu et al., “Demystifying Incentives in the Consensus

Computer”

• Marmolejo-Cossio et al., “Competing (Semi-)Selfish

Miners in Bitcoin”

74

Other aspects of bitcoin

75

Block reward

• Defined as part of the Bitcoin protocol
• Started at 50 BTC; halves every 210,000 blocks

(≈ 4 years)

– Finite supply of 21 million BTC!

• Finite supply of Bitcoin chosen to keep

inflation down

– Finite supply helps ensure that value of 1 BTC will increase over time

• Interesting opportunity for economic analysis!

76

Changing block reward

• What happens immediately after the block

reward drops?

• Cost of electricity to mine remains the same,

but value of mining drops by a factor of 2

• No incentive to mine, unless either

– Value of bitcoin goes up – Some miners drop out, so cost of mining bitcoin goes down

• Interesting opportunity for empirical analysis!

77

0 Block reward?

• Eventually, the block reward drops to near-0

– Only income for miners will be transaction fees

• What happens in this case?

– Mining stops until sufficient transaction fees are available to cover mining cost – Transaction fees expected to rise – Results in competition for fees!

78

Illustrative example

79

0 Block reward

• Bitcoin may become unstable in this regime

due to competition for transaction fees

– See Carlsten et al., “On the Instability of Bitcoin Without the Block Reward”

80

Takeaway point(s)

• A full analysis of the bitcoin protocol is

incredibly complex!

– Not a closed system – Many aspects to consider – Many factors are difficult to model (e.g., network latency, asynchrony) – Incentives not always clear

81

Verification

• Do nodes have incentive to verify transactions
• r blocks (including blocks they mine)?

– Will do slightly better by leaving verification for

• ther nodes
• If nodes are strict about verifying, attacker can

carry out DoS attacks…

82

Block propagation

• Do nodes have incentive to forward new

blocks?

– By delaying, they can mine on the new block before others – If delay too long, another block may take its place

83

Transaction propagation

• Do nodes have incentive to forward new

transactions?

– By delaying, they can increase their own probability of getting the transaction fee – Downside?

84

Transaction priorities?

• Say a node receives conflicting transactions

– Which should it include in the block being mined?

• Current default is to include the one that was

received first

• Rational miner would include the one with the

higher transaction fee

– Leads to “bidding war” for users making transactions

85

Economic issues

• PoS-based systems may lead to a “rich-get-

richer” phenomenon

– See Fanti et al., “Compounding of Wealth in PoS Cryptocurrencies”

• Does this occur in PoW-based schemes?

86

Closing thoughts

87

Is Bitcoin incentive compatible?

• Answer in theory appears to be no…
• In practice, few of these attacks have been
• bserved (so far?)

– Little non-default behavior observed – Is it not occurring? If so, why? – Or is it occurring but has not been detected?

88

Explanation?

If a greedy attacker is able to assemble more CPU power than all the honest nodes … He

• ught to find it more profitable to play by the

rules … than to undermine the system and the validity of his own wealth

89

• -Satoshi Nakamoto

PoS vs. PoW

• Similar argument is even stronger for a PoS-

based blockchain

• Open question: formal analysis of this theory

90

Thank you!

91