CS251 Fall 2023

(cs251.stanford.edu)

Bitcoin Mechanics
Dan Boneh

Reminder: proj #1 is posted on the course web site. Due Oct. 4

 Recap

(1) SHA256: a collision resistant hash function

that outputs 32-byte hash values

Applications:

• a binding commitment to one value: commit() ⇾ H()

or to a list of values: commit() ⇾ Merkle()

• Proof of work with difficulty D:

given find s.t. takes time
 Digital Signatures
Physical signatures: bind transaction to author

Bob agrees to pay Alice 1$

Bob agrees to pay Alice 100$

Problem in the digital world:

anyone can copy Bob’s signature from one doc to another
 Digital signatures
Solution: make signature depend on document
Signer
Verifier
‘accept’
Bob agrees to pay Alice 1$
verifier or
‘reject’
signature

signing
secret signing
algorithm public verification
key (sk) key (pk)
 Digital signatures: syntax
Def: a signature scheme is a triple of algorithms:
• Gen(): outputs a key pair (pk, sk)
• Sign(sk, msg) outputs sig. σ
• Verify(pk, msg, σ) outputs ‘accept’ or ‘reject’

Secure signatures: (informal)

Adversary who sees signatures on many messages of his
choice,
cannot forge a signature on a new message.
 Families of signature schemes
1. RSA signatures (old … not used in blockchains):
• long sigs and public keys (≥256 bytes), fast to verify

2. Discrete-log signatures: Schnorr and ECDSA (Bitcoin, Ethereum)

• short sigs (48 or 64 bytes) and public key (32 bytes)

3. BLS signatures: 48 bytes, aggregatable, easy threshold

(Ethereum 2.0, Chia, Dfinity)

4. Post-quantum signatures: long (≥600 bytes)

details in CS255
 Signatures on the blockchain
Signatures are used everywhere: verify
• ensure Tx authorization, Tx
• governance votes, verify
verify Tx
• consensus protocol votes. Tx

sk1 data signatures

sk2 data signatures

 In summary …
Digital signatures: (Gen, Sign, Verify)

Gen() ⇾ (pk, sk),

Sign(sk, m) ⇾ σ, Verify(pk, m, σ) ⇾
accept/reject

signing key
verification key
Bitcoin mechanics
 This lecture: Bitcoin mechanics
Oct. 2008: paper by Satoshi Nakamoto
Jan. 2009: Bitcoin network launched
Total market value:
Sep. 2023: $528B
This lecture: Bitcoin mechanics
user facing tools (cloud servers)

applications (DAPPs, smart contracts)

Execution engine (blockchain computer) today

Sequencer: orders transactions

Data Availability / Consensus Layer

next week
 First: overview of the Bitcoin consensus
layer
Bitcoin P2P network
end users signed Tx

skA

skB

skC
typically, miners are connected to
eight other peers (anyone can join)
 First: overview of the Bitcoin consensus
layer mempool
miners broadcast received Tx
to the P2P network

every miner:
validates received Tx and
stores them in its mempool
(unconfirmed Tx)

note: miners see all Tx before

they are posted on chain
Bitcoin P2P network
 First: overview of the Bitcoin consensus
blockchain
layer
I am the
leader
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 P2P network
• all miners validate new block Bitcoin P2P network
 First: overview of the Bitcoin consensus
blockchain
layer

6.25 BTC
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 21M BTC (currently 19.6M BTC)

note: miner chooses order of Tx in block

 Properties (very informal)

Next week:

Safety / 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 **
(some sub 50% censorship attacks, such as feather
forks)
 Bitcoin blockchain: a sequence of block headers, 80 bytes each
genesis
block BH1 BH2 BH3
version (4 bytes)
H H prev H prev
prev (32 bytes)
time (4 bytes) …
bits (4 bytes)
nonce (4 bytes)
Tx root (32 bytes) Tx root Tx root
80 bytes
coinbase Tx
coinbase Tx
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 for choosing a leader (next week)

nonce: proof of work solution

Merkle tree: payer can give a short proof that Tx is in the block

new block every ≈10 minutes.

An example
Tx data
#Tx

1855

2826

1128

2774

2075

2622
 Block 648493

(from coinbase Tx)

(D) (adjusts every two weeks)

(Tx fees given to miner in coinbase Tx)

 This lecture

View the blockchain as a sequence of Tx (append-only)

coinbase Tx
 Tx structure (non-coinbase)
input[0] input: TxID 32 byte hash
inputs input[1] out-index 4 byte index
input[2] ScriptSig program
seq ignore
outputs output[0] TxID = H(Tx)
output[1] (excluding witnesses)

value 8 bytes
(segwit) witnesses output:
(part of input) ScriptPK program
(4 bytes)
locktime
#BTC = value/108
earliest block # that can include Tx
 Example
null locktime
TxIn[0] TxOut[0] TxOut[1]
Tx1: input 2 ScriptPK 5 ScriptPK 0
(funding Tx) value value
UTXO1 UTXO2
UTXO: unspent Tx output

TxIn[0] TxOut[0] TxOut[1]

Tx2: TxID 1 ScriptSig output output 0
(spending Tx) identifies UTXO3 UTXO4
a UTXO
 Example

