Chapter 24

Lightning Network

A Network of Payment Channels

The Lightning Network transforms individual payment channels into a global payment network. By routing payments through chains of channels, any participant can pay any other without establishing a direct channel—enabling Bitcoin to scale to millions of transactions per second while preserving its fundamental security properties.

This chapter covers the network layer built atop the payment channels of Chapter 23: routing algorithms, invoices, the BOLT specifications, and the emergent network topology that enables instant, low-cost Bitcoin payments.

24.1 Multi-Hop Payments

The key insight of Lightning: if Alice has a channel with Bob, and Bob has a channel with Carol, Alice can pay Carol through Bob—atomically and trustlessly.

The Routing Problem

Definition 24.1 (Multi-Hop Payment)

A multi-hop payment from sender S to receiver R through intermediaries I₁, I₂, ..., Iₙ:

  1. R generates secret preimage r and payment_hash H(r)
  2. R sends payment_hash to S (via invoice)
  3. S routes payment through I₁ → I₂ → ... → Iₙ → R
  4. R reveals r to Iₙ to claim payment
  5. r propagates back: Iₙ → ... → I₁ → S
  6. Each hop atomically settles their HTLC
Multi-Hop Payment via HTLCs Alice Sender Bob Routing Carol Routing Dave Receiver HTLC 1.003 BTC timeout: T+30 HTLC 1.002 BTC timeout: T+20 HTLC 1.001 BTC timeout: T+10 preimage r preimage r preimage r Each HTLC uses same payment_hash; preimage unlocks entire chain atomically Routing Fees Bob: 0.001 BTC Carol: 0.001 BTC
Figure 24.1 — Multi-hop payment: HTLCs chain forward with decreasing amounts (fees) and decreasing timeouts. The preimage propagates backward to settle all HTLCs atomically.

Atomicity Guarantee

Theorem 24.1 (Atomic Multi-Hop Payment)

In a multi-hop HTLC payment:

  • Complete success: All HTLCs settle, receiver gets paid, all routing nodes receive fees
  • Complete failure: All HTLCs timeout, sender loses nothing
  • No partial state: Either all or nothing, never some HTLCs settled and others failed

Proof.

The payment_hash H(r) is identical across all HTLCs. If receiver reveals r to claim the final HTLC, every intermediate node learns r (from their downstream) and can claim their incoming HTLC. Since timeouts decrease toward the receiver, each node has sufficient time to claim after learning r.

Conversely, if receiver never reveals r, all HTLCs eventually timeout and funds return to senders. An intermediate node cannot steal funds because they cannot claim their outgoing HTLC without r, and cannot keep their incoming HTLC without the timeout expiring. ∎

Timeout Decrements

Definition 24.2 (CLTV Delta)

Each hop requires a CLTV delta—the number of blocks between incoming and outgoing HTLC timeouts. This ensures:

  • Sufficient time to detect preimage revelation downstream
  • Sufficient time to claim incoming HTLC after learning preimage
  • Protection against blockchain congestion delays

Typical values: 40-144 blocks per hop.

24.2 Onion Routing

Lightning uses Sphinx-style onion routing to preserve payment privacy. Intermediate nodes learn only their immediate predecessor and successor.

Definition 24.3 (Onion Packet)

The sender constructs a 1366-byte onion packet containing:

  • Per-hop payload: Instructions for each routing node
  • Layered encryption: Each hop can only decrypt their layer
  • Shared secrets: Derived via ECDH with each hop's public key
  • MAC chain: Integrity verification at each hop
Onion Routing: Layered Encryption Dave Carol Bob Alice creates Bob peels Dave Carol Bob sees Carol peels Dave Carol sees Dave final hop Dave sees Privacy Properties Bob knows: Alice → ? (doesn't know final destination) Carol knows: ? → ? (doesn't know source or destination)
Figure 24.2 — Each node peels one encryption layer, forwards to next hop. No node knows the complete path except the sender.

Per-Hop Payload

Definition 24.4 (Per-Hop Data)

Each routing node's decrypted payload contains:

Field Purpose
short_channel_id Which channel to forward to
amt_to_forward Amount for next hop (less fee)
outgoing_cltv Timeout for outgoing HTLC
padding Fixed size for unlinkability

24.3 Invoices and Payment Requests

