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

Lightning Network — Complete Technical Guide