Lightning Network
A layer-2 payment protocol on top of Bitcoin. Near-instant, low-cost micropayments.
Core Concept#
Instead of every payment going on-chain (slow, expensive), counterparties open a payment channel (on-chain), then transact off-chain unlimited times, only settling on-chain when closing.
BITCOIN LAYER 1 │ LIGHTNING LAYER 2
│
┌──────────────┐ │ ┌──────┐
│ Funding TX │─────────│──▶│Channel│ ← 2-of-2 multisig UTXO
│ 0.1 BTC │ │ │ 0.1 │
└──────────────┘ │ └──┬─┬─┘
│ │ │
│ ┌──┘ └──┐
│ ▼ ▼
│ Alice Bob
│ 0.05 0.05
│
(on-chain, visible) │ (off-chain, private, instant)
Payment Channels#
Opening#
- Funding TX: Alice sends BTC to a 2-of-2 multisig address — this is the channel
- Commitment TX (unbroadcast): Pre-signed refund held by both parties
- Channel now open — Alice and Bob can transact instantly
Updating State#
Each payment creates and exchanges a new commitment transaction:
- Reflects the current balance split
- Revokes the previous state
- Can be broadcast unilaterally by either party
Closing#
- Cooperative close: Both sign a final transaction. Fast, cheap.
- Unilateral close (force close): Broadcast latest commitment TX. Wait for timelock (~144 blocks). Higher fees.
- Breach remedy: If Bob broadcasts an old state, Alice can claim ALL funds (punishment mechanism).
Hash Time-Locked Contracts (HTLCs)#
The core contract that enables multi-hop routing.
Alice ──HTLC──▶ Bob ──HTLC──▶ Carol ──HTLC──▶ Dave
(2 BTC) (1.5 BTC) (1 BTC) (0.5 BTC)
Each hop uses the SAME payment_hash H(R)
Carol generates preimage R, reveals to claim her HTLC
R propagates backward: Dave → Carol → Bob → Alice
All HTLCs settle atomically.
HTLC Parameters#
| Parameter | Description |
|---|---|
payment_hash = H(R) |
Hash of the secret preimage R |
amount |
Value to transfer |
cltv_expiry |
Block height timeout |
payment_preimage = R |
Revealed by receiver to claim |
CLTV Delta#
Each hop reduces the timeout. Typical delta: 40 blocks (~7 hours).
Sender: cltv_expiry = 700,140
Hop 1: cltv_expiry = 700,100 (delta = 40)
Hop 2: cltv_expiry = 700,060 (delta = 40)
Receiver: cltv_expiry = 700,020 (delta = 40)
This ensures each hop has time to claim after the next hop reveals R.
Routing#
Network Graph#
G = (V, E)
V: Lightning nodes (pubkeys)
E: Payment channels (with capacity, fees, reliability)
Fee Model#
Total fee = base_fee + (amount × fee_rate / 1,000,000)
Example: base=1000 msat, rate=100
1,000 sat: fee = 1000 + (1,000,000 × 100 / 1M) = 1,100 msat ≈ 1 sat
100,000 sat: fee = 1000 + (100,000,000 × 100 / 1M) = 11,000 msat = 11 sat
Pathfinding#
- Build graph from gossip data
- Filter edges with insufficient capacity
- Run modified Dijkstra (weight = fees)
- Try paths sequentially (trial-and-error for liquidity)
Onion Routing (Sphinx)#
- Sender computes the full route
- Each hop only knows: predecessor + successor
- Nested encryption: each hop can only peel one layer
- No hop knows the full path
Sender knows: full path
Hop 1 knows: [sender, self, hop 2]
Hop 2 knows: [hop 1, self, hop 3]
Hop 3 knows: [hop 2, self, receiver]
Receiver knows: [hop 3, self]
Invoices (BOLT #11)#
lnbc10u1p3unwf... // bech32-encoded invoice
Decoded:
amount: 100 sats
description: "coffee"
payment_hash: a1b2c3...
payee: 02a1b2c3...
expiry: 3600 seconds
route_hints: [private channel paths]
Key fields:
- payment_hash: H(payment_preimage), used in HTLCs
- amount: Optional (can be zero for "any amount")
- expiry: Seconds until invoice expires
- route_hints: Private channel paths to reach receiver
BOLT Specifications#
| BOLT | Title | Description |
|---|---|---|
| #1 | Base Protocol | Message framing, encryption |
| #2 | Peer Protocol | Channel lifecycle |
| #3 | Transactions | On-chain format |
| #4 | Onion Routing | Payment packet construction |
| #5 | On-Chain Handling | Force close, HTLC resolution |
| #7 | P2P Node Discovery | Gossip protocol |
| #8 | Transport | Noise_XK encrypted comms |
| #9 | Feature Bits | Capability negotiation |
| #11 | Invoice Protocol | BOLT 11 invoice format |
| #12 | Offers | Reusable payment endpoints |
Multi-Path Payments (MPP)#
Large payments split across multiple routes:
1 BTC payment:
Route A: 0.3 BTC (Alice → B → C → D → Dave)
Route B: 0.7 BTC (Alice → E → F → Dave)
Same payment_hash, different paths.
Dave waits for all shards before revealing preimage.
Enables payments larger than any single channel.
Liquidity#
| Concept | Definition |
|---|---|
| Local balance | Amount YOU can send |
| Remote balance | Amount YOU can receive |
| Inbound liquidity | Someone else's BTC on your side |
| Outbound liquidity | Your BTC on your side |
Management Techniques#
- Circular rebalancing: Route payment to yourself through different path
- Submarine swap: Swap on-chain BTC for off-chain LN capacity
- Loop out → Loop in: Push BTC out then back in
- Liquidity ads: Market for channel leases (Lightning Pool)
- JIT routing: Just-in-Time channel rebalancing
Network Statistics (2024)#
| Metric | Value |
|---|---|
| Public nodes | ~15,000–20,000 |
| Public channels | ~60,000–80,000 |
| Total capacity | ~5,000+ BTC |
| Avg fee | < 1 sat |
Future#
PTLCs (Point Time-Locked Contracts)#
- Replace hash-locks with Schnorr-based point-locks
- Better privacy (no shared payment_hash between hops)
- Stuckless payments
eltoo / LN-Symmetry#
- Requires SIGHASH_ANYPREVOUT (BIP-118 soft fork)
- Simpler channel construction
- No punishment mechanism needed
- All states equally valid
Channel Factories#
- Multi-party channel opening with single on-chain transaction
- Sub-channels inside factory without on-chain footprint
Taproot & MuSig2#
- Better privacy for channel opens (look like regular transactions)
- Schnorr multi-signatures for efficient cooperative closes
- PTLCs natively supported
Key Takeaways#
- Lightning turns payment channels into a global payment network
- HTLCs provide atomic, trustless multi-hop payments
- Onion routing preserves privacy along the path
- MPP breaks the single-channel-capacity bottleneck
- All value ultimately settles on Bitcoin
Comments
No comments yet. Start the conversation.