# How Bitcoin Achieves Decentralization
## Aspects of decentralization in Bitcoin
1. Who maintains the ledger?
2. Who has authority over which transactions are valid?
3. Who create new bitcoins?
4. Who determines how the rules of the system change?
5. How do bitcoins acquire exchange value?
- Peer-to-peer network:
- open to anyone, low barrier to entry
- Mining:
- open to anyone, but inevitable concentration of power ofter seen as undesirable
- Updates to software:
- core developers trusted by community, have great power
## Bitcoin's key challenge
- Key technical challenge of decentralized e-cash: distributed consensus (how to decentralize ScroogeCoin)
## Why consensus protocols
- Traditional motivation: reliability in distributed systems
- Distributed key-value store enables various applications:
- DNS, public key directory, stock trades
## Why consensus is hard
- Nodes may crash
- Nodes may be calicious
- Network is imperfect
- Not all pairs of nodes are connected
- Faults in network
- Latency
- **No notion of global time!!**
## Some things Bitcoin does differently
- Introduces incentives
- Possible only because it's a currency
- Embraces randomness
- Does away with the notion of a specific end-point
- Consensus happens over long time scales - about 1 hour
## Consensus without identities
Pragmatic: some protocols need node IDs
Security: assume less than 50% malicious
### Why don't Bitcoin nodes have identities
- Identity is hard in a P2P system - *Sybil attack*
- Pseudonymity is a goal of Bitcoin
### Weaker assumption: select random node
- Analogy: lattery or raffle
- While tracking & verifying identities is hard, we give people tokens, tickets, etc.
- Now we can pick a random ID & select that node
### Key idea: implicit consensus
In each round, random node is picked
This node proposes the next block in the chain
Other nodes implicitly accept/reject this block
- by either extending it
- or ignoring it and extending chain from earlier block
**Every block contains hash of the block it extends**
## Consensus algorithm (simplified)
1. New transactions are broadcasted to all nodes
2. Each node collects new transactions into a block
3. In each round a random node gets to broadcast its block
4. Other nodes accept the block only if all transactions in it are valid (unspent, valid signatures)
5. Nodes express their acceptance of the block by including its hash in the next block they create
### Double spending attack attempt
- Honest nodes will extend the ***longest valid branch***

### From Bob's POV
- The probability of a succesful double spend decreases exponentially with number of confirmations
- The most common heuristic: 6 confirmations

## Incentive and proof of work
### Assumption of honesty is problematic
- Can we give nodes incentives for behaving honestly?
### Incentive 1: block reward
- include special **coin-creation transaction** in the block
- you can choose recipient address of this transaction (often yourself)
- Value is fixed: currently 25 BTC, halves every 4 years
- Block creator gets to "collect" the reward **only if the block ends up on the long-term consensus branch!**
- There's finite supply as this is **the only coin-creating mechanism!**

### Incentive 2: transaction fees
- Creator of transaction can choose to make output value less than input value
- Remainder is a transaction fee and goes to block creator
- Purely voluntary, like a tip
### Proof of work
- To approximate selecting a random node:
- select nodes in proportion to a resource that no one can monopolize
- In proportion to computing power: proof-of-work
- In proportion to ownership: proof-of-stake

#### PoW property 1: difficult to compute
- As of Aug 2014: about $10^{20}$ hashes/block
- Only some nodes (miners) bother to compete
#### PoW property 2: parameterizable cost
- Nodes automatically re-calculate the target every two weeks
- Goal: average time between block = 10 minutes
#### PoW property 3: trivial to verify
- Nonce must be published as part of block
- Other miners simply verify that $H(nonce\ ||\ prev\_hash\ ||\ tx\ ||\ ...||\ tx)<target$
### Key security assumption
- Attakcs are infeasible if majority of miners **weighted by hash power** follow the protocol

## For Bitcoin to work
