Notes: https://pdos.csail.mit.edu/6.824/notes/l-bitcoin.txt
Video: https://youtu.be/yB6m8EjAqPU
Prep:
- Bitcoin
- Challenges
- Tx Inside Ledger
- Double Spending
- Decentralization
- Block Chain
- Forks & Conflict Resolution
- Practical Issues
Bitcoin
consensus with BFT
similar to SUNDR → signed log, handling forks
Challenges
- forgery
- signing
- double spending
- ledger / public log
- theft
Tx Inside Ledger
PK of receiver
hash of prev tx
signed by SK of sender
Double Spending
sender creates 2 tx records to diff receivers with same prev tx
⇒ spent/sent same money twice
Solution is ledger, which will maintain global order of txs
⇒ prev tx will mismatch during double spend tx
Alternate Solution
maintain a centralized server w/ log
probs
- can’t trust centralized
- log conflict resolution
- quorum?
Decentralization
every client maintains log
consensus protocol like raft doesn’t work out as it’s decentralized and there’s no quorum number
Bitcoin solves this consensus problem with PoW Proof of Work
- winner in PoW decides on next log entry
- hard to impersonate
- waste of energy
- ethereum uses PoS proof of stake approach, no wastage
Block Chain
blocks (~1mb), which contain tx records, get appended to prev blocks and form a chain
every node creates it’s own block, that’s ready to be appended to prev block, and a temp block after it’s own block
the purpose of temp block is to accept new blocks created by other nodes
if node doesn’t succeed in computing by the time of new block’s arrival, temp which should store new block will become prev block
if it succeeds, curr block will become prev, and spread across network similar to gossip and cycle goes on
when txs are made
Forks & Conflict Resolution
happens when 2 blocks/forks want to get appended to same prev block
solved by choosing longest chain, and whatever blocks in the smaller chain will get attached to longest
this also solves the double spending problem
Practical Issues
10mins → 10x the time to flood n/w