📊 Scaling Architecture Comparison

Layer 1 (On-Chain) – Bitcoin Base Layer

Characteristics:

• Every transaction recorded permanently: All full nodes validate and store
• Global consensus required: Miners include in blocks, entire network agrees on state
• Maximum security: 51% attack threshold, irreversible after confirmations
• High cost, low throughput: Scarce block space → auction for inclusion → expensive
• Censorship resistant: No central authority can block transactions

Layer 2 (Off-Chain) – Lightning Network

Characteristics:

• Most transactions stay off-chain: Only channel open/close touch blockchain
• Local consensus: Only channel participants need to agree on state
• Backed by Layer 1 security: Can always settle on-chain if dispute
• Low cost, high throughput: No blockchain bottleneck—pure P2P payment
• Trade-offs: Requires online presence, liquidity locked in channels, routing complexity

🔐 Anatomy of a Payment Channel

Components:

1. Funding Transaction (On-Chain):
   • Creates 2-of-2 multi-sig output (both Alice and Bob must sign to spend)
   • Example: Alice and Bob each deposit 0.5 BTC → 1 BTC channel capacity
   • This UTXO is the channel—recorded on Bitcoin blockchain
2. Commitment Transactions (Off-Chain):
   • Pre-signed transactions spending the funding UTXO
   • Represents current balance distribution
   • Each party holds their version with asymmetric timelocks
   • Updated with every off-chain payment
3. Revocation Keys:
   • Cryptographic keys that invalidate old commitment transactions
   • If party broadcasts old state, counterparty can claim all funds (penalty)
   • Enforcement mechanism ensuring honest behavior

Example Channel State:

// Initial State (after funding)
Funding TX: 1 BTC in 2-of-2 multi-sig (Alice + Bob)
Alice's balance: 0.5 BTC
Bob's balance: 0.5 BTC

// After Alice pays Bob 0.2 BTC (off-chain)
Commitment TX v2:
  Alice's balance: 0.3 BTC
  Bob's balance: 0.7 BTC
  
// After Bob pays Alice 0.1 BTC (off-chain)
Commitment TX v3:
  Alice's balance: 0.4 BTC
  Bob's balance: 0.6 BTC

// Can update thousands of times - all off-chain!

🚀 Creating a Payment Channel

Step-by-Step Process:

1. Negotiation:
   • Alice and Bob agree on channel parameters (capacity, fee policy, timelock duration)
   • Exchange node public keys and channel IDs
2. Funding Transaction Construction:
   • Alice creates transaction: inputs from her wallet → output: 2-of-2 multi-sig (Alice + Bob)
   • Example: Alice funds 1 BTC, or Alice 0.5 BTC + Bob 0.5 BTC (dual-funded channel)
3. Initial Commitment Exchange:
   • Before broadcasting funding TX, create and sign initial commitment transactions
   • This ensures both parties can exit if funding TX confirms but channel never activates
   • Safety measure: Never fund channel without commitment TX in hand
4. Funding TX Broadcast:
   • Alice broadcasts funding transaction to Bitcoin network
   • Wait for confirmations (typically 3-6 blocks for safety)
5. Channel Activation:
   • After sufficient confirmations, channel is “open”
   • Can now exchange off-chain payments instantly
   • Funding UTXO sits on blockchain, commitment TXs remain off-chain unless dispute

On-Chain Footprint:

// Funding Transaction (visible on blockchain)
Input: 1.0 BTC from Alice's address
Output: 1.0 BTC to 2-of-2 multi-sig
  Script: OP_2 <Alice_PubKey> <Bob_PubKey> OP_2 OP_CHECKMULTISIG

// With Taproot (more private - looks like single-sig!)
Output: 1.0 BTC to bc1p... (aggregated Schnorr pubkey)

Cost: One on-chain transaction (~141 vbytes for SegWit, ~$3-10 depending on fee market). This pays for unlimited off-chain payments until channel closes.

🔒 Two Ways to Close a Channel

Cooperative Close (Normal, Preferred)

Process:

1. Both parties agree to close channel
2. Create final settlement transaction spending funding UTXO
3. Pays each party their current balance directly (no timelocks)
4. Both parties sign and broadcast

Advantages:

• Immediate access to funds (no waiting period)
• Lower fees (single transaction, smaller than commitment TX)
• More private (looks like normal Bitcoin transaction, not identifiable as Lightning)

Unilateral Close (Forced, Fallback)

When Used:

• Counterparty is offline or unresponsive
• Dispute over channel state
• Emergency exit needed

Process:

1. Alice broadcasts her latest commitment transaction
2. Alice’s output is timelocked (e.g., 1 day delay)
3. Bob’s output is immediately spendable by Bob
4. After timelock expires, Alice can claim her funds
5. If Alice broadcast old state, Bob has timelock period to submit penalty transaction (takes all funds)

Disadvantages:

• Timelock delay (typically 144 blocks = ~1 day)
• Higher fees (commitment TX larger, includes revocation logic)
• Less private (clearly identifiable as Lightning channel close)

🔐 HTLCs: The Secret Sauce of Lightning Routing

Problem to Solve:

