Bitcoin A Basic Tutorial on Decentralized money Aviv Zohar School of Engineering and Computer Science The Hebrew University

What is Bitcoin and how does is work? What are the main challenges?

Password / encryption keys Blue: $2 Red: $1 Actions require consent of bank Less privacy Easier to regulate Password / encryption keys

Bitcoin: A decentralized digital currency Bitcoin: A decentralized digital currency. Invented by Satoshi Nakamoto (2008) Active since 2009

Other “Features” of Bitcoin Pseudonymous Fixed amount Can not be frozen Irreversible Transfers Cannot be seized Escrow Joint accounts

(taken from bitstamp.net)

Bypass regulation Increase competition Disrupt A crypto-anarchistic agenda: use cryptography to increase freedom

Blue: 2 Red: 1 Blue: 2 Red: 1 Blue: 2 Red: 1 Blue: 2 Red: 1 Blue: 2 Red: 1 Blue: 2 Red: 1 Blue: 2 Red: 1 Blue: 2 Red: 1

Transactions spread through the network They are “signed” by the creator to prove his identity

Transactions are thus public, addresses are (free) pseudonyms

Signer’s Identifier (Public Key) Signature Message Contents Secret Owned by Signer (Private Key) Verifier Message Contents Signature Signer’s Identifier (Public Key)

Signature is hard to generate without the secret. Message Contents Secret Owned by Signer (Private Key) Signature is hard to generate without the secret. Changing even a single bit of the message contents requires a new signature Implications: Only owner of funds can move them.

Transactions Each transaction is essentially a transfer of money from inputs to outputs (many-to-many) 1 BTC Txn 1.1 BTC 1 BTC Inputs Outputs 1.5 BTC 0.5 BTC (the fee is the difference between outputs and inputs)

Transactions Addresses are public keys Signatures are included to prove ownership (generated with private keys) More complex scripts are possible (e.g., k out of n signatures) Txn

A transaction is valid if and only if It contains all required signatures, every input matches a previous unspent output Txn

The Double-spend problem Blue: 2 Red: 1

Solve difficult computational problem Intuition: Consensus by a “cascade” Take a “vote” on which transaction to accept, Voters switch vote to join the majority. Problem: Votes are easy to “create”. Weak Identities. Solve difficult computational problem Get one vote “One CPU, One Vote”

Cryptographic Hash Functions functions that deterministically map strings (of any length) to fixed-size strings. Properties: Efficiency: easy to compute hash(x) Collision Resistance: Hard to find x,y such that hash(x)=hash(y) Hash(x) reveals little about x. Hash(x) “looks” completely random

Authenticate block & tell neighbors Block Chain New Block Hash Nonce Hash Nonce Hash Nonce Authenticate block & tell neighbors Neighbor may send an inconsistent block Nonce Hash

Make block creation hard. Block Chain New Block Hash Nonce Hash Nonce Hash Nonce Hash Solution: Make block creation hard. 00001001011011001 2. Adopt conflicting blocks if they make up a longer chain. A small number ~ one block authorization per 10 minutes (in the entire network) Difficulty scales automatically to maintain this.

Make block creation hard. Adopt conflicting blocks if they make up a longer chain. A1 A2 A1 A2 A1 A2 A1 A2 B1 A1 A2 A1 A2 B1 A1 A2 B1 Bitcoin’s Guarantee (as described by Satoshi): As long as attacker controls < 50% of computing power, probability of block replacement decreases exponentially with time.

To encourage nodes to authorize transactions: New Block Hash Nonce Reward the authorizer with fees from each transaction (+ newly minted money) Coinbase Tx Hash Block creation is known as “Mining” 00001001011011001 A small number

The Double Spend Attack It is possible that a payment will be “erased” when history is replaced. Can be exploited by attacker to get money back after a purchase

Analysis of the Attack Policy of the receiver of funds: Wait until transaction is buried inside the blockchain, at a depth of 𝑛. 𝑛 “confirmations” More confirmations harder for anyone to replace the sub-chain.

Analysis of the Attack Block creation is assumed to be a Poisson process. A node with a 𝑞-fraction of computational resources generates blocks at rate 𝜆𝑞.

Analysis of the Attack Consider a Markov Process representing the difference in length between the chains Attacker creates block (q) Network creates block (1-q) Honest chain length minus attacker’s -1 1 2 3 If we ever get here, Attacker wins 𝑛 blocks built by honest nodes, attacker has strength 𝑞 → probability distribution over initial states ∈{𝑛,𝑛−1,𝑛−2,…}.

The Result: Attacker’s strength: 𝑞<0.5 Receiver’s policy: wait for 𝑛 confirmations Probability of successful attack: 𝑟=1− 𝑚=0 𝑛 𝑚+𝑛−1 𝑚 ⋅ ( 1−q n q m − 1−q m q n ) Result due to Meni Rosenfeld: “Analysis of hashrate-based double-spending”

