Lecture 3

Mechanics of Bitcoin
Recap: Bitcoin consensus
Bitcoin consensus gives us:
● Append-only ledger
● Decentralized consensus
● Miners to validate transactions

assuming a currency exists to motivate miners!

 Lecture 3.1:

Bitcoin transactions
 An account-based ledger (not Bitcoin)
time
might need to
Create 25 coins and credit to AliceASSERTED BY MINERS scan backwards
until genesis!
Transfer 17 coins from Alice to BobSIGNED(Alice)
Transfer 8 coins from Bob to CarolSIGNED(Bob)
Transfer 5 coins from Carol to AliceSIGNED(Carol)
is this valid?
Transfer 15 coins from Alice to DavidSIGNED(Alice)

SIMPLIFICATION: only one transaction per block

 A transaction-based ledger (Bitcoin)
1
time Inputs: Ø
Outputs: 25.0→Alice we implement this
with hash pointers
change address
2 Inputs: 1[0]
Outputs: 17.0→Bob, 8.0→Alice
SIGNED(Alice)

3 Inputs: 2[0] finite scan to

check for validity
Outputs: 8.0→Carol, 7.0→Bob
SIGNED(Bob)

4 Inputs: 2[1]
is this valid?
Outputs: 6.0→David, 2.0→Alice
SIGNED(Alice)

SIMPLIFICATION: only one transaction per block

 Merging value
time
1 Inputs: ...
Outputs: 17.0→Bob, 8.0→Alice
SIGNED(Alice)
...

2 Inputs: 1[1]
Outputs: 6.0→Carol, 2.0→Bob
SIGNED(Carol)
...
3 Inputs: 1[0], 2[1]
Outputs: 19.0→Bob
SIGNED(Bob)

SIMPLIFICATION: only one transaction per block

 Joint payments
time
1 Inputs: ...
Outputs: 17.0→Bob, 8.0→Alice
SIGNED(Alice)
...

2 Inputs: 1[1]
Outputs: 6.0→Carol, 2.0→Bob
SIGNED(Carol)
...
3 Inputs: 2[0], 2[1]
two signatures!
Outputs: 8.0→David
SIGNED(Carol), SIGNED(Bob)

SIMPLIFICATION: only one transaction per block

 The real deal: a Bitcoin transaction
{
"hash":"5a42590fbe0a90ee8e8747244d6c84f0db1a3a24e8f1b95b10c9e050990b8b6b",
"ver":1,
"vin_sz":2,
metadata "vout_sz":1,
"lock_time":0,
"size":404,
"in":[
{
"prev_out":{
"hash":"3be4ac9728a0823cf5e2deb2e86fc0bd2aa503a91d307b42ba76117d79280260",
"n":0
},
"scriptSig":"30440..."
},
input(s) {
"prev_out":{
"hash":"7508e6ab259b4df0fd5147bab0c949d81473db4518f81afc5c3f52f91ff6b34e",
"n":0
},
"scriptSig":"3f3a4ce81...."
}
],
"out":[
{
"value":"10.12287097",
output(s) "scriptPubKey":"OP_DUP OP_HASH160 69e02e18b5705a05dd6b28ed517716c894b3d42e OP_EQUALVERIFY OP_CHECKSIG"
}
]
}
 The real deal: transaction metadata
{
transaction hash "hash":"5a42590...b8b6b",
"ver":1,
housekeeping "vin_sz":2,
"vout_sz":1,
“not valid before” "lock_time":0, more on this later...
housekeeping "size":404,
...
}
 The real deal: transaction inputs
"in":[
{
"prev_out":{
previous
transaction "hash":"3be4...80260",
"n":0
},
signature "scriptSig":"30440....3f3a4ce81"
},
(more inputs) ...
],
 The real deal: transaction outputs
