The Lightning Network
Module 5 of Bitcoin Deep Dive
What Is the Lightning Network?
The Lightning Network is Bitcoin's Layer 2 scaling solution:
- Off-chain payment channels
- Near-instant transactions
- Extremely low fees
- Inherits Bitcoin's security
"If Bitcoin is digital gold, Lightning is digital cash."
The Scaling Problem
Bitcoin's Limitations
Block size: ~1-4 MB (with SegWit)
Block time: ~10 minutes
Transactions per block: ~2,000-3,000
TPS: ~7 transactions per second
For comparison:
- Visa: ~65,000 TPS capacity
- Cash: Unlimited parallel transactions
Why Not Just Bigger Blocks?
- Decentralization: Larger blocks = fewer can run nodes
- Propagation: Big blocks take longer to broadcast
- Verification: More transactions = more computation
- Storage: Blockchain already ~500 GB
Solution: Move transactions off-chain, settle on-chain.
How Lightning Works
The Core Idea
Instead of broadcasting every transaction to the blockchain:
- Open a channel (one on-chain transaction)
- Transact off-chain (unlimited, instant, free)
- Close the channel (one on-chain transaction)
Thousands of transactions → 2 on-chain transactions.
Payment Channels
Two parties lock funds in a 2-of-2 multisig:
Opening Transaction (on-chain):
┌─────────────────────────────┐
│ 2-of-2 Multisig │
│ Alice: 0.5 BTC │
│ Bob: 0.5 BTC │
│ Total: 1 BTC locked │
└─────────────────────────────┘
Now they can update balances off-chain:
State 1: Alice 0.5, Bob 0.5
State 2: Alice 0.4, Bob 0.6 (Alice paid Bob 0.1)
State 3: Alice 0.35, Bob 0.65 (Alice paid Bob 0.05)
...
Each state is a signed transaction that COULD be broadcast, but isn't.
Closing the Channel
When done, broadcast the final state:
Closing Transaction (on-chain):
Alice receives: 0.35 BTC
Bob receives: 0.65 BTC
All intermediate transactions never hit the blockchain!
Channel Security
The Cheating Problem
What if Alice broadcasts an old state (where she had more)?
The Solution: Revocation
Each state update includes a revocation key:
If Alice broadcasts old state:
Bob has revocation key for that state
Bob can take ALL funds as penalty
This makes cheating economically irrational.
Commitment Transactions
Each party holds their own version:
Alice's version: Alice can spend after 144 blocks, Bob immediately
Bob's version: Bob can spend after 144 blocks, Alice immediately
This delay allows the other party to catch cheaters.
Multi-Hop Payments
The Network Effect
You don't need a direct channel with everyone:
Alice ←→ Bob ←→ Carol ←→ Dave
Alice can pay Dave through Bob and Carol!
Hash Time-Locked Contracts (HTLCs)
Enable trustless multi-hop payments:
1. Dave generates secret R, gives hash H(R) to Alice
2. Alice → Bob: "I'll pay you if you show me R" (locked with H)
3. Bob → Carol: Same deal
4. Carol → Dave: Same deal
5. Dave reveals R to Carol (gets paid)
6. Carol reveals R to Bob (gets paid)
7. Bob reveals R to Alice (gets paid)
Key properties:
- Atomic: Either all hops succeed or none do
- Trustless: No one can steal funds
- Fast: Happens in seconds
Routing
Finding paths through the network:
| Algorithm | How It Works |
|---|---|
| Source routing | Sender computes full path |
| Onion routing | Each hop only knows next step |
| MPP | Split payment across multiple paths |
Lightning in Practice
Node Operations
Running a Lightning node:
- Run Bitcoin full node
- Run Lightning implementation (LND, c-lightning, Eclair)
- Open channels with other nodes
- Maintain liquidity
Channel Capacity
Your channel capacity: Amount locked in channel
Outbound liquidity: How much you can send
Inbound liquidity: How much you can receive
Example:
Total: 1 BTC
Your side: 0.3 BTC (can send 0.3)
Their side: 0.7 BTC (can receive 0.7)
Liquidity Challenges
Problem: Need inbound liquidity to receive payments.
Solutions:
- Buy inbound liquidity
- Loop out (submarine swaps)
- Balanced channel opens
- Liquidity marketplaces
Network Statistics
Current State (2024)
| Metric | Value |
|---|---|
| Nodes | ~15,000 |
| Channels | ~60,000 |
| Total Capacity | ~5,000 BTC |
| Avg. Channel Size | ~$5,000 |
Growth Trajectory
2018: 100 BTC capacity
2020: 1,000 BTC capacity
2022: 4,000 BTC capacity
2024: 5,000+ BTC capacity
Use Cases
1. Micropayments
Pay-per-use services previously impossible:
Traditional minimum: ~$0.30 (credit card fees)
Lightning minimum: <$0.01 (or less)
Examples:
- Pay per article read
- Pay per API call
- Streaming sats for content
2. Instant Payments
No waiting for confirmations:
On-chain: 10-60 minutes
Lightning: <1 second
3. Gaming
In-game economies with real value:
- Earn sats playing games
- Instant deposits/withdrawals
- Microtransactions without friction
4. Remittances
Send money internationally:
- No bank required
- Near-zero fees
- Instant settlement
- 24/7 availability
Wallet Types
Custodial Wallets
Someone else manages your Lightning node.
| Wallet | Type | Pros | Cons |
|---|---|---|---|
| Wallet of Satoshi | Custodial | Easy | Trust required |
| Strike | Custodial | Great UX | Requires KYC |
Non-Custodial Wallets
You control your keys.
| Wallet | Type | Pros | Cons |
|---|---|---|---|
| Phoenix | Non-custodial | Easy + sovereign | Channel fees |
| Breez | Non-custodial | Good UX | Setup complexity |
| Zeus | Self-hosted | Full control | Technical |
Challenges and Tradeoffs
Current Limitations
- Channel management: Requires active management
- Liquidity: Need balanced channels
- Online requirement: Must be online to receive
- Complexity: Harder than on-chain
- Routing failures: Payments can fail
Security Considerations
- Hot wallet: Keys must be online
- Watchtowers: Need monitoring for cheating
- Force closes: Can be expensive in high-fee environments
- Backup complexity: Static channel backups
Technical Deep Dive
BOLT Specifications
Lightning is defined by BOLTs (Basis of Lightning Technology):
| BOLT | Topic |
|---|---|
| 1 | Base protocol |
| 2 | Peer protocol |
| 3 | Transactions |
| 4 | Onion routing |
| 7 | P2P node discovery |
| 11 | Invoice format |
Implementations
| Implementation | Language | Maintainer |
|---|---|---|
| LND | Go | Lightning Labs |
| c-lightning/CLN | C | Blockstream |
| Eclair | Scala | ACINQ |
| LDK | Rust | Spiral |
Future Developments
Taproot Channels
Using Taproot for improved:
- Privacy (channels look like normal transactions)
- Efficiency (smaller on-chain footprint)
Point Time-Locked Contracts (PTLCs)
Replace HTLCs with:
- Better privacy
- No hash reuse
- Stuckless payments
Splicing
Resize channels without closing:
- Add or remove funds
- Seamless capacity management
Trampoline Routing
Let someone else route for you:
- Better for mobile
- Reduces client complexity
Key Takeaways
- Lightning scales Bitcoin with off-chain channels
- Security inherits from Bitcoin — can always settle on-chain
- HTLCs enable trustless routing through multiple hops
- Instant and cheap — milliseconds, sub-penny fees
- Liquidity management is key — the main challenge
- Rapidly improving — better UX every year
Questions to Consider
- Will Lightning make on-chain Bitcoin obsolete for payments?
- How does Lightning affect Bitcoin's fee market?
- Can Lightning ever be as easy as Venmo?
- What happens if most Lightning nodes become large institutions?