CS 251 Fall 2020 cs 251 stanford edu

CS 251 Fall 2020 (cs 251. stanford. edu) Bitcoin Mechanics Dan Boneh Note: HW#1 is posted on the course web site. Due Sep. 28.

Recap •

Recap (2) Digital signatures: (Gen, Sign, Verify) Gen() �(pk, sk), Sign(sk, m) �σ, signing key Verify(pk, m, σ) �accept/reject verification key

This lecture: Bitcoin mechanics Total market value: Oct. 2008: paper by Satoshi Nakamoto Jan. 2009: Bitcoin network launched Sep. 2020: $200 B

This lecture: Bitcoin mechanics Layer 3: user facing tools (cloud servers) Layer 2: applications (DAPPs, smart contracts) Layer 1. 5: compute layer (blockchain computer) Layer 1: consensus layer next week

First: overview of the Bitcoin consensus layer end users signed Tx Bitcoin P 2 P network sk. A sk. B sk. C typically, miners are connected to eight other peers (anyone can join)

First: overview of the Bitcoin consensus layer miners broadcast received Tx to the P 2 P network mempool every miner: validates received Tx and stores them in its mempool (unconfirmed Tx) note: miners see Tx before they are posted on chain Bitcoin P 2 P network

First: overview of the Bitcoin consensus layer blockchain Every 10 minutes: • Each miner creates a candidate block from Tx in its mempool • a “random” miner is selected (how: next week), and broadcasts its block to P 2 P network • all miners validate new block I am the leader Bitcoin P 2 P network

First: overview of the Bitcoin consensus layer blockchain Selected miner is paid 6. 25 BTC in coinbase Tx (first Tx in the block) • only way new BTC is created • block reward halves every four years ⇒ max 21 M BTC (currently 18. 5 M BTC) note: miner chooses order of Tx in block 6. 25 BTC

Properties (very informal) Next week: Persistence: • to remove a block, need to convince 51% of mining power * Liveness: • to block a Tx from being posted, need to convince 51% of mining power **

Bitcoin blockchain: a sequence of block headers, 80 bytes each genesis block H version prev time bits nonce Tx root (4 bytes) H (32 bytes) (4 bytes) (32 bytes) 80 bytes coinbase Tx BH 3 BH 2 BH 1 coinbase Tx prev H prev … Tx root

Bitcoin blockchain: a sequence of block headers, 80 bytes each time: time miner assembled the block. Self reported. (block rejected if too far in past or future) bits: proof of work difficulty nonce: proof of work solution for choosing a leader (next week) Merkle tree: payer can give a short proof that Tx is in the block new block every ≈10 minutes.

An example (Sep. 2020) Tx data #Tx 1855 2826 1128 2774 2075 2622

Block 648493 (from coinbase Tx) (D) (adjusts every two weeks)

This lecture View the blockchain as a sequence of Tx (append-only) … coinbase Tx

Tx structure (non-coinbase) inputs input[0] input[1] input[2] outputs output[0] output[1] (segwit) witnesses input: Tx. ID = H(Tx) (excluding witnesses) output: (4 bytes) locktime earliest block # that can include Tx Tx. ID out-index Script. Sig seq 32 byte hash value Script. PK 8 bytes 4 byte index program ignore program value = #BTC/108 [10 -8, …, 237]

Example Tx. In[0] Tx 1: (funding Tx) Tx. Out[0] 2 Script. PK input value UTXO 1 Tx. Out[1] 5 Script. PK value null locktime 0 UTXO 2 UTXO: unspent Tx output Tx 2: (spending Tx) Tx. ID Tx. In[0] 1 Script. Sig identifies a UTXO Tx. Out[0] Tx. Out[1] output UTXO 3 UTXO 4 0

Example Tx. In[0] Tx 1: (funding Tx) Tx. Out[0] 2 Script. PK input UTXO 1 UTXO: unspent Tx output Tx 2: (spending Tx) Tx. ID Tx. In[0] 1 Script. Sig identifies a UTXO ☓ Tx. Out[1] 5 Script. PK null locktime 0 UTXO 2 Tx. Out[0] Tx. Out[1] output UTXO 3 UTXO 4 0

Validating Tx 2 program from funding Tx: under what conditions can UTXO be spent Miners check (for each input): 1. The program Script. Sig | Script. PK returns true 2. Tx. ID | index is in the current UTXO set 3. sum input values ≥ sum output values After Tx 2 is posted, miners remove UTXO 2 from UTXO set