☓
null locktime
TxIn[0] TxOut[0] TxOut[1]
Tx1: input 2 ScriptPK 5 ScriptPK 0
(funding Tx) value value
UTXO1 UTXO2
UTXO: unspent Tx output

TxIn[0] TxOut[0] TxOut[1]

Tx2: TxID 1 ScriptSig output output 0
(spending Tx) identifies UTXO3 UTXO4
a UTXO
 Validating Tx2
program from funding Tx:

Miners check (for each input): under what conditions

can UTXO be spent

1. The program ScriptSig | ScriptPK returns true

2. TxID | index is in the current UTXO set

3. sum input values ≥ sum output values

After Tx2 is posted, miners remove UTXO2 from UTXO set

 An example (block 648493) [2826 Tx]

Tx0
6.25 + Tx fees =

input (input UTXO value)

Tx1 outputs
(Tx fee)

(Tx fee) Tx2

sum of fees in block added to coinbase Tx
 Tx fees
Bitcoin average Tx fees in USD (last 60 days, sep. 2023)

$2.11

Bitcoin average Tx fees in USD (all time)

 All value in Bitcoin is held in UTXOs

130M

Sep. 2023: miners need to store ≈130M UTXOs in memory

Focusing on Tx2: TxInp[0]
from UTXO
(Bitcoin script)

from TxInp[0]
 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? ScriptPK = [OP_RETURN,
<data>]
136
OP_EQVERIFY: pop, pop, abort fail if not equal
 Bitcoin Script
4. arithmetic:
OP_ADD, OP_SUB, OP_AND, …: pop two items, add, push
5. crypto:
OP_SHA256: pop, hash, push
OP_CHECKSIG: pop pk, pop sig, verify sig. on Tx, push 0 or 1
6. Time: OP_CheckLockTimeVerify (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 HASH256 <pkhash> EQVERIFY CHECKSIG

stack: empty init

<sig> <pk> push values
<sig> <pk> <pk> DUP
<sig> <pk> <hash> HASH256
<sig> <pk> <hash> <pkhash> push value
<sig> <pk> EQVERIFY
1 CHECKSIG verify(pk, Tx, sig)
⇒ successful termination
 Transaction types: (1) P2PKH
pay to public key hash
Alice want to pay Bob 5 BTC:
• step 1: Bob generates sig key pair (pkB, skB) ⇽ Gen()
• step 2: Bob computes his Bitcoin address as addrB ⇽ H(pkB)
• step 3: Bob sends addrB to Alice
• step 4: Alice posts Tx: UTXOB for Bob UTXOA for Alice (change)
Point to input
5 ScriptPKB 2 ScriptPKA 0
Alice’s UTXO 7 BTC

ScriptPKB: DUP HASH256 <addrB> EQVERIFY CHECKSIG

 Transaction types: (1) P2PKH
pay to public key hash
“input” contains ScriptSig that authorizes spending Alice’s UTXO
• example: ScriptSig contains Alice’s signature on Tx
⟹ miners cannot change ScriptPKB (will invalidate Alice’s
signature)
UTXOB for Bob UTXOA for Alice (change)
Point to input
5 ScriptPKB 2 ScriptPKA 0
Alice’s UTXO 7 BTC

ScriptPKB: DUP HASH256 <addrB> EQVERIFY CHECKSIG

 Transaction types: (1) P2PKH
Later, when Bob wants to spend his UTXO: create a Txspend

Txspend: TxID 0 ScriptSigB output output 0

points to
UTXOB
<sig> <pkB> (authorizes spending UTXOB)

<sig> = Sign(skB, Tx) where Tx = (Txspend excluding all ScriptSigs) (SIGHASH_ALL)

Miners validate that ScriptSigB | ScriptPKB returns true

 P2PKH: 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 <AddrB> and steal funds:

invalidates Alice’s signature that created UTXOB
 Segregated Witness

ECDSA malleability:
Given (m, sig) anyone can create (m, sig’) with sig ≠ sig’
⇒ miner can change sig in Tx and change TxID = SHA256(Tx)
⇒ Tx issuer cannot tell what TxID is, until Tx is posted
⇒ leads to problems and attacks

Segregated witness: signature is moved to witness field in Tx

TxID = Hash(Tx without witnesses)
Transaction types: (2) P2SH: pay to script hash
(pre SegWit 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

ScriptPK in UTXO: HASH160 <H(redeem script)> EQUAL

ScriptSig to spend: <sig1> <sig2> … <sign> <redeem script>

payer can specify complex conditions for when UTXO can be spent
 P2SH

Miner verifies:
(1) <ScriptSig> ScriptPK = true ⟵ payee gave correct script
(2) ScriptSig = true ⟵ script is satisfied
 Example P2SH: multisig

Goal: spending a UTXO requires t-out-of-n signatures

Redeem script for 2-out-of-3: (set by payer)

<2> <PK1> <PK2> <PK3> <3> CHECKMULTISIG

hash gives P2SH address

ScriptSig to spend: (by payee) <0> <sig1> <sig3> <redeem script>

 END OF LECTURE

Next lecture: interesting scripts,

wallets, and how to manage crypto
assets