From Meni Rosenfeld’s paper “Analysis of hash-rate based double spending”.

Implications To get final approval for a transaction one has to wait several blocks (confirmations). Each block takes 10 minutes in expectation. Risk of an attack should take transaction size into account.

The 50% Attack An attacker with >50% of the hash power can monopolize block creation Can block any/ all transactions from entering the chain Can double spend at will Can not take someone else’s money

hash rate distribution at the time

The Finney attack Some Vendors cannot afford to wait. Accept 0-confirmation transactions. Susceptible to a simple attack: Alice pre-mines block with a transaction to self. Alice creates and sends transaction paying bob. Instantly receives goods from Bob. Alice releases pre-mined block before the transaction to Bob is even included in a block.

Altcoins Many Bitcoin clones

Mining Pools Bitcoin mining is a high risk “lottery” Miners can join together to split profits and reduce risk Miner Block header Mining Pool Server Fees Nonce

Hash rate distribution (from Blockchain.info)

How (not) to split rewards Miners that contribute more should get higher reward. Win: Hash(header)<𝑡𝑎𝑟𝑔𝑒𝑡 Get a share: Hash(header)<𝑘⋅𝑡𝑎𝑟𝑔𝑒𝑡 Pay per share: Split wins proportionately to # of shares contributed. Mining Pool Server Miner

Pool Hopping It is not known when a block will be created by the pool (a memoryless process). The first share may be worth a lot (if block found right after) The 50th share is already very “diluted” Miners are better off switching to another pool / solo mining after several shares have been found. Hop-proof reward schemes exist. Explore tradeoff between risk to pool, risk to player and time. [Meni Rosenfeld]

Challenges Regulation Adoption Volatility The pull towards centralization Incentives Scalability

The Pull Towards Centralization Advantage of large miners: Economies of scale (e.g. datacenters in Iceland) Block distribution to self not needed. Attractive connections for other miners Outcome: Large miners gain more than proportional share. Drive small miners out of business. System becomes centralized.

Incentives Is the protocol “incentive compatible”? Two issues found thus far: Miners lack the incentive to flood transaction messages to others. [Babaioff, Dobzinsky, Oren & Zohar] Miners do not necessarily want to mine on top of latest block. [Eyal & Sirer]

Selfish Mining [Ittay Eyal & Emin Gün Sirer] Miners do not necessarily want to mine on top of latest block. *depends on fast block distribution

From: Eyal, Ittay, and Emin Gün Sirer From: Eyal, Ittay, and Emin Gün Sirer. "Majority is not enough: Bitcoin mining is vulnerable." arXiv preprint arXiv:1311.0243 (2013).

Scalability Visa: ~2,000 TPS (~11,000 TPS during Christmas 2010 peak) Paypal: ~100 TPS Bitcoin: ~1 TPS Can Bitcoin grow match these? Indications are that it might be able to, but it will be hard.

Can Bitcoin Be Faster? Block rate: one every 10 minutes 2.5 minutes 12 seconds What is the effect of this? Why not go even faster?

Scalablity [Yonatan Sompolinsky & Aviv Zohar]

A Quick Calculation and some good news. Source: https://en. bitcoin Average transaction size: ~0.5KB 2000 TPS (Visa’s scale) Requires only 1MB per second to listen to all transactions Comment: messages also need to be sent out, often to several neighbors, and there are additional protocol related messages that add traffic.

Few transactions per day Blocks are currently bounded in size (under 1 MB) Few, small blocks Few transactions per day High fees, and migration off-chain

Satoshi’s analysis assumes block propagation time << 10 minutes This situation never occurs:

Generated using data generously shared by Decker & Wattenhofer

Back to TPS More TPS Larger blocks Higher block creation rates Lower security More forks in block tree Distribution time non-negligible

At high rates the main chain grows slower than the rate of block creation. More blocks conflict. #Transactions = #Blocks X #Transactions-per-block Easier for a centralized attacker to build a chain that is longer than the honest network’s chain and double-spend. 50% attack with less than 50% of hash power.

How Scalable is Bitcoin? Highly dependent on network topology An optimistic estimate: 40 TPS, vulnerable to 40% attack. A pessimistic estimate: 10 TPS, vulnerable to 25% attack (estimates make use of network measurement data produced by Decker & Wattenhoffer)

Greedy Heaviest Observed Sub-Tree (GHOST) An alternative chain selection rule (instead of “longest chain”) Begin at the “Genesis Block” At every split, pick the heaviest sub-tree. Outcome: The 50% Attack requires at least 50% of hash power B A B’

Hidden Things