Bitcoin Deep Dive

Lightning Network

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?

  1. Decentralization: Larger blocks = fewer can run nodes
  2. Propagation: Big blocks take longer to broadcast
  3. Verification: More transactions = more computation
  4. 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:

  1. Open a channel (one on-chain transaction)
  2. Transact off-chain (unlimited, instant, free)
  3. 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:

AlgorithmHow It Works
Source routingSender computes full path
Onion routingEach hop only knows next step
MPPSplit payment across multiple paths

Lightning in Practice

Node Operations

Running a Lightning node:

  1. Run Bitcoin full node
  2. Run Lightning implementation (LND, c-lightning, Eclair)
  3. Open channels with other nodes
  4. 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)

MetricValue
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.

WalletTypeProsCons
Wallet of SatoshiCustodialEasyTrust required
StrikeCustodialGreat UXRequires KYC

Non-Custodial Wallets

You control your keys.

WalletTypeProsCons
PhoenixNon-custodialEasy + sovereignChannel fees
BreezNon-custodialGood UXSetup complexity
ZeusSelf-hostedFull controlTechnical

Challenges and Tradeoffs

Current Limitations

  1. Channel management: Requires active management
  2. Liquidity: Need balanced channels
  3. Online requirement: Must be online to receive
  4. Complexity: Harder than on-chain
  5. Routing failures: Payments can fail

Security Considerations

  1. Hot wallet: Keys must be online
  2. Watchtowers: Need monitoring for cheating
  3. Force closes: Can be expensive in high-fee environments
  4. Backup complexity: Static channel backups

Technical Deep Dive

BOLT Specifications

Lightning is defined by BOLTs (Basis of Lightning Technology):

BOLTTopic
1Base protocol
2Peer protocol
3Transactions
4Onion routing
7P2P node discovery
11Invoice format

Implementations

ImplementationLanguageMaintainer
LNDGoLightning Labs
c-lightning/CLNCBlockstream
EclairScalaACINQ
LDKRustSpiral

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

  1. Lightning scales Bitcoin with off-chain channels
  2. Security inherits from Bitcoin — can always settle on-chain
  3. HTLCs enable trustless routing through multiple hops
  4. Instant and cheap — milliseconds, sub-penny fees
  5. Liquidity management is key — the main challenge
  6. Rapidly improving — better UX every year

Questions to Consider

  1. Will Lightning make on-chain Bitcoin obsolete for payments?
  2. How does Lightning affect Bitcoin's fee market?
  3. Can Lightning ever be as easy as Venmo?
  4. What happens if most Lightning nodes become large institutions?