Lightning payments are typically initiated by the receiver generating an invoice (BOLT #11) containing payment details.

Definition 24.5 (BOLT #11 Invoice)

A Lightning invoice encodes:

  • payment_hash: H(preimage) to verify payment
  • amount: Requested payment (optional)
  • destination: Receiver's node public key
  • expiry: Invoice validity period
  • route hints: Private channels for routing
  • description: Human-readable payment purpose
  • signature: Receiver's signature over invoice

Example 24.1 (Lightning Invoice)

lnbc1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpl2pkx2ctnv5sxxmmwwd5kgetjypeh2ursdae8g6twvus8g6rfwvs8qun0dfjkxaq9qrsgq357wnc5r2ueh7ck6q93dj32dlqnls087fxdwk8qakdyafkq3yap9us6v52vjjsrvywa6rt52cm9r9zqt8r2t7mlcwspyetp5h2tztugp9lfyql

Decodes to:

  • Network: mainnet (lnbc)
  • Amount: unspecified
  • Payment hash: 0001020304050607...
  • Description: "Please consider supporting this project"
  • Expiry: 3600 seconds

BOLT #12 Offers

BOLT #12 introduces offers—reusable payment requests with better privacy:

Definition 24.6 (BOLT #12 Offer)

Unlike invoices, offers:

  • Are reusable (no pre-generated payment_hash)
  • Support subscription/recurring payments
  • Use blinded paths for receiver privacy
  • Enable two-way communication via onion messages

24.4 Pathfinding and Routing

Finding efficient payment paths through the Lightning Network is a complex graph problem combining cost optimization with reliability.

Network Graph

Definition 24.7 (Channel Graph)

The Lightning Network graph G = (V, E) where:

  • Vertices V: Lightning nodes (public keys)
  • Edges E: Payment channels
  • Edge weights: Fees, capacity, reliability metrics

Nodes gossip channel announcements and updates via BOLT #7.

Fee Structure

Definition 24.8 (Routing Fees)

Each channel advertises:

  • base_fee: Fixed fee per forwarded HTLC (satoshis)
  • fee_rate: Proportional fee (millionths of amount)

Total fee = base_fee + (amount × fee_rate / 1,000,000)

Example 24.2 (Fee Calculation)

Channel with base_fee = 1000 msat, fee_rate = 100:

  • Forward 100,000 sat: fee = 1000 + (100,000,000 × 100 / 1,000,000) = 1000 + 10,000 = 11,000 msat = 11 sat
  • Forward 1,000 sat: fee = 1000 + (1,000,000 × 100 / 1,000,000) = 1000 + 100 = 1,100 msat ≈ 1 sat

Pathfinding Algorithms

Algorithm 24.1 (Basic Pathfinding)

function FindRoute(source, destination, amount):
    // Build graph from gossip data
    graph = BuildChannelGraph()

    // Filter edges with insufficient capacity
    graph = FilterByCapacity(graph, amount)

    // Find shortest path by fee
    path = Dijkstra(graph, source, destination,
                    weight = base_fee + amount * fee_rate)

    // Verify path validity
    if VerifyPath(path, amount):
        return path
    else:
        return FindRoute(source, destination, amount,
                        exclude = path.failed_edges)

Multipath Payments (MPP)

Definition 24.9 (Multi-Path Payment)

Large payments can be split across multiple routes:

  • Same payment_hash, different payment_secret per shard
  • Receiver waits for all shards before revealing preimage
  • Enables payments larger than any single channel capacity
  • Improves privacy by obscuring payment amounts
Multi-Path Payment Alice B C D E Dave 0.3 BTC 0.7 BTC
Figure 24.3 — Multi-path payment: 1 BTC split across two routes with different intermediate nodes.

24.5 BOLT Specifications

The Lightning Network is defined by the BOLT (Basis of Lightning Technology) specifications:

BOLT Title Description
#1 Base Protocol Message framing, encryption, authentication
#2 Peer Protocol Channel establishment, operation, closing
#3 Transactions On-chain transaction formats
#4 Onion Routing Payment packet construction
#5 On-Chain Handling Unilateral close, HTLC resolution
#7 P2P Node Discovery Gossip protocol for graph
#8 Transport Encrypted communication (Noise_XK)
#9 Feature Bits Capability negotiation
#10 DNS Bootstrap Initial peer discovery
#11 Invoice Protocol Payment request encoding
#12 Offers Reusable payment requests (draft)

24.6 Network Topology

Network Statistics

Example 24.3 (Network Size, 2024)

Public nodes ~15,000-20,000
Public channels ~60,000-80,000
Total capacity ~5,000+ BTC
Private channels Unknown (significant)

Hub and Spoke vs Mesh

The network exhibits characteristics of both topologies:

Liquidity Management

Definition 24.10 (Channel Balance Problem)

As payments flow through channels, balances shift:

  • Outbound liquidity: Amount you can send
  • Inbound liquidity: Amount you can receive

A channel with 1 BTC capacity split 0.9/0.1 can only receive 0.1 BTC until rebalanced.

Liquidity management techniques:

24.7 Future Developments

eltoo / LN-Symmetry

A proposed channel construction using SIGHASH_ANYPREVOUT:

Channel Factories

Multi-party constructions enabling:

PTLCs (Point Time-Locked Contracts)

Replace hash-based HTLCs with Schnorr-based PTLCs:

Exercises

Exercise 24.1

Calculate the minimum total fees to route 0.1 BTC through a 5-hop path where each node charges base_fee = 1 sat and fee_rate = 1000 (0.1%).

Exercise 24.2

Prove that the CLTV timeouts must decrease toward the receiver. What attack becomes possible if they don't?

Exercise 24.3

A routing node sees an onion packet. What information can they extract? What remains hidden?

Exercise 24.4

Design an attack where a malicious intermediate node delays HTLC settlement to profit. How do CLTV deltas mitigate this?

Exercise 24.5

A node has 10 channels with 1 BTC each. After receiving many payments, 8 channels have 0.9 BTC local, 0.1 BTC remote. Calculate the cost to rebalance using circular payments with 0.1% fees.

Exercise 24.6

Explain why multi-path payments must use the same payment_hash but different payment_secrets. What attack would be possible otherwise?

Chapter Summary