Game Theory Primer
Delve into the concept of decentralized mining and explore strategic interactions through the lens of game theory. From the Prisoner's Dilemma to Nash equilibrium and coordination games, understand why decentralized mining could be successful and its implications.
Uploaded on Feb 18, 2025 | 0 Views
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Game Theory Primer (why decentralized mining could work?) Prisoner s dilemma Dominated strategies Payoff Matrix Nash equilibrium Coordination game
The Prisoners Dilemma Two accomplices interrogated separately The prosecutors have enough evidence to sentence each one 1 year do not have enough evidence to sentence 2 years unless at least one suspect confesses If both confess, each sentenced 2 years If neither confesses, each sentenced 1 year If only one confesses, the confessor is immediately released, and the denier sentenced 3 years How should each prisoner do?
The Prisoners Dilemma Confess Deny (-2, -2) (0, -3) Confess (-3, 0) (-1, -1) Deny Individually optimal outcome <> socially optimal outcome
Prisoners New Dilemma Confess Deny (-2, -2) (-1, -3) Confess (-3, -1) (0, 0) Deny
The Nash Equilibrium Confess Deny (-1, -3) Confess (-2, -2) (-3, -1) Deny (0, 0) Individually optimal outcome <> socially optimal outcome
Coordination Game Alice and Bob wish to see each other at a party If Bob goes, Alice would like to go too If Bob does not go, Alice prefers staying at home Same for Bob If Alice goes, Bob would like to go too If Alice does not go, Bob prefers staying at home They don t have each other s contact info Should Alice and Bob go to the party or not?
Coordination Game Bob Not go go Go (1, 1) (-1, 0) Alice Not go (0, -1) (0, 0) Dominant strategies? Nash equilibrium?
Coordination Game Bob Not go go Go (-1, 0) (1, 1) Alic e Not go (0, -1) (0, 0) Individually optimal outcome is not necessarily socially optimal outcome How can we ensure Alice and Bob meet? Initial Coin Offering and Platform Building
A bit more on smart contract
Bitcoin scripts in practice (as of 2014) Most nodes whitelist known scripts 99.9% are simple signature checks ~0.01% are MULTISIG ~0.01% are Pay-to-Script-Hash Remainder are errors, proof-of-burn More on this soon How about today? Any changes? Why or why not? final project https://www.blockchain.com/explorer
Proof-of-burn nothing s going to redeem that OP_RETURN <arbitrary data>
Should senders specify scripts? ? I m ready to pay for my purchases! Big Box Cool! Well we re using MULTISIG now, so include a script requiring 2 of our 3 account managers to approve. Don t get any of those details wrong. Thanks for shopping at Big Box! Bitcoin has a clever solution to this problem, and it applies to not just multi-sig addresses but to any complicated condition governing when coins can be spent. Instead of telling the sender send your coins to the hash of this public key , the receiver can instead tell the sender send your coins to the hash of this script. Bitcoin Wiki
Idea: use the hash of redemption script <signature> <<pubkey> OP_CHECKSIG> <signature> OP_HASH160 <hash of redemption script> OP_EQUAL <pubkey> OP_CHECKSIG Pay to Script Hash
Pay to script hash I m ready to pay for my purchases! Big Box Great! Here s our address: 0x3454
Applications of Bitcoin scripts (simple smart contracts )
Example 1: Escrow transactions (disputed case) (normal case) Pay x to Bob Pay x to Alice Judy SIGNED(ALICE, BOB) SIGNED(ALICE, JUDY) To: Alice From: Bob Alice Bob Pay x to 2-of-3 of Alice, Bob, Judy (MULTISIG) PROBLEM: Alice wants to buy online from Bob. Alice doesn t want to pay until after Bob ships. Bob doesn t want to ship until after Alice pays. SIGNED(ALICE)
Example 2: Green addresses 004 days since last double spend! It s me, Alice! Could you make out a green payment to Bob? Faraday cage Bank Pay x to Bob, y to Bank No double spend SIGNED(BANK) Alice Bob PROBLEM: Alice wants to pay Bob. Bob can t wait 6 verifications to guard against double-spends, or is offline completely.
Example 3: Efficient micro- payments What if Bob never signs?? Input: x; Pay 42 to Bob, 58 to Alice Input: x; Pay 42 to Bob, 58 to Alice all of these could be double- spends! SIGNED(ALICE)___________ SIGNED(ALICE) SIGNED(BOB) ... Alice demands a timed refund transaction before starting Input: x; Pay 04 to Bob, 96 to Alice Input: x; Pay 100 to Alice, LOCK until time t SIGNED(ALICE)___________ SIGNED(ALICE) SIGNED(BOB) Input: x; Pay 03 to Bob, 97 to Alice I m done! I ll publish! SIGNED(ALICE)___________ Input: x; Pay 02 to Bob, 98 to Alice SIGNED(ALICE)___________ Input: x; Pay 01 to Bob, 99 to Alice SIGNED(ALICE)___________ PROBLEM: Alice wants to pay Bob for each minute of phone service. She doesn t want to incur a transaction fee every minute. Bob Alice Input: y; Pay 100 to Bob/Alice (MULTISIG) SIGNED(ALICE)
lock_time { "hash":"5a42590...b8b6b", "ver":1, "vin_sz":2, "vout_sz":1, "lock_time":315415, "size":404, ... } Block index or real-world timestamp before which this transaction can t be published lightening network; state channel
More advanced scripts Multiplayer lotteries Hash pre-image challenges Coin-swapping protocols Very relevant to anonymity solutions! Smart contracts
A gentle introduction to Ethereum Turing complete smart contracts Gas
How Bitcoin Achieves Decentralization? A revisit
Mining Illustration https://anders.com/blockchain/block.html
Assumption of honesty is problematic Can we give nodes incentives for behaving honestly? Can we reward nodes that created these blocks? Can we penalize the node that created this block? Everything so far is just a distributed consensus protocol But now we utilize the fact that the currency has value
Incentive 1: block reward Creator of block gets to include special coin-creation transaction in the block choose recipient address of this transaction Value is fixed: currently 12.5 BTC, halves every 4 years Block creator gets to collect the reward only if the block ends up on long-term consensus branch!
Theres a finite supply of bitcoins Total supply: 21 million Total bitcoins in circulation Block reward is how new bitcoins are created First inflection point: reward halved from 50BTC to 25BTC Runs out in 2040. No new bitcoins unless rules change Year
Incentive 2: transaction fees Creator of transaction can choose to make output value less than input value Remainder is a transaction fee and goes to block creator Purely voluntary, like a tip
Remaining problems 1. How to pick a random node? 1. How to avoid a free-for-all due to rewards? 1. How to prevent Sybil attacks?
The feedback loop in Bitcoin/Ethereum
Bitcoin has three types of consensus Value State Rules
Bitcoin is bootstrapped security of block chain health of mining ecosystem value of currency
What can a 51% attacker do? Steal coins from existing address? Suppress some transactions? From the block chain From the P2P network Change the block reward? Destroy confidence in Bitcoin?