Module 1: Payment Channels

🤔 The Scaling Problem

Bitcoin's base layer processes ~7 transactions per second. To become global money, we need millions of transactions per second. But increasing the block size would centralize the network by making it expensive to run a full node.

Key Insight: What if most transactions didn't need to be on the blockchain? What if two parties could transact thousands of times with only two on-chain transactions: one to open a channel, one to close it?

That's exactly what Lightning payment channels enable.

What is a Payment Channel?

A payment channel is a bidirectional payment relationship between two parties (Alice and Bob) that allows them to send bitcoin back and forth instantly, with near-zero fees, without broadcasting transactions to the blockchain.

The Core Concept

Think of it like a bar tab:

1. You open a tab (put money down) → Opening transaction (on-chain)
2. You order drinks throughout the night → Off-chain payments
3. At the end, you settle the final balance → Closing transaction (on-chain)

But unlike a bar tab where you trust the bartender, Lightning channels are trustless— either party can close the channel at any time and get their correct balance, enforced by Bitcoin's consensus rules.

Channel Lifecycle

1. Channel Opening

Alice wants to open a channel with Bob. She creates a funding transaction that locks Bitcoin in a 2-of-2 multisig address controlled by both Alice and Bob.

┌─────────────────────────────────────┐
│   Funding Transaction (on-chain)   │
├─────────────────────────────────────┤
│                                     │
│  Alice locks: 0.5 BTC               │
│  Bob locks:   0.3 BTC               │
│  ─────────────────────              │
│  Total:       0.8 BTC               │
│                                     │
│  → 2-of-2 Multisig Address          │
│    (requires both signatures)       │
└─────────────────────────────────────┘

Important: Before broadcasting the funding transaction, Alice and Bob create the first commitment transaction that allows them to get their money back. This prevents one party from stealing funds.

2. Channel Updates (Off-Chain Payments)

Once the channel is open, Alice and Bob can update the balance distribution as many times as they want without touching the blockchain. Each update creates a new commitment transaction that spends from the funding transaction.

State 0 (Opening):
Alice: 0.5 BTC  |  Bob: 0.3 BTC

Alice pays Bob 0.1 BTC → State 1:
Alice: 0.4 BTC  |  Bob: 0.4 BTC

Bob pays Alice 0.2 BTC → State 2:
Alice: 0.6 BTC  |  Bob: 0.2 BTC

Alice pays Bob 0.05 BTC → State 3:
Alice: 0.55 BTC  |  Bob: 0.25 BTC

Each state is represented by a pair of commitment transactions (one for Alice, one for Bob). Only the latest state should be broadcastable—old states must be revoked.

3. Channel Closing

Either party can close the channel at any time:

• Cooperative Close: Both parties agree on the final balance and sign a closing transaction. Fast and cheap.
• Unilateral Close: One party broadcasts their latest commitment transaction. Requires a time delay for security.
• Breach Close: If someone tries to broadcast an old state, the other party can claim all funds as a penalty.

Commitment Transactions: The Security Mechanism

The brilliant part of Lightning is the revocation mechanism that makes old channel states unbroadcastable (or extremely costly to broadcast).

How Commitment Transactions Work

Each time Alice and Bob update the channel balance, they create two commitment transactions:

• Alice's commitment tx: Spends the funding output, gives Bob his balance immediately, but delays Alice's balance
• Bob's commitment tx: Spends the funding output, gives Alice her balance immediately, but delays Bob's balance

Why the delay? The delay (typically 144 blocks / ~1 day) gives the other party time to detect if you're broadcasting an old state and punish you.

Revocation Keys

When moving to a new state, both parties exchange revocation keys for the previous state. This key allows the other party to spend your delayed output if you cheat by broadcasting an old commitment transaction.

Alice broadcasts old State 1 (cheating):
┌────────────────────────────────┐
│ State 1: Alice 0.4, Bob 0.4    │
└────────────────────────────────┘
         ↓
Bob detects this (watchtower or running node)
         ↓
Bob uses revocation key to claim ALL 0.8 BTC
         ↓
🎉 Bob gets 0.8 BTC, Alice gets 0 (penalty)

This penalty mechanism is what makes Lightning trustless—trying to cheat results in losing all your funds.

Technical Deep Dive

Commitment Transaction Structure

A commitment transaction has two outputs:

Commitment Transaction (Alice's version):
├─ Output 0: Bob's balance
│  └─ scriptPubKey: Bob can spend immediately
│
├─ Output 1: Alice's balance
   └─ scriptPubKey: Two spending paths:
      ├─ Path 1: Alice can spend after timelock (144 blocks)
      └─ Path 2: Bob can spend immediately using revocation key

RSMC (Revocable Sequence Maturity Contract)

The script that enables revocable commitments uses OP_CHECKSEQUENCEVERIFY:

OP_IF
    # Revocation path
    <revocation_pubkey>
OP_ELSE
    # Delayed path
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayed_pubkey>
OP_ENDIF
OP_CHECKSIG

This allows either the revocation key to spend immediately (if cheating is detected) or the owner to spend after a delay.