• Alice wants to pay Dave through Bob and Carol
• Can’t trust Bob/Carol to forward payment honestly
• Need cryptographic guarantee: payment either succeeds atomically or fails completely

HTLC Structure:

Hash Time-Locked Contract = Hash Lock + Time Lock

1. Hash Lock: Money can be claimed by revealing preimage of hash
2. Time Lock: If preimage not revealed within timeout, money returns to sender

HTLC Payment Flow Example:

// Setup Phase
1. Dave (recipient) generates random secret: S
2. Dave computes hash: H = SHA256(S)
3. Dave sends invoice to Alice containing H (but NOT S)

// Payment Phase (Alice → Bob → Carol → Dave)
4. Alice creates HTLC with Bob:
   "I'll pay you 0.1 BTC if you reveal preimage of H within 10 blocks"
   
5. Bob creates HTLC with Carol:
   "I'll pay you 0.1 BTC if you reveal preimage of H within 8 blocks"
   
6. Carol creates HTLC with Dave:
   "I'll pay you 0.1 BTC if you reveal preimage of H within 6 blocks"

// Settlement Phase (Reverse order: Dave → Carol → Bob → Alice)
7. Dave reveals S to Carol (claims 0.1 BTC from Carol)
8. Carol now knows S, reveals to Bob (claims 0.1 BTC from Bob)
9. Bob now knows S, reveals to Alice (claims 0.1 BTC from Alice)

// Result: Payment routed atomically!
Alice: -0.1 BTC
Bob: 0 BTC (forwarded)
Carol: 0 BTC (forwarded)
Dave: +0.1 BTC

Critical Properties:

• Atomicity: Either everyone gets paid or no one does (no partial failures)
• Trustless: Intermediaries can’t steal—can only forward or timeout
• Time-decrementing: Each hop has shorter timeout (ensures downstream HTLCs settle before upstream)
• Hash-linking: Same hash H used for all hops—only recipient knows secret S initially

🧭 Finding Routes Through the Network

Challenge: Find path from sender to receiver that:

• Has sufficient liquidity at every hop
• Minimizes fees and number of hops
• Completes within reasonable time
• Doesn’t reveal payment amount/destination to routing nodes

Dijkstra’s Algorithm (Most Common):

1. Start with sender node
2. Explore all connected channels (weighted by fees + hops)
3. Find shortest path to receiver
4. Attempt payment along this path
5. If failure (insufficient liquidity), try next-best path

Information Problem:

• Sender knows: Network topology (which channels exist)
• Sender doesn’t know: Channel balance distribution (how much on each side)
• Privacy trade-off: Revealing exact balances would help routing but destroy privacy
• Result: Trial-and-error pathfinding—try route, if fails due to liquidity, try next

↔️ The Directionality Dilemma

Outbound Liquidity (Your Side)

• Definition: Amount you can send through channel
• How to get: Fund channel when opening, or receive payments
• Use case: Sending payments, routing others’ payments

Inbound Liquidity (Counterparty’s Side)

• Definition: Amount you can receive through channel
• How to get: Send payments out (depletes your side), or counterparty funds channel
• Use case: Receiving payments, accepting routed payments

Merchant Problem: Merchants primarily receive payments → need inbound liquidity. If they fund channels themselves, get only outbound liquidity initially → channel unusable until they send payments out first.

🚀 Next-Generation Lightning

1. Eltoo (Simplified Penalty-Free Channels)

Concept: Replace penalty mechanism with simpler “latest state wins” model

Benefits:

• No need to store revocation keys for every state update
• Simplified backup (only need latest state)
• Reduced liveness requirement (no penalty window to watch)
• Enables multi-party channels more easily

Status: Requires SIGHASH_ANYPREVOUT (BIP118)—not yet activated on Bitcoin

2. Channel Factories

Concept: Hierarchical channels—many Lightning channels inside single on-chain UTXO

Benefits:

• Massive reduction in on-chain footprint (1 UTXO → 100+ channels)
• Lower fees (open/close many channels with single transaction)
• Better scalability (millions of channels, thousands of on-chain TXs)

Status: Proof-of-concept implementations, requires covenant opcodes for best design

3. Async Payments (Trampoline Routing)

Concept: Intermediate nodes handle routing, sender doesn’t need full network view

Benefits:

• Mobile wallets don’t need to store full network graph (~500 MB)
• Faster pathfinding (offload to routing node)
• Better for offline receivers (trampoline holds payment until online)

Status: Partially deployed (Phoenix wallet uses trampoline)

4. Taproot Channels

Concept: Lightning channels using Taproot instead of SegWit

Benefits:

• Better privacy (channel opens/closes look like normal payments)
• Smaller transactions (~5-10% size reduction)
• Enables more complex scripts via MAST

Status: Specification finalized, gradual deployment 2023-2024

5. Onion Messages & Offers (BOLT 12)

Concept: Encrypted messaging over Lightning + reusable payment codes

Benefits:

• Static payment codes (like addresses) instead of one-time invoices
• Better privacy (payment requests encrypted)
• Enables subscriptions, recurring payments

Status: BOLT 12 spec finalized, implementation in progress