CS 4593/6463 – Bitcoins

and Cryptocurrencies
Prof. Murtuza Jadliwala
[email protected]

Note: most of the slides used in this course are

derived from those available for the book “Bitcoins
and Cryptocurrencies Technologies – A
Comprehensive Introduction”, Arvind Narayanan,
Joseph Bonneau, Edward Felten, Andrew Miller &
Steven Goldfeder, 2016, Princeton University Press.
Lecture 3
Mechanics of Bitcoin
Recap: Bitcoin consensus
Bitcoin consensus gives us:
• Append-only ledger
• Decentralized consensus protocol
• Miners to validate transactions

Assuming a currency exists to motivate

miners!

In this chapter we will see how such a currency can

be engineered
Bitcoin transactions
 An account-based ledger (not Bitcoin)
time
Create 25 coins and credit to AliceASSERTED BY MINERS might need to
scan backwards
Transfer 17 coins from Alice to BobSIGNED(Alice) until genesis!

Transfer 8 coins from Bob to CarolSIGNED(Bob)

Transfer 5 coins from Carol to AliceSIGNED(Carol)
Transfer 15 coins from Alice to DavidSIGNED(Alice) is this valid?

SIMPLIFICATION: only one transaction per block

 A transaction-based ledger (Bitcoin)
Inputs: Ø
1
time Outputs: 25.0→Alice No
signature required we implement this
with hash pointers
change address
2 Inputs: 1[0]
Outputs: 17.0→Bob, 8.0→Alice
SIGNED(Alice)
finite scan to
3 Inputs: 2[0] 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(Alice)
..
.
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(Alice)
..
.
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
{ also serves as a
transaction hash "hash":"5a42590...b8b6b", unique ID
"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 "hash":"3be4...80260",
transaction
"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
OP_EQUALVERIFY OP_CHECKSIG"
recipient },
address?? ... more on this soon...
(more outputs) ]

Sum of all output values less than or equal to sum of all input values!
If sum of all output values less than sum of all input values, then difference
goes to miner as a transaction fee
Bitcoin scripts
Output “addresses” are really scripts

OP_DUP
OP_HASH160
69e02e18...
OP_EQUALVERIFY OP_CHECKSIG
 Input “addresses” are also scripts
(from the redeeming transaction)

30440220...
scriptSig
0467d2c9...

(from the transaction being redeemed)

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
• Support for cryptography
• Stack-based (linear) I am not impressed
• Limits on time/memory
• No looping
• Result: Bitcoin script is not Turing Complete!
i.e, cannot compute arbitrarily powerful
functions
• Advantage: No infinite looping problem!

image via Jessie St. Amand

Bitcoin scripting language (“Script”)
• 256 instructions (each represented by 1 byte)
• 75 reserved, 15 disabled
• Basic arithmetic, basic logic (“if”  “then”), throwing errors,
returning early, crypto instructions (hash computations,
signature verifications), etc.

• Only two possible outcomes of a Bitcoin script

• Executes successfully with no errors  transaction is valid OR
• Error while execution  transaction invalid and should not be
accepted in the block chain
Common script instructions
Name Functions
OP_DUP Duplicates top item on the stack

OP_HASH160 Hashes twice: first using SHA-256, then using RIPEMD-160

OP_EQUALVERIFY Returns true if inputs are equal, false (marks transaction invalid)
otherwise
OP_CHECKSIG Checks that the input signature is valid using input public key for
the hash of the current transaction
OP_CHECKMULTISIG Checks that t signatures on the transaction are valid from t (out
of n) of the specified public keys
OP_CHECKMULTISIG
• Built-in support for joint signatures
• Specify n public keys
• Specify t
• Verification requires t signatures are valid
BUG ALERT: Extra data value
popped from the stack and
ignored
 Bitcoin script execution example

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

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

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

Applications of Bitcoin scripts
Example 1: Escrow transactions
(disputed
(normal case)
case)
Judy Pay x to Alice
Bob
SIGNED(ALICE,JUDY)
SIGNED(ALICE, BOB)

