Aviv Zohar

The Rachel & Selim Benin School of Eng. and Computer Science
The Hebrew University
In this tutorial:

 What is Bitcoin and how does is work?

 What are the main challenges?
 The surrounding ecosystem
 Pointers to related research & additional
sources of information
Money isn’t perfect

Currently slower and more expensive than:

 A decentralized digital currency

Invented by Satoshi Nakamoto in 2008

Launched in 2009

Built for the age of the internet

 Features of Bitcoin

Pseudonymous Fixed amount

Irreversible Transfers Cannot be seized Can not be frozen

Escrow Joint accounts

*From Bitstamp.net
 Blue: 2
Red: 1
• Bypass
regulation &
Please
transfer $1 censorship
to Blue

• Increase
competition

• Disrupt
 Blue: 2
Red: 1
Blue: 2
Blue: 2 Red: 1
Blue: 2
Red: 1
Red: 1

Blue: 2
Blue: 2 Red: 1
Red: 1
Blue: 2
Blue: 2 Red: 1
Red: 1
Transactions are thus public, addresses are (free) pseudonyms
 The Double-spend problem

2
Blue: 3
Red: 1

Blue: 2
Green:
Red: 11

A variant of the Byzantine general’s problem (Byzantine consensus

in asynchronous dist. systems)
 Block Chain New Block

Hash Hash Hash

• Blocks aggregate transactions in batches

• Each block contains a cryptographic hash of the prev one,

“proving” it is created afterwards.

• Can Read ledger from start to finish to “follow the money”

• Each node tries to grow the chain with recent transactions:

• Create a block with recent consistent transactions
• Send to peers
 Block Chain New Block

Hash Hash Hash

Hash
Inconsistency may occur if blocks
are created simultaneously by
different nodes

(double spend problem)

Another Node’s Block

 Block Chain New Block

Hash Nonce Hash Nonce Hash Nonce

Crypt. Hash

Solution: 00000001011011001
10101001011011001
1. Make block creation hard.
2. Adopt conflicting blocks if they make Must be a small number for
up a longer chain. valid block
(under some target value)
If not, change Nonce & try again

~ one block per 10 min. in the entire network

(Difficulty scales automatically to maintain this)
Current traget has ~65 zeros in most significant digits
 A 𝐵1 C

1. Make block creation hard A 𝐵1 C

(once every 10 minutes) A 𝐵1 C
A 𝐵12 C
2. Adopt (conflicting) blocks iff
they make up a longer chain.
A 𝐵1 C
A 𝐵1 C

A 𝐵12 C
A 𝐵1 C

A 𝐵1 C

𝐵2
The Double-Spend Attack
 A payment can be reversed!
 Easy if attacker has >50% of compute power
 Possible with less than 50%

Bitcoin’s Guarantee [Satoshi]:

If attacker controls < 50% of compute 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
Coinbase Tx
money)

Block creation is known as “Mining”

Block size is limited (currently to 1MB)
Transactions will compete to enter – highest fee first.
(An auction!)
Analysis of the Double Spend
Attack
The recipient has an acceptance strategy:
 # of “confirmations” (blocks) it waits for
before transaction is considered
“accepted”.
 Assumption: attacker has hashrate q.
Yields distribution over the # of blocks in
its chain.
 Analysis of the Attack
 Consider a Markov Process
representing the difference in length
between the chains
Attacker Network
creates creates
block (q) block (1-q)

Honest chain
length minus -1 0 1 2 3
attacker’s
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
𝑟 =1− ⋅ ( 1 − q n qm − 1 − q m qn )
𝑚
𝑚=0

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 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 release pre-mined block before the
transaction to Bob is authorized.
Additional Attack Vectors
 Network-structure attacks
 Isolating a node implies you can use its computational
power to launch double spend attacks
 Sybil attacks

 DDoS attacks with amplification

 Blocks are secure by difficulty, blocks that are too old are
not allowed
 Transactions are secured by fee

 Clock Drift attacks (Timejacking)

 0-Confirmation attacks & chain splits based on

different versions
Addresses
 Addresses are
(essentially) public keys

 Allow sending Bitcoins

even when recipient is
offline

 Signatures are used to

prove ownership
(generated with private
keys)

 Security matters!
paper wallets / cold
storage.
Transactions
 Each transaction is a transfer of money
from inputs to outputs
(many-to-many)

1 BTC
1.1 BTC

Inputs 1 BTC
Txn Outputs
1.5 BTC 0.5 BTC

