Incentives and Game-Theoretic Considerations in Bitcoin Jonathan Katz 1
“Bitcoin provides a rich playground in which to explore the effects of rational behavior” Jonathan Katz 2
Background 3
Basic game theory • “Normal - form game” • N players; each player P i has a set of available actions A i – A = A i x … x A N is the set of outcomes • Utility functions u i : A R – Encodes each party’s preferences: u i (a) > u i (a’) means that P i 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 P i simultaneously choose an action a i • The “payoff” to P i is u i (a 1 , …, a N ) 5
Example • Two-party games can be encoded as a matrix Enjoy Attend talk Shanghai Prepare talk (10, 10) (-10, 5) Enjoy (-10, -50) (5, 5) Shanghai 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 P 1 knows the actions a 2 , …, a N the other parties will play, P 1 will play a best response – I.e., an action a 1 that maximizes u 1 (a 1 , …, a N ) • Given this actions by P 1 , each of the other players will adjust their behavior accordingly – Iterate… 8
Nash equilibrium • Outcome a = (a 1 , …, a N ) is “stable” if it is “self - enforcing” – I.e., even knowing what all other players are going to do, no P i can profit by deviating – Formally: for all i and a’ i : u i ( a’ i , a -i ) ≤ u i (a) • Such an outcome is called a Nash equilibrium 9
Nash equilibrium • Another view • Say each party P i is told to play a i (by, e.g., a protocol designer) – Will they listen? • Consider from perspective of P i – Assuming other parties play a -i , can P i 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 s i be a distribution over A i – E.g., a probabilistic strategy for P i • Given strategy vector s=(s 1 , …, s N ), we can define u i (s) = Exp[u i (a 1 , …, a N )], where each a i is sampled according to s i – Note: implicit assumption here that expected utility is all that matters 13
Mixed-strategy Nash equilibrium • Strategy vector s = (s 1 , …, s N ) is a Nash equilibrium if for all i and all s’ I it holds that u i ( s’ i, s -i ) ≤ u i (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 s i is weakly dominated by s’ i if 1. For all a -i , it holds that u i (s i , a -i ) ≤ u i ( s’ i, a -i ) 2. For some a -i, it holds that u i (s i , a -i ) < u i ( s’ i, a i ) • 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 of 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 h i hashes/year – Pool computes H = h 1 + … h N hashes/year – Pool gets expected payoff pH per year – Miner i gets expected payoff pH * (h i /H) = ph i – (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 h 1 and h 2 , respectively – For simplicity, assume total hash power of the network is h = h 1 + h 2 (but this is not essential) • If both honest, pool 1 gets h 1 /h of the revenue and pool 2 gets h 2 /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 h 1 - x but pool 2 still has (effective) hash power h 2 – Total power reduced to h – x – Network adjusts to keep revenue rate unchanged 37
Sabotage! • Revenue of pool 1? – (h 1 -x)/(h-x) fraction of the revenue from solutions it finds – x/(h 2 +x) of the revenue from pool 2 – I.e., total revenue (h 1 -x)/(h-x) + x/(h 2 +x) * h 2 /(h-x) – This is larger than h 1 /h for x > 0! 38
Recommend
More recommend
