Bitcoin & Blockchain: Consensus Without Authority
How Bitcoin solves Byzantine consensus in an open, anonymous network. The 5-component framework, Nakamoto consensus steps, UTXO model, PoW vs PoS, and comparisons across Bitcoin, Ethereum, Hyperledger Sawtooth, Fabric, and Ripple.
Traditional consensus (Paxos, Raft, PBFT) works among a fixed, known set of participants who already trust the system. Blockchain solves a harder problem: reaching consensus on a shared transaction history among a large, open, pseudonymous set of participants where some may be actively adversarial — without any central authority.
Classical SMR (Paxos / Raft / PBFT)
- • Fixed, known participants
- • Identity always known
- • Incentive to participate = job / contract
- • Deterministic finality
- • O(N²) messages (PBFT) → limited N
- • Trusted admin manages membership
Blockchain Consensus
- • Open: anyone can join/leave
- • Pseudonymous (public key hash)
- • Incentive = block reward / tx fees
- • Probabilistic (PoW) or deterministic (BFT)
- • O(N) gossip → scales to thousands
- • Sybil resistance via proof-of-X
The 5-Component Framework
Xiao et al. (IEEE 2020) identified exactly 5 key components that every blockchain consensus protocol must implement. Understanding these lets you systematically compare any two blockchain systems and explain design trade-offs.
💡 Key Insight: The Unique 5th Component
The incentive mechanism has no counterpart in classical SMR. Paxos, Raft, and PBFT assume servers are operated by a single organization that already has reason to be honest. Blockchain operates in open, zero-trust environments where rational participation must be made financially dominant over defection.
Component 1: Block Proposal
The proposal mechanism determines who gets to build the next block. It must be Sybil-resistant: creating fake identities should not give an attacker proportionally more proposals.
Component 2: Information Propagation
Once a block is proposed, it must reach all nodes efficiently and reliably. Bitcoin uses an advertisement-based gossip protocol (INV → GETDATA → BLOCK) to avoid redundant transmissions of the full block.
INV → GETDATA → BLOCK (avoids redundant transmissions)
Why 10-minute block intervals?
Component 3: Block Validation
Each node independently validates every block it receives before accepting it or re-broadcasting it. Validation is stateless per block but stateful across the chain.
📋 Stateless Block, Stateful Chain
Block validation is stateless per-block but stateful across the chain: checking that a UTXO is unspent requires the node to maintain the full UTXO set — a database of all currently unspent transaction outputs. Bitcoin nodes keep ~5 GB of UTXO data in memory as of 2024.
Component 4: Block Finalization
Finalization determines when a block is considered irreversibly part of the canonical chain. There are two fundamentally different approaches.
Probabilistic Finality (Nakamoto)
- • Longest-chain rule
- • Pr[reverted at depth m] = (α/(1-α))^m
- • Wait 6 confirmations (~1 hour in Bitcoin)
- • Fork resolution: implicit (honest majority eventually wins)
- • Scales to thousands of nodes (O(N) gossip)
- • Examples: Bitcoin, Litecoin, pre-Merge Ethereum
Deterministic Finality (BFT-style)
- • PBFT / Tendermint / HoneyBadgerBFT
- • Once 2f+1 nodes commit → FINAL, cannot be reverted
- • Confirmation: 1–2 rounds (seconds to minutes)
- • No forks — consensus is explicit
- • Limited to ~100 nodes (O(N²) messages)
- • Examples: Hyperledger Fabric, Tendermint, Casper FFG
Longest-chain rule: honest miners always extend the heaviest chain.
Three blocks have been mined in sequence. All nodes agree on this chain.
Advanced: The GHOST Rule (Ethereum pre-Merge)
Component 5: Incentive Mechanism
🔑 Why classical SMR has no incentive mechanism
In Paxos/Raft, servers participate because they are operated by the same organization — a bank's data centers, a company's cloud VMs. There is no question of whether they will behave honestly; they have operational motivation (contracts, employment) to do so. Blockchain's open environment requires explicit economic incentives.
⚠️ Mining Pool Centralization
The Nakamoto Process: 6 Steps
Bitcoin's consensus protocol can be described as exactly six steps, originally specified in Satoshi Nakamoto's 2008 whitepaper.
Step 1: New transactions broadcast to all nodes
Alice creates a transaction: she wants to send 5 BTC to Bob. She signs it with her private key and broadcasts it to the P2P network. Every node that receives it adds it to their local mempool — a pool of unconfirmed transactions waiting to be included in a block.
💡 The Elegance of Implicit Consensus
Unlike PBFT where nodes exchange explicit COMMIT messages, in Nakamoto consensus nodes "vote" by extending the chain. The chain itself IS the consensus record. There is no separate "agreement" phase — mining the next block on top of a block IS the vote for that block.
The UTXO Model: How Bitcoin Tracks Ownership
Unlike Ethereum's account model (which stores balances), Bitcoin uses Unspent Transaction Outputs (UTXOs). Your "balance" is not stored anywhere — it's the sum of all UTXOs your private key controls.
Each coin is an Unspent Transaction Output. Spending destroys the UTXO and creates new ones.
No account balances in Bitcoin
To find "Alice's balance," you must scan the entire UTXO set for outputs locked to Alice's public key hash. This is why Bitcoin full nodes maintain the UTXO set in memory: ~5 GB as of 2024, containing ~100 million entries. Each UTXO carries a locking script (scriptPubKey); spending requires a matching unlocking script (scriptSig) — typically a signature.
System Comparison: All 5 Components
Comparing Bitcoin, Ethereum, Hyperledger Sawtooth, Hyperledger Fabric, and Ripple across the 5-component framework.
| Component | Bitcoin | Ethereum | H. Sawtooth | H. Fabric | Ripple |
|---|---|---|---|---|---|
| Block Proposal | PoW (SHA256²) | PoS (Casper) | PoET (SGX timer) | Round-robin orderer | RPCA (UNL voting) |
| Info Propagation | Gossip (INV→GETDATA→BLOCK) | Gossip | Gossip | Gossip (per channel) | Gossip |
| Block Validation | PoW + UTXO set + Merkle | PoS + account state + Merkle | PoET cert + txn validity | Endorsement policy (N-of-M) | UNL 80% agree |
| Block Finalization | Probabilistic (6 conf ≈ 1h) | Deterministic (Casper FFG) | Probabilistic | Deterministic (PBFT) | Prob. (80% UNL) |
| Incentive | Block reward + tx fees | Block reward + tx fees | None (enterprise) | None (enterprise) | None (XRP pre-mined) |
| Fault Tolerance | 50% hash power | 33% staked ETH | 50% (SGX-attested) | 33% (PBFT) | 20% (UNL overlap) |
| Finality Type | Probabilistic | Deterministic | Probabilistic | Deterministic | Probabilistic |
| Network Type | Permissionless | Permissionless | Permissioned | Permissioned | Semi-permissioned |
| TPS | ~7 | ~15–100 | ~1,000 | ~1,000–3,000 | ~1,500 |
⚡ Ripple's Unique Node List (UNL)
The Permissioned vs. Permissionless Axis
The choice between permissioned and permissionless blockchain is the most fundamental design decision. It determines which of the 5 components are even applicable.
Click any system to see its details. No system is purely "decentralized" or "centralized" — it's a spectrum.
- • Open join/leave — no approval needed
- • Pseudonymous (public key = identity)
- • PoW/PoS Sybil resistance
- • Probabilistic finality
- • Block rewards essential for participation
- • 7–30 TPS typical
- • Known, authenticated participants
- • Real identity required (PKI / MSP)
- • BFT consensus (PBFT, Raft)
- • Deterministic finality
- • No incentive mechanism needed
- • 1,000–3,000+ TPS
| Dimension | Permissionless | Permissioned |
|---|---|---|
| Identity | Pseudonymous | Known, authenticated |
| Join/leave | Free (no approval) | Requires authorization |
| Consensus | PoW/PoS (Nakamoto or hybrid) | BFT (PBFT, Raft) |
| Throughput | 7–1,500 TPS | 1,000–3,000+ TPS |
| Finality | Probabilistic | Deterministic |
| Incentive | Essential (block rewards) | Not needed |
| Sybil protection | Proof-of-X (resource cost) | Identity management |
| Example | Bitcoin, Ethereum | Hyperledger Fabric, Ripple |
Interactive Proof-of-Work Demo
This demonstrates Component 1 (Block Proposal) for the Bitcoin/Nakamoto protocol. Find a nonce N such that SHA256(SHA256(block_header + N)) starts with the required leading zeros. Bitcoin adjusts difficulty every 2,016 blocks (~2 weeks) to target a 10-minute average block time.
Uses browser WebCrypto (double SHA-256). Leading zeros highlighted in green.
# Real Bitcoin context (June 2024)
Current difficulty: ~83 trillion (requires ~76 leading zero bits)
Global network: ~600 EH/s (6 × 10²⁰ hashes/second)
Average time to find valid nonce: ~10 minutes
Your browser demo uses 1–4 zero bits → finds it in milliseconds
Bitcoin Block Explorer: Field Annotations
Each field in a Bitcoin block header maps to one of the 5 consensus components:
Each block references its predecessor via prev_hash. Changing any block invalidates all subsequent blocks.
Merkle Tree: Transaction Commitment
The Merkle root in the block header commits to all transactions. O(log n) proof that any single transaction is included — without downloading the full block.
Edit any transaction to see how the change propagates up the tree (shown in red). Click any node to see its full hash.
Blockchain Exam Questions
Click any question to reveal the model answer.