To: Alice
From: Bob

PROBLEM: Alice wants to buy online from

Alice
Pay x Alice
Bob. to 2-of-3 of Alice,
doesn’t wantBob, Judy
to pay until after Bob
(MULTISIG) Bob ships.
Bob doesn’t want to ship until after Alice
SIGNED(ALICE)
 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)

PROBLEM: Alice wants to pay Bob.

Alice 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??
Input: x; Pay 42 to Bob, 58 to Alice
all of these SIGNED(ALICE)
SIGNED(ALICE)___________
SIGNED(BOB)
could be
double-spends!
...
Alice demands a timed refund transaction before starting
Input: x; Pay 100 04 totoBob,
Alice,96LOCK
to Aliceuntil time
SIGNED(ALICE)___________
t
Input: x; Pay 03 to Bob, 97SIGNED(ALICE)
I’m done! to AliceSIGNED(BOB)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
minute Bob
Alice Input: y;of phone
Pay service.
100 to She (MULTISIG)
Bob/Alice doesn’t want
to incur a transaction fee every SIGNED(ALICE)
minute.
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”
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: trans: trans:
H( ) H( ) 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...",
"time":1391279636,
"bits":419558700,
block header "nonce":459459841,
"mrkl_root":"89776...",
"n_tx":354,
"size":181520,
"tx":[
...
],
"mrkl_tree":[
"6bd5eb25...",
...
"89776cdb..."
]
}
transaction
data
 The real deal: a Bitcoin block header
{
"hash":"00000000000000001aad2...",
"ver":2,
"prev_block":"00000000000000003043...",
mining "time":1391279636, hashed
puzzle "bits":419558700, during
information "nonce":459459841, mining
"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 on brink of second
}, bailout for banks”
"out":[ block reward
transaction fees
{
"value":"25.03371419",
"scriptPubKey":"OPDUP OPHASH160 ... ”
}
See for yourself!

blockchain.info (and many other sites)

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
heard that!
5
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)
• Run script for each previous output being redeemed and
ensure that script returns true!
• Script matches a whitelist
• Avoid unusual scripts Sanity checks only...
• Haven’t seen before Well-behaving nodes implement them!
Some nodes may ignore them!
• Avoid infinite loops
• Doesn’t conflict with others I’ve relayed
• Avoid double-spends
Nodes may
New tx! differ on transaction pool
A→C

A→C 5
1 A→C A→B
A→C
A→C 7
A→B
A→C
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 the 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 (in 2014)

20 GB
Storage costs (in 2018)
160 GB

Source: blockchain.info
Tracking the UTXO set
• Unspent Transaction Output
• Should be stored in memory - everything else can be
stored on disk, why?

65 M

Source: blockchain.info
Tracking the UTXO set
• Currently ~65 M UTXOs
• Out of 300 M transactions
• Can require several Gigabytes to store – can it fit in the RAM of a standard
computer?

300 M

Source: blockchain.info
Thin/SPV clients (not fully-validating)
SPV – Simplified Payment Verification (e.g., Wallet nodes)

Idea: Don’t store everything

• Store block headers – verify the puzzle was solved correctly, but cannot verify
every transaction in each blocl!
• Validate only those transactions that affect them  By requesting
transactions as needed
• To verify incoming payment
• Trust fully-validating nodes
1000x cost savings! Requires only a few tens of Megabytes (compare to tens of
Gigabytes needed for fully validating nodes)
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”
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
These affect
• 100 M satoshis per bitcoin economic
balance of
• 23M total bitcoins maximum power too
much to change
• 50,25,12.5... bitcoin mining reward 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
That’s
Block 24
23
24 crazy talk!!

I found a nifty 3
6 24 new block! Block
Block 23
24
Block 23 2
Block 23
24
24
4 PROBLEM: Old nodes will never
Block 23
24
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 the 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