• Lightning Network
  • Core Concept
  • Payment Channels
    • Opening
    • Updating State
    • Closing
  • Hash Time-Locked Contracts (HTLCs)
    • HTLC Parameters
    • CLTV Delta
  • Routing
    • Network Graph
    • Fee Model
    • Pathfinding
    • Onion Routing (Sphinx)
  • Invoices (BOLT #11)
  • BOLT Specifications
  • Multi-Path Payments (MPP)
  • Liquidity
    • Management Techniques
  • Network Statistics (2024)
  • Future
    • PTLCs (Point Time-Locked Contracts)
    • eltoo / LN-Symmetry
    • Channel Factories
    • Taproot & MuSig2
  • Key Takeaways

§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

1. Funding TX: Alice sends BTC to a 2-of-2 multisig address — this is the channel
2. Commitment TX (unbroadcast): Pre-signed refund held by both parties
3. 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

§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

1. Build graph from gossip data
2. Filter edges with insufficient capacity
3. Run modified Dijkstra (weight = fees)
4. 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

§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

§Management Techniques

1. Circular rebalancing: Route payment to yourself through different path
2. Submarine swap: Swap on-chain BTC for off-chain LN capacity
3. Loop out → Loop in: Push BTC out then back in
4. Liquidity ads: Market for channel leases (Lightning Pool)
5. JIT routing: Just-in-Time channel rebalancing

§Network Statistics (2024)

§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