Outline Bitcoin background 8271 discussion of: Double Spending Fast - PDF document

Outline Bitcoin background 8271 discussion of: “Double Spending Fast Payments in Bitcoin” Double spends and fast payments Stephen McCamant (Original paper: Ghassan O. Karame, Elli Androulaki, and Srdjan ˇ Capkun) University of Minnesota (Original paper: NEC Labs and ETH Zurich) Administrative reminders Bitcoin addresses Global transaction log Address is basically a public/private Basic transaction: Take ① ✶ from ❛ ✶ , ① ✷ signing key pair from ❛ ✷ , . . . , put ② ✶ in ❛ ✵ ✶ , ② ✷ in ❛ ✵ ✷ , . . . Randomized naming, collision unlikely Of course require P ✐ ① ✐ ❂ P ❥ ② ❥ At any moment, balance is a perhaps Keep one big list of all transactions fraction number of bitcoins (BTC) ever Anyone one can send to an address, Check all balances in addresses taken private key needed to spend from are sufficient Bitcoin network Consistency and double-spending Use peer-to-peer network to distribute If all clients always saw the same log, transaction log double-spending would be impossible Roughly similar to BitTorrent, etc. for But how to ensure consistency, if old data multiple clients update at once? Once a client is in sync, only updates Symmetric situation: me and “me” in need to be sent Australia both try to spend the same New transactions sent broadcast $100 at the same time

Bitcoin blocks Bitcoin blockchains Group ✘ 10 minutes of latest Each block contains a pointer to the transactions into one “block” previous one Use a proof of work so creating a block Clients prefer the longest chain they is very hard know All clients race, winning block E.g., inconsistency usually resolved by propagates next block Regulating difficulty Bitcoin mining Where do bitcoins come from Difficulty of the proof-of-work is originally? adjusted to target the 10 minute block frequency Fixed number created per block, assigned by the client that made it Recomputed over two-week (2016 block) average Incentive to compete in the block generation race Network adjusts to amount of computing power available Called mining by analogy with gold Enforcing consistency Outline Structure of network very resistant to protocol change Bitcoin background Inertia of everybody else’s code Changes unpopular among miners will Double spends and fast payments not stick Minor crisis in March 2013: details of Administrative reminders database lock allocation cause half of network to reject large block

Fast payments Reception vs. confirmation You’d like to use Bitcoin for Reception : transaction propagated instantaneous transactions: through P2P network In-person snack machine, grocery store, Average about 3 seconds etc. Confirmation : transaction incorporated Pure digital goods like MP3s, e-books, etc. in block chain ATM withdrawal, currency conversion Average 10 minutes per block But no possibility of reversing Conservative 6 confirmations: 1 hour, transactions later mail-order speed So need strong protection against fraud Block generation time distribution Basic double-spend attack Attacker ❆ , victim (e.g., vendor) ❱ Expected: exponential with ✕ ❂ ✶✵ min Two transactions ❚❘ ❱ and ❚❘ ❆ spend Paper’s analysis basically confirms this the same coins with extra complexities Attacker wins if ❚❘ ❱ accepted by Good fit between 2-minute binned results vendor, but ❚❘ ❆ ends up in block chain and shifted geometric distribution with ♣ ❂ ✵✿✶✾ (vs. expected ✷❂✶✵ ) Send ❚❘ ❱ to vendor, “helpers” introduce ❚❘ ❆ elsewhere Analyzing difficulty Experimental difficulty Ten geographically-distributed test Nodes store whichever transaction they nodes see first, ignore other Vary vendor location, randomly choose 1-2 helpers Easy to ensure vendor sees ❚❘ ❱ first Vary relative time of two introductions Which ❚❘ appears in the next block Many configurations had 100% success proportional to how many nodes keep it rate

Countermeasure: listening period CM: network observers Idea: after receiving transaction, wait Recruit extra nodes to listen for double 15 s to see a double spend spends Proposed in a Bitcoin FAQ In experiments with 5 observers, all Attacker has tradeoff between double-spends were seen within a few probabilities of detection and success seconds Attractive attacks (5-30% success) Authors recommend at least 3 possible observers, arguably expensive Especially when vendor has few connections CM: forwarding double-spends Outline Authors propose: always forward transactions that appear to be double Bitcoin background spends But do not use for block generation Double spends and fast payments Affects only detection, not attack success Administrative reminders Possible problems: load, DoS Not deployed as far as I know Last call for Zerocoin More papers posted New potential papers posted for: If anyone besides me wants to present Infrastructure paranoia the “Zerocoin” paper for Wednesday, Smartphone security now is your last chance to volunteer Tor (Anti-)censorship

Topic popularity survey By Tuesday night, email me your list of the topic areas from the web page, sorted by order of your interest Mentioning specific papers is optional