"out":[
{
output value
"value":"10.12287097",
"scriptPubKey":"OP_DUP OP_HASH160 69e...3d42e
recipient
address?? OP_EQUALVERIFY OP_CHECKSIG"
}, more on this soon...
...
(more outputs) ]
Lecture 3.2:

Bitcoin scripts
Output “addresses” are really scripts

OP_DUP
OP_HASH160
69e02e18...
OP_EQUALVERIFY OP_CHECKSIG
 Input “addresses” are also scripts

scriptSig
30440220...
0467d2c9...

OP_DUP
scriptPubKey
OP_HASH160
69e02e18...
OP_EQUALVERIFY OP_CHECKSIG
TO VERIFY: Concatenated script must execute completely with no errors
Bitcoin scripting language (“Script”)
Design goals
● Built for Bitcoin (inspired by Forth)
● Simple, compact I am not impressed
● Support for cryptography
● Stack-based
● Limits on time/memory
● No looping
image via Jessie St. Amand
 Bitcoin script execution example

✓
<pubKeyHash?>
<pubKey>
<pubKeyHash>
<pubKey>
<sig>
true

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash?> OP_EQUALVERIFY OP_CHECKSIG

Bitcoin script instructions
256 opcodes total (15 disabled, 75 reserved)
● Arithmetic
● If/then
● Logic/data handling
● Crypto!
○ Hashes
○ Signature verification
○ Multi-signature verification
OP_CHECKMULTISIG

● Built-in support for joint signatures

● Specify n public keys
● Specify t
● Verification requires t signatures

BUG ALERT: Extra data value

popped from the stack and ignored
Bitcoin scripts in practice (as of 2014)

● Most nodes whitelist known scripts

● 99.9% are simple signature checks
● ~0.01% are MULTISIG More on this soon
● ~0.01% are Pay-to-Script-Hash
● Remainder are errors, proof-of-burn
Proof-of-burn

nothing’s going to redeem that ☹

OP_RETURN
<arbitrary data>
Should senders specify scripts?
?
I’m ready to pay for my purchases! Big Box

Cool! Well we’re using MULTISIG now,

so include a script requiring 2 of our 3
account managers to approve. Don’t
get any of those details wrong. Thanks
for shopping at Big Box!
Idea: use the hash of redemption script

<signature>
<signature>
<<pubkey> OP_CHECKSIG>

OP_HASH160
<pubkey>
<hash of redemption script>
OP_CHECKSIG
OP_EQUAL

“Pay to Script Hash”

Pay to script hash
I’m ready to pay for my purchases! Big Box

Great! Here’s our address: 0x3454

 Lecture 3.3:

Applications of Bitcoin scripts

Example 1: Escrow transactions
(normal case)
Pay x to Bob
Judy
SIGNED(ALICE, BOB)

Pay x to Alice (disputed case)

SIGNED(ALICE, JUDY)
To: Alice
From: Bob

Alice Pay x to 2-of-3

PROBLEM: Aliceofwants
Alice,to
Bob,
buyJudy (MULTISIG)
online from Bob. Bob
Alice doesn’t want to pay until after Bob ships.
SIGNED(ALICE)

Bob doesn’t want to ship until after Alice pays.

 Example 2: Green addresses
004 days since last double spend!

It’s me, Alice! Could you make out

a green payment to Bob? Faraday cage
Bank

Pay x to Bob, y to Bank No double spend

SIGNED(BANK)

Alice PROBLEM: Alice wants to pay Bob. Bob

Bob can’t wait 6 verifications to guard against
double-spends, or is offline completely.
 Example 3: Efficient micro-payments
What if Bob never signs??

all of these could

Input: x; Pay 42 to Bob, 58 to Alice
SIGNED(ALICE)
SIGNED(ALICE)___________
SIGNED(BOB)
be
double-spends! ...
Alice demands a timed refund transaction before starting
Input: x; Pay 04 to Bob, 96 to Alice
Input: x; Pay 100 to Alice, LOCKSIGNED(ALICE)___________
until time t
SIGNED(ALICE) SIGNED(BOB)
Input: x; Pay 03 to Bob, 97 to Alice
I’m done! I’ll publish!
SIGNED(ALICE)___________

