Bitcoin Whitepaper

1. BITCOIN:
A P2P ELECTRONIC
CASH SYSTEM
Satoshi Nakamoto

2. OnlineTransactions
■ Physical cash
– Non-traceable (mostly)
– Secure (mostly)
– Low inflation
■ Can’t be used online directly
 Electronic credit or debit transactions
 Bank sees all transactions
 Merchants can track/profile customers

3. E-Cash
■ Secure
■ Low inflation
■ Privacy-preserving

4. E-Cash Crypto Protocols
 Chaum82: blind signatures for e-cash
 Chaum88: retroactive double spender identification
 Brandis95: restricted blind signatures
 Camenisch05: compact offline e-cash
■ Various practical issues:
– Need for trusted central party
– Computationally expensive
– Etc.

5. Bitcoin
■ Proposed by Satoshi Nakamoto, 2008
■ A distributed, decentralized digital currency system
■ Effectively a bank run by an ad hoc network
– A distributed transaction log

6. Public & Private key:
Encryption & Decryption
■ Key pair generation
Message Encrypted Message Message
Privat
e Key
Public
Key
Encryption Decryption

7. Public & Private key:
Digital signature &Verification
■ Keys work inversely
Message
Message HashValue
Signed Message
Hash
Privat
e Key
Sign
Message HashValue
Public
Key
Message
Message HashValue
Compose
Verify
(Encrypt)
(Decrypt)
Hash

8. Bitcoin
■ Electronic coin = chain of digital signatures
■ Bitcoin transfer:
– message = Previous transaction + payee’s public key
– Ownership verification
– Sign[Hash(message)] with Payer’s private key
Alice gets 5 BTC fromTx 0,
and wants to sent it to Bob Tx 0
Bob’s Public Key
Hash
Alice’s Signature
Alice’s Private
Key
Sign
Tx 1
Alice’s Public Key
Verify

9. Address 0xa8fc93875a972ea
Signature 0xa87g14632d452cd
Public key 0xc7b2f68...

10. Transaction (cont.)
■ Input:
– Multiple inputs allowed
– Refer to an output from previousTx
– Special: generation transaction
■ Output: at most 2
– One for payment
– One for change (return to payer)
In
Out
Out
12.5 BTC
In
In
In
Out
0.5 BTC
0.1 BTC
0.2 BTC
0.8 BTC
In
(Gen)
Out
12 BTC
Tx 1
Tx 0
Tx 2

11. Double-spending
■ Payee cannot verify whether the payer double-spent the coin
■ Common solution: introduce trusted central authority (3rd party)
■ What about BTC?
Mint
Each transaction:
A B
return issue
Only trust money from mint
Check money

12. Avoid double-spending
■ Be aware of all transactions: publicly announce them!
■ Need a system agreed on a single history.
■ Each node (miner) verifies validity ofTxs.
■ Include validTxs into a block, attach it to the current chain.

13. Proof-of-Work
■ Pick a random node in proportion to some resource that no one can
monopolize.
■ Proof ofWork:
– in proportion to computing power.
– Nodes compete for right to create a block
– Make it relatively hard to create new blocks
■ Proof of Stake: in proportion to ownership.

14. Proof-of-Work
■ Cryptographic Hash Functions
– Consistent: hash(X) always yields same result
– One-way: givenY, hard to find X s.t. hash(X) =Y
– Collision resistant: given hash(W) = Z, hard to find X s.t. hash(X) = Z
■ SHA-256 is used for PoW.

15. Proof-of-Work
■ Block:Txs + Prev Hash
■ Find a nonce such that Hash(Txs, prev hash, nonce) < E
– Find a hash value whose leading bits are zero
– The work is exponential in the number of zero bits required
■ Hard to find, easy to verify.

17. PoW Properties
■ Difficult to compute!
– Only miners bother to compete
– Say 1020 hashes per block (in August 2014)
■ Cost is parameterizable
– Recalculate the target space every 2 weeks so amount of work to find a block
increases.
– Prob (Alice wins next block) = fraction of global hash power she controls
■ Key Security Assumption
– Majority of miners weighted by hash power are honest

18. Block chain
■ A distributed timestamp server on a peer-to-peer basis
■ Longest chain
– Has the greatest proof-of-work effort invested in it
– Represent majority decision (One-CPU-one-vote)

19. Tie breaking
■ Two nodes may find a correct block simultaneously.
– Keep both and work on the first one
– If one grows longer than the other, switch to work on the longer one

20. Bitcoin Network
■ Each P2P node runs the following algorithm:
1. New transactions are broadcast to all nodes.
2. Each node (miners) collects new transactions into a block.
3. Each node works on finding a proof-of-work for its block.
4. When a node finds a proof-of-work, it broadcasts the block to all nodes.
5. Nodes accept the block only if all transactions in it are valid (digital signature
checking) and not already spent (check all the transactions).
6. Nodes express their acceptance by working on creating the next block in the chain,
using the hash of the accepted block as the previous hash.

21. Reverting is Hard
■ Reverting gets exponentially hard as the chain grows.
1. Modify the transaction
(revert, change the payer, etc.)
2. Recompute nonce 3. Recompute the next nonce

22. 51% Attack
■ The attacker with >= half of all the computation power can succeed.
■ Gambler’s Ruin problem
0 1 2 3
P(right) = p
P(left) = 1-p = q
P(n) = P(1)n (prob. that move from n to 0)
cliff
P(1) = 1-p+p*P(2)
P(2) = P(1)2 P(1) = (1-p)/p = q/p
p<=0.5, then P(1)>=1
p>0.5, P(1)<1, the larger n, the safer

23. 51% Attack (cont.)
■ BTC: if attacker is behind the longest chain by z blocks
■ Actually, 50% will do… (as long as p<= 0.5, P(1)>=1)
■ If honest is the majority: the larger the z, the safer
0 z
… z+1
honest node (p)
attacker node (q)

24. Vanishing chance
■ Simulation result: P(Attacker succeed) drop off exponentially with z

25. Practical Limitation
■ At least 10 mins to verify a transaction.
– Agree to pay.
– Wait for 1 block (10 mins) for the transaction to go through.
– But for a large transaction ($$$) wait longer.
■ More block attached, more secure
■ For large $$$, wait for 6 blocks (1 hour).

26. Incentives
■ For miners
– N new BTC reward for each new block
■ N starts from 50, halved every 210k blocks (~4 yrs)
■ Total BTC amount will not exceed 21 million
– Transaction fees
■ Encourage nodes to stay honest
– Attacker succeed when >= 50% CPU power
– Find more profit when playing by the rules

27. Privacy
■ Anonymous public key
■ A new key pair for each transaction
– Avoid linking to a common owner

28. A final word…
■ Distributed currencies are good or bad?
■ A future world without governments
Q&A

29. Optimizations
■ MerkleTree (Hash tree)
– Block header only contains the root hash
– Block header is about 80 bytes
– 80 bytes * 6 per/hr * 24 hrs * 365 = 4.2 MB/year

30. Simplified payment verification
■ Get the longest proof-of-work chain.
■ Query the block thatTx3 is in.
■ Only need Hash01 and Hash2 to verify.
VerifyTx3

31. Reclaiming Disk Space
■ Prune spent transactions
– A leaf (Tx) can be pruned when all of its outputs have been spent.