An example (block 648493) Tx 0 input Tx 1 outputs Tx 2 sum of fees in block added to coinbase Tx [2826 Tx]

Tx fees Bitcoin average Tx fees in USD Ethereum average Tx fees in USD

Focusing on Tx 2: Tx. Inp[0] from UTXO (Bitcoin script) from Tx. Inp[0]

All value in Bitcoin is held in UTXOs Sep. 2020: miners need to store ≈70 M UTXOs in memory

Bitcoin Script A stack machine. Not Turing Complete: no loops. Quick survey of op codes: 1. OP_TRUE (OP_1), OP_2, …, OP_16: push value onto stack 81 82 96 2. OP_DUP: push top of stack onto stack 118

Bitcoin Script 3. control: 99 OP_IF <statements> OP_ELSE <statements> OP_ENDIF 105 OP_VERIFY: abort fail if top = false 106 OP_RETURN: abort and fail what is this for? Script. PK = [OP_RETURN, <data>] 136 OP_EQVERIFY: pop, abort fail if not equal

Bitcoin Script 4. arithmetic: OP_ADD, OP_SUB, OP_AND, …: pop two items, add, push 5. crypto: OP_SHA 256: pop, hash, push OP_CHECKSIG: pop sig, pop pk, verify sig. on Tx, push 0 or 1 6. Time: OP_Check. Lock. Time. Verify (CLTV): fail if value at the top of stack > Tx locktime value. usage: UTXO can specify min-time when it can be spent

Example: a common script <sig> <pk> DUP HASH 256 <pkhash> EQVERIFY CHECKSIG stack: empty <sig> <pk> <sig> <pk> <hash> <pkhash> <sig> <pk> 1 ⇒ successful termination init push values DUP HASH 256 push value EQVERIFY CHECKSIG verify(pk, Tx, sig)

Transaction types: (1) P 2 PKH pay to public key hash Alice want to pay Bob 5 BTC: • step 1: Bob generates sig key pair (pk. B, sk. B) �Gen() • step 2: Bob computes his Bitcoin address as Addr. B �H(pk. B) • step 3: Bob sends Addr. B to Alice • step 4: Alice creates Tx: input 7 BTC Script. PKB: 5 Script. PKB UTXOB for Bob 2 Script. PKA 0 UTXOA for Alice (change) DUP HASH 256 <Addr. B> EQVERIFY CHECKSIG

Transaction types: (1) P 2 PKH Later, when Bob wants to spend his UTXO: Txspend: Tx. ID 0 points to UTXOB Script. Sig. B: output create a Txspend output 0 <sig> <pk. B> <sig> = Sign(sk. B, Tx) where Tx = (Txspend excluding all Script. Sigs) (SIGHASH_ALL) Miners validate that Script. Sig. B | Script. PKB returns true

P 2 PKH: comments • Alice specifies recipient’s pk in UTXOB • Recipient’s pk is not revealed until UTXO is spent (some security against attacks on pk) • Miner cannot change <Addr. B> and steal funds: invalidates the signature that created the UTXOB

Segregated Witness ECDSA malleability: • given (m, sig) anyone can create (m, sig’) with sig ≠ sig’ ⇒ miner can change sig in Tx and change Tx. ID = SHA 256(Tx) ⇒ Tx issuer cannot tell what Tx. ID is, until Tx is posted ⇒ leads to problems and attacks Segregated witness: signature is moved to witness field in Tx Tx. ID = Hash(Tx without witnesses)

Transaction types: (2) P 2 SH: pay to script hash (pre Seg. Wit in 2017) Let’s payer specify a redeem script (instead of just pkhash) Usage: payee publishes hash(redeem script) �Bitcoint addr. payer sends funds to that address Script. PK in UTXO: HASH 160 <H(redeem script)> EQUAL Script. Sig to spend: <sig 1> <sig 2> … <sign> <redeem script> payer can specify complex conditions for when UTXO can be spent

P 2 SH Miner verifies: (1) <Script. Sig> Script. PK = true �payee gave correct script (2) Script. Sig = true �script is satisfied

Example P 2 SH: multisig Goal: spending a UTXO requires t-out-of-n signatures Redeem script for 2 -out-of-3: (set by payer) <2> <PK 1> <PK 2> <PK 3> <3> CHECKMULTISIG hash gives P 2 SH address Script. Sig to spend: (by payee) <0> <sig 1> <sig 3> <redeem script>

END OF LECTURE Next lecture: interesting scripts, wallets, and how to manage crypto assets