Input: x; Pay 02 to Bob, 98 to Alice

SIGNED(ALICE)___________

Input: x; Pay 01 to Bob, 99 to Alice

SIGNED(ALICE)___________
PROBLEM: Alice wants to pay Bob for each
Bob
Alice minute
Input: of phone
y; Pay 100 toservice. She(MULTISIG)
Bob/Alice doesn’t want to
incur a transaction fee every minute.
SIGNED(ALICE)
lock_time
{
"hash":"5a42590...b8b6b",
"ver":1,
"vin_sz":2,
"vout_sz":1,
"lock_time":315415,
"size":404, Block index or real-world timestamp before
which this transaction can’t be published
...
}
More advanced scripts
● Multiplayer lotteries
● Hash pre-image challenges
● Coin-swapping protocols
○ Don’t miss the lecture on anonymity!

“Smart contracts”
Lecture 3.4:

Bitcoin blocks
Bitcoin blocks

Why bundle transactions together?

● Single unit of work for miners
● Limit length of hash-chain of blocks
○ Faster to verify history
 Bitcoin block structure
Hash chain of blocks

prev: H( ) prev: H( ) prev: H( )

trans: H( ) trans: H( ) trans: H( )

H( ) H( )

Hash tree (Merkle tree) of

transactions in each block
H( ) H( ) H( ) H( )

transaction transaction transaction transaction

 The real deal: a Bitcoin block
{
"hash":"00000000000000001aad2...",
"ver":2,
"prev_block":"00000000000000003043...",
block header "time":1391279636,
"bits":419558700,
"nonce":459459841,
"mrkl_root":"89776...",
"n_tx":354,
"size":181520,
"tx":[
...
transaction ],
data "mrkl_tree":[
"6bd5eb25...",
...
"89776cdb..."
]
}
 The real deal: a Bitcoin block header
{
"hash":"00000000000000001aad2...",
"ver":2,
mining puzzle "prev_block":"00000000000000003043...", hashed
information during mining
"time":1391279636,
"bits":419558700,
"nonce":459459841,
"mrkl_root":"89776...",
... not hashed

}
 The real deal: coinbase transaction
"in":[
{
Null hash pointer
"prev_out":{
redeeming "hash":"000000.....0000000",
nothing
"n":4294967295
}, First ever coinbase parameter:
arbitrary
"coinbase":"..." “The Times 03/Jan/2009 Chancellor
}, block reward
on brink of second bailout for banks”
"out":[
transaction fees
{
"value":"25.03371419",
"scriptPubKey":"OPDUP OPHASH160 ... ”
}
See for yourself!

blockchain.info (and many other sites)

 Lecture 3.5:

The Bitcoin network

Bitcoin P2P network
● Ad-hoc protocol (runs on TCP port 8333)
● Ad-hoc network with random topology
● All nodes are equal
● New nodes can join at any time
● Forget non-responding nodes after 3 hr
Joining the Bitcoin P2P network
Hello World! I’m 5
1
ready to Bitcoin!

7
getaddr() getaddr()
1, 7 getaddr()
8

3
6
2

4
Transaction propagation (flooding)
Already
5 heard that!
1

7
A→B
8
A→B A→B
A→B New tx! 3
6 A→B A→B
A→B 2
A→B
A→B A→B
4
A→B
Should I relay a proposed transaction?
● Transaction valid with current block chain
● (default) script matches a whitelist
○ Avoid unusual scripts
● Haven’t seen before Sanity checks only...
○ Avoid infinite loops Some nodes may ignore them!

● Doesn’t conflict with others I’ve relayed

○ Avoid double-spends
Nodes may differ on transaction pool
New tx!
A→C

A→C 5
1 A→C A→B
A→C
A→C 7
A→C A→B
8
A→B
A→B

3
6 A→B
A→B 2
A→B

4
A→B
Race conditions
Transactions or blocks may conflict
● Default behavior: accept what you hear first
● Network position matters
● Miners may implement other logic!
Stay tune for our lecture on mining!
Block propagation nearly identical
Relay a new block when you hear it if:
● Block meets the hash target
● Block has all valid transactions
○ Run all scripts, even if you wouldn’t relay
● Block builds on current longest chain
○ Avoid forks
Sanity check
Also may be ignored...
Source: Yonatan Sompolinsky and Aviv Zohar: “Accelerating Bitcoin’s Transaction Processing” 2014
How big is the network?
● Impossible to measure exactly
● Estimates-up to 1M IP addresses/month
● Only about 5-10k “full nodes”
○ Permanently connected
○ Fully-validate
● This number may be dropping!
Fully-validating nodes
● Permanently connected
● Store entire block chain
● Hear and forward every node/transaction
Storage costs

20 GB
Tracking the UTXO set
● Unspent Transaction Output
○ Everything else can be stored on disk
● Currently ~12 M UTXOs
○ Out of 44 M transactions
● Can easily fit into RAM
Thin/SPV clients (not fully-validating)
Idea: don’t store everything
● Store block headers only
● Request transactions as needed
○ To verify incoming payment
● Trust fully-validating nodes

1000x cost savings! (20 GB-23MB)

Software diversity
● About 90% of nodes run “Core Bitcoin” (C++)
○ Some are out of date versions
● Other implementations running successfully
○ BitcoinJ (Java)
○ Libbitcoin (C++)
○ btcd (Go)
● “Original Satoshi client”
 Lecture 3.6:

Limitations & improvements

Hard-coded limits in Bitcoin
● 10 min. average creation time per block
● 1 M bytes in a block
● 20,000 signature operations per block
● 100 M satoshis per bitcoin
These affect
● 23M total bitcoins maximum economic
balance of power
● 50,25,12.5... bitcoin mining reward too much to
change now
Throughput limits in Bitcoin
● 1 M bytes/block (10 min)
● >250 bytes/transaction
● 7 transactions/sec ☹

Compare to:
● VISA: 2,000-10,000 transactions/sec
● PayPal: 50-100 transaction/sec
Cryptographic limits in Bitcoin
● Only 1 signature algorithm (ECDSA/P256)
● Hard-coded hash functions

Crypto primitives might break by 2040...

“Hard-forking” changes to Bitcoin
5
1 Block 23
24
Block 23

7
Block 23
24
That’s 8
crazy talk!! Block 23
24 That’s
Block
24 crazy talk!!

I found a nifty 3
6 24 new block! Block
Block 23
24
Block 23 2
Block 23
24
24
4
Block 23
24 PROBLEM: Old nodes will never catch up
Soft forks
Observation: we can add new features which
only limit the set of valid transactions

Need majority of nodes to enforce new rules

Old nodes will approve

RISK: Old nodes might mine now-invalid blocks
Soft fork example: pay to script hash

<signature>
<<pubkey> OP_CHECKSIG>

OP_HASH160
<hash of redemption script>
OP_EQUAL

Old nodes will just approve the hash, not run the embedded script
Soft fork possibilities
● New signature schemes
● Extra per-block metadata
○ Shove in the coinbase parameter
○ Commit to UTXO tree in each block
Hard forks
● New op codes
● Changes to size limits
● Changes to mining rate
● Many small bug fixes
Currently seem very unlikely to happen

Stay tuned for our lecture on altcoins!

In the next lecture...
Human beings aren’t Bitcoin nodes
● How do people interact with the network?
● How do people exchange bitcoins for cash?
● How do people securely store bitcoins?

Currency needs to work for people, not nodes