Outline Previous e-cash and techniques CSci 5271 Introduction to - PDF document

Outline Previous e-cash and techniques CSci 5271 Introduction to Computer Security Bitcoin design Missed topic: Electronic cash and Bitcoin Stephen McCamant Bitcoin experience University of Minnesota, Computer Science & Engineering Kinds of Internet payments One ideal: electronic cash Credit/debit cards: most popular Direct transactions without third party Wide adoption among consumers, little consumer fraud liability No transaction fees Restrictive merchant procedures Potentially anonymous PayPal Non-revocable: buyer bears fraud risk Easier to accept payments Centrally managed to deal with fraud Micropayments Blinded signatures Claim: what the web needs is small payments to Sign something without knowing its value support content Often used together with randomized auditing Too small for existing mechanisms For RSA, multiply message by r ❡ , r random One idea (Peppercoin): simulate small payment with Allows a bank to “mint” coins that can still be small probability of larger payment anonymous Actual market for micropayments has been small Most buyers and sellers prefer free + other revenue Challenge: double spending Puzzles / proof-of-work Computational problem you solve to show you spent Any purely electronic data can be duplicated, some effort including electronic money Common: choose s so that ❤ ✭ ♠ ❦ s ✮ starts with Can’t allow two copies to both be spent many 0 bits Shows ideal no-third-party e-cash can’t be possible For instance, required solved puzzles can be a countermeasure against DoS

Hashcash and spam Hash trees and timestamp services Idea: use proof of work to solve email spam problem Merkle tree: parent node includes hash of children Puzzle based on date and recipient Good hash function ✦ root determines whole tree Legitimate users send only a few messages Can prove value of leaf with log-sized evidence Problem 1: mailing lists Application: document timestamping (commitment) Problem 2: spam botnets service Never caught on Outline Bitcoin addresses Address is basically a public/private signing key pair Previous e-cash and techniques Randomized naming, collision unlikely At any moment, balance is a perhaps fractional Bitcoin design number of bitcoins (BTC) Anyone one can send to an address, private key Bitcoin experience needed to spend Global transaction log Bitcoin network Use peer-to-peer network to distribute transaction Basic transaction: Take ① ✶ from ❛ ✶ , ① ✷ from ❛ ✷ , . . . , log put ② ✶ in ❛ ✵ ✶ , ② ✷ in ❛ ✵ ✷ , . . . Of course require P ✐ ① ✐ ❂ P Roughly similar to BitTorrent, etc. for old data ❥ ② ❥ Keep one big list of all transactions ever Once a node is in sync, only updates need to be Check all balances in addresses taken from are sent sufficient New transactions sent broadcast Consistency and double-spending Bitcoin blocks If all nodes always saw the same log, Group ✘ 10 minutes of latest transactions into one double-spending would be impossible “block” But how to ensure consistency, if multiple clients Use a proof of work so creating a block is very hard update at once? All nodes race, winning block propagates Symmetric situation: me and “me” in Australia both try to spend the same $100 at the same time

Bitcoin blockchains Regulating difficulty Difficulty of the proof-of-work is adjusted to target Each block contains a pointer to the previous one the 10 minute block frequency Nodes prefer the longest chain they know Recomputed over two-week (2016 block) average E.g., inconsistency usually resolved by next block Network adjusts to amount of computing power available Bitcoin mining Outline Where do bitcoins come from originally? Previous e-cash and techniques Fixed number created per block, assigned by the Bitcoin design node that made it An incentive to compete in the block generation race Bitcoin experience Called mining by analogy with gold Where Bitcoin came from Example statistics (Dec. 2017) Block chain 497,498 blocks, ✘ 154GB Paper and early implementation by Satoshi 16.7M BTC minted (many presumed lost) Nakamoto Generally presumed to be a pseudonym Theoretical value at market exchange rate ❃ $184 “Genesis block” created January 2009 billion Containing headline from The Times (of London) about a Millions of addresses, probably many fewer users bank bailout Mining power: 11 etahash/sec What can you buy with Bitcoin? Bitcoin as a currency Can be exchanged for dollars, etc. Stuff from increasingly many online retailers Currently pretty cumbersome In-person purchases, still mostly a novelty In some ways more like gold than fiat currencies Ransomware ransoms No central authority Illegal drugs (Silk Road successors) Price changes driven more by demand than supply Murder for hire: currently probably a fraud Exchange rate trend: volatile, recently up a lot

Deflation and speculation Bitcoin mining trends Some people want bitcoins to spend on purchases Exponentially increasing rates Demand based on “velocity” Supply does not keep up with interest CPU ✦ GPU ✦ FPGA ✦ ASIC So, value of 1 BTC has to go up Specialized hardware has eclipsed general purpose Others want bitcoins because they think the price Including malware and botnets will go up in the future Recent price trends suggest continuing investment Self-fulfilling prophecy But vulnerable to steep drops if expectations change Enforcing consistency Scaling Bitcoin Structure of network very resistant to protocol Current most pressing limitation: 1MB block size change Limits volume of transactions Several changes that would effectively increase it still Inertia of everybody else’s code being discussed Changes unpopular among miners will not stick Size of block chain Minor crisis March 2013: details of database lock Compare growth to external storage cost/GB allocation cause half of network to reject large block Fewer and fewer users keep the whole chain anyway Speed of confirmation Stealing bitcoins Bitcoins are a very tempting target for malware When is it safe to know you have received money? Private keys stored directly on client machines Safe answer: wait for several blocks Theft is non-reversible Too slow for, say, in-person transactions Much easier than PayPal or identity theft Much faster: wait for transaction to propagate Standard recommendation is to keep keys mostly Basic rule: precedence by order seen offline Bitcoin (non-)anonymity Zero-knowledge for privacy Basic idea: prove this money came from a previous Bitcoin addresses are not directly tied to any other transaction identity But without revealing which But the block chain is public, so there’s lots of Made possible with recent crypto constructions information Downsides: still expensive, trusted setup E.g., list of largest balances easily collectable Two rounds of academic papers lead to “Zcash”

Different proofs of work Smart contracts Desire: avoid centralizing mining in large farms Basically, computer programs that disburse money Common approach is to make memory rather than Idea predates Bitcoin, but it’s a natural match computation the limiting factor in cost Bitcoin has a limited programming language Similar constructions also used for password hashing Other contenders, such as Ethereum, have a richer one Some tricky trade-offs, including desire for cheap verification Smart contracts challenges Expensive to run contracts many times (e.g., during mining) Code visible, but bugs can’t be fixed Hack of high-profile Ethereum “DAO” application lead to a community fork