(the fee is the difference between

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

Txn
 Transactions Txn

 outputs specify amount and “script” for

redeeming money.
OP_DUP OP_HASH160 5df3d323c10c8563e9086074c4bd94eab97b95a8
OP_EQUALVERIFY OP_CHECKSIG

 Inputs specify data for script to return

“True”

 Some outputs
cannot be redeemed.
Scripts allow for much more…
 k out of n signatures
 Delayed payments
 Savings accounts

 P2P bets
 Derivatives
 Distributed exchanges

 Implemented on top of Bitcoin

 or in alternative chains
Altcoins
 Many Bitcoin clones
Zerocoin / Zerocash
[Ben-Sasson, Chiesa, Garman, Green, Miers, Tromer, and Virza]

 Improved anonymity for Bitcoin using

advanced cryptographic tools
 zero-knowledge Succinct Non-interactive
ARguments of Knowledge (zk-SNARKs)

 Hides transaction origin, destination &

amount.

 Most importantly: efficient implementation

makes otherwise heavy crypto practical
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?
Two related problems
[Sompolinsky & Zohar]

A block every 10 minutes

 A Long wait for transaction
confirmations

1MB per block (per 10 minutes)

 A limit on number of transactions
per second (3.3 TPS)
 Higher block
Larger blocks
creation rates

More forks in
chain

*Data generously shared by Decker & Wattenhofer

 Higher block
Larger blocks
creation rates

More forks in
chain

Modest
increase in
TPS
 Higher block
Larger blocks
creation rates

More forks in
chain

Modest
Lower
increase in
security
TPS

50% attack with

less than 50%
of hash power
Greedy Heaviest Observed Sub-Tree (GHOST)
[Sompolinsky & Zohar]
An alternative chain selection rule
(instead of “longest chain”)
 Begin at the “Genesis Block”
 At every split, pick the heaviest sub-tree.

Outcome: 50% attack only works with 50% of compute power.

B GHOST

Longest
B’ Chain

Attacker’s
Secret
Chain
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.

 Gets worse at high block rates / large blocks

Incentives
Is the protocol
“incentive compatible”?

Two main issues found thus far:

1. Miners lack the incentive to flood transaction

messages to others.
On Bitcoin and Red Baloons [Babaioff, Dobzinsky, Oren & Zohar]

2. Miners do not necessarily want to mine on top of

latest block or release their block instantly
“Majority is not Enough“ [Eyal & Sirer]
Block Withholding
[Ittay Eyal & Emin Gün Sirer]

Miners do not necessarily want to mine on

top of latest block.
From: Eyal, Ittay, and Emin Gün Sirer. "Majority is not enough:
Bitcoin mining is vulnerable." arXiv preprint arXiv:1311.0243 (2013).
Mining Pools
 Bitcoin mining is a high risk “lottery”

 Miners can join together to split profits

and reduce risk
Miner

Mining Pool Miner

Server
Fees

Miner
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: Miner

Mining
Split wins proportionately Pool
Server
Miner

to # of shares contributed. 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]
 More on Block Structure:
Merkle Trees
Hash

Hash Hash

Tx1 Tx2 Tx3 Tx4

Specifying the root, is equivalent to committing to

all transactions in the tree (unless we can easily
find hash collisions)
Root of the Merkle tree is thus included in
the block header.
Block Header
(80 Byte) Block Body

P. Block Hash
…
…
Nonce

Merkle Root

Other Fields…

Hash

00001001011011001

Smaller than
target value
Light nodes
 Running a full Bitcoin node root

may be too expensive.

(e.g. for smartphones)
Hash Hash

 To prove that transaction

occurred: Hash Hash
 Download block headers and
check nonce values, Merkle root
 Request Merkle “branch”
Tx3 Tx4
leading from some block to root
 Saving space
 The same scheme allows full nodes to
save space.

Hash

Hash Hash

Tx1 Tx2 Tx3 Tx4

“Spent” transactions no Txn

longer needed Txn
Txn
Unspent transaction outputs
 What about proving that money is
in someone else’s account? Block Header
(Unspent output)
P. Block Hash

 Suggested modification: Include Nonce

a Merkle root of unspent
Txn Merkle Root
transactions in the header.
UTxO Merkle Root

Other Fields…
 Show a Merkle branch to the
output.

 Allows for more space savings

Suggested Reading
 Bitcoin Wiki
 BitcoinTalk forums
 Bitcoin on Stack-Exchange

Some papers (in no particular order):

 Nakamoto, Satoshi. "Bitcoin: A peer-to-peer electronic cash system." (2008).
 Ben-Sasson, Eli, et al. "Zerocash: Decentralized anonymous payments from
Bitcoin." Security and Privacy (SP), 2014 IEEE Symposium on. IEEE. 2014.
 Rosenfeld, Meni. "Analysis of hashrate-based double spending." (2012).
 Rosenfeld, Meni. "Analysis of Bitcoin Pooled Mining Reward Systems." arXiv
preprint arXiv:1112.4980 (2011).
 Babaioff, Moshe, et al. "On bitcoin and red balloons." Proceedings of the EC
2012.
 Eyal, Ittay, and Emin Gün Sirer. "Majority is not enough: Bitcoin mining is
vulnerable." FC 2014.
 Decker, Christian, and Roger Wattenhofer. "Information propagation in the
bitcoin network." IEEE P2P 2013.
 Sompolinsky, Yonatan, and Aviv Zohar. "Accelerating Bitcoin’s Transaction
Processing.“ IACR eprint archive.
 Ron, Dorit, and Adi Shamir. "Quantitative analysis of the full bitcoin
transaction graph." Financial Cryptography and Data Security. Springer
Berlin Heidelberg, 2013. 6-24.