Chapter 23

Payment Channels

The Foundation of Layer 2 Scaling

Bitcoin's blockchain processes approximately 7 transactions per second globally. Payment channels provide a mechanism for parties to transact thousands of times while touching the blockchain only twice—once to open the channel and once to close it.

This chapter develops the theory of payment channels from first principles, building from simple unidirectional channels to the sophisticated bidirectional channels that underpin the Lightning Network. Understanding these primitives is essential for grasping how Bitcoin scales to millions of transactions per second.

23.1 The Scaling Problem

Bitcoin's on-chain capacity is fundamentally limited:

Definition 23.1 (On-Chain Throughput Limit)

With ~4 million weight units per block and ~10 minutes per block:

  • Average transaction: ~500-1000 weight units
  • Transactions per block: ~2000-4000
  • Transactions per second: ~3-7 TPS
  • Transactions per day: ~300,000-600,000

This is roughly 7 orders of magnitude below global payment demand.

Layer 2 Approach

Rather than increasing block size (which has centralizing effects), Layer 2 solutions move transactions off-chain while preserving Bitcoin's security:

Theorem 23.1 (Payment Channel Scaling)

A payment channel between two parties requires:

  • On-chain: 2 transactions (open + close)
  • Off-chain: Unlimited transactions between parties

If a channel supports N off-chain payments, throughput multiplies by N/2.

23.2 Unidirectional Payment Channels

We begin with the simplest channel type: one party (customer) pays another (merchant) repeatedly.

Basic Construction

Definition 23.2 (Unidirectional Channel)

A unidirectional payment channel from Alice to Bob:

  1. Funding: Alice locks funds in a 2-of-2 multisig with Bob
  2. Payments: Alice signs transactions giving Bob increasing amounts
  3. Settlement: Bob broadcasts the latest transaction
Unidirectional Payment Channel Funding Transaction Input: Alice's UTXO (1 BTC) Output: 2-of-2 multisig (Alice + Bob) Broadcast Blockchain Off-Chain Payments (Not Broadcast) Payment 1 Alice: 0.9 BTC Bob: 0.1 BTC Payment 2 Alice: 0.7 BTC Bob: 0.3 BTC ... Final State Alice: 0.2 BTC Bob: 0.8 BTC Settlement (broadcast)
Figure 23.1 — Unidirectional channel: Alice funds a multisig, signs transactions giving Bob increasing amounts, Bob broadcasts the final state.

Security Analysis

Theorem 23.2 (Unidirectional Channel Security)

In a unidirectional channel:

  • Bob's guarantee: Can always claim the latest payment Alice signed
  • Alice's guarantee: Bob can only claim what Alice signed
  • Problem: Alice cannot recover uncommitted funds if Bob disappears

Adding Timelocks

To allow Alice to recover funds if Bob is unresponsive, we add a refund path:

Definition 23.3 (Timelocked Unidirectional Channel)

The funding output script: 

OP_IF
    2 <Alice_pubkey> <Bob_pubkey> 2 OP_CHECKMULTISIG
OP_ELSE
    <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <Alice_pubkey> OP_CHECKSIG
OP_ENDIF

Either: 2-of-2 multisig (normal operation)
Or: After locktime, Alice can recover funds alone

Example 23.1 (Coffee Shop Channel)

Alice opens a 0.1 BTC channel to her local coffee shop:

  1. Day 1: Fund channel (0.1 BTC), refund timelock = 30 days
  2. Day 2: Buy coffee, sign tx giving shop 0.004 BTC
  3. Day 5: Buy coffee, sign tx giving shop 0.008 BTC
  4. ... (many more coffees)
  5. Day 25: Balance is Alice 0.02, Shop 0.08
  6. Day 26: Shop broadcasts final state, closes channel

30 coffees, 2 on-chain transactions.

23.3 The Bidirectional Channel Problem

Unidirectional channels only allow value to flow one way. For general payment networks, we need bidirectional channels where either party can pay the other.

Problem 23.1 (State Revocation)

In a bidirectional channel, both parties sign each state update. The problem: how to prevent a party from broadcasting an old, favorable state?

Example 23.2 (The Double-Spend Attack)

Alice and Bob open a channel with 0.5 BTC each:

  1. State 1: Alice 0.5, Bob 0.5 (initial)
  2. State 2: Alice 0.3, Bob 0.7 (Alice paid Bob 0.2)
  3. State 3: Alice 0.6, Bob 0.4 (Bob paid Alice 0.3)

If Bob broadcasts State 2 instead of State 3, he steals 0.3 BTC. We need a mechanism to punish broadcasting old states.

Solution Approaches

Approach Mechanism Used In
Replace-by-version nSequence invalidation Historical (limited)
Punishment Breach remediation LN-Penalty (current Lightning)
Symmetry Relative timelocks eltoo/LN-Symmetry (proposed)

23.4 LN-Penalty Channels

The Lightning Network uses revocable commitment transactions with a punishment mechanism: if you broadcast an old state, your counterparty can take all the funds.

Commitment Transaction Structure

Definition 23.4 (Commitment Transaction)

Each party holds their own version of the commitment transaction. Alice's version:

  • Input: Spends the funding output (2-of-2 multisig)
  • Output 1 (to Alice): Delayed by timelock OR Bob can spend with revocation key
  • Output 2 (to Bob): Immediately spendable by Bob

Bob's version is symmetric (his output delayed, Alice's immediate).

Asymmetric Commitment Transactions Funding Output 2-of-2 (Alice, Bob) Alice's Commitment TX (Held by Alice) To Alice (delayed) IF: Alice after 144 blocks ELSE: Bob with revocation_key To Bob (immediate) Bob can spend immediately Bob's Commitment TX (Held by Bob) To Bob (delayed) IF: Bob after 144 blocks ELSE: Alice with revocation_key To Alice (immediate) Alice can spend immediately Key Insight: Asymmetry Creates Accountability The broadcaster's funds are delayed; counterparty can punish if state was revoked
Figure 23.2 — Each party holds a different commitment transaction. The broadcaster's funds are delayed, giving the counterparty time to punish if an old (revoked) state is broadcast.

Revocation Mechanism

Definition 23.5 (Revocation Keys)

Each commitment uses unique revocation keys:

  • revocation_basepoint: Each party's fixed public key
  • per_commitment_point: Unique per state, derived from secret
  • revocation_pubkey: Derived from both, known to counterparty after revocation

To revoke state N, a party reveals the per_commitment_secret for state N. This allows the counterparty to compute the revocation private key.

Algorithm 23.1 (State Update Protocol)

// To update from state N to state N+1:

1. Alice creates commitment_tx_{N+1} for Bob
   - Uses new per_commitment_point from Bob
   - Signs it with her funding key
   - Sends signature to Bob

2. Bob creates commitment_tx_{N+1} for Alice
   - Uses new per_commitment_point from Alice
   - Signs it with his funding key
   - Sends signature to Alice

3. Alice sends per_commitment_secret_N to Bob
   (Revokes state N - Bob can now punish if Alice broadcasts)

4. Bob sends per_commitment_secret_N to Alice
   (Revokes state N - Alice can now punish if Bob broadcasts)

// State N is now revoked; only state N+1 is safe to broadcast

Punishment Transaction

Definition 23.6 (Breach Remedy Transaction)

If a party broadcasts a revoked commitment:

  1. The honest party detects the old state on-chain
  2. During the timelock delay, they construct a punishment transaction
  3. Using the revealed revocation secret, they spend ALL channel funds
  4. The cheater loses everything

Theorem 23.3 (LN-Penalty Security)

In an LN-Penalty channel:

  • Honest behavior: Both parties receive their balance
  • Cheating attempt: Cheater loses all funds to counterparty
  • Requirement: Honest party must be online during timelock

23.5 Channel Operations

Channel Lifecycle

Payment Channel Lifecycle Opening Normal Closing Closed Force Close On-chain Off-chain On-chain
Figure 23.3 — Channel lifecycle: opening and closing are on-chain; normal operation is entirely off-chain.

Opening a Channel

Algorithm 23.2 (Channel Opening)

1. Alice proposes: open_channel message
   - Funding amount, fee rate, keys, parameters

2. Bob accepts: accept_channel message
   - His keys and parameters

3. Alice creates funding transaction (not broadcast yet)
   - 2-of-2 output with both keys

4. Alice sends funding_created with:
   - Funding txid/vout
   - Signature for Bob's first commitment

5. Bob validates and sends funding_signed with:
   - Signature for Alice's first commitment

6. Alice broadcasts funding transaction

7. Both watch for confirmations

8. After N confirmations: channel_ready (formerly funding_locked)

Cooperative Close

Definition 23.7 (Cooperative Close)

The ideal channel close:

  1. Either party sends shutdown message
  2. No new HTLCs accepted
  3. Existing HTLCs resolved
  4. Parties negotiate closing transaction
  5. Simple outputs (no delays, no scripts)
  6. Both sign and broadcast

Result: Immediate access to funds, minimal fees.

Force Close

Definition 23.8 (Unilateral Close)

If cooperation fails:

  1. One party broadcasts their commitment transaction
  2. Their own funds are timelocked (e.g., 144 blocks / ~1 day)
  3. Counterparty's funds are immediately available
  4. HTLCs resolved with additional transactions

Result: Delayed access, higher fees, but trustless.

23.6 HTLCs: Conditional Payments

Payment channels become truly powerful when combined with Hash Time-Locked Contracts (HTLCs), enabling conditional payments and multi-hop routing.

Definition 23.9 (HTLC)

A Hash Time-Locked Contract locks funds that can be claimed in two ways:

  • Success path: Recipient provides preimage R where H(R) = hash
  • Timeout path: Sender reclaims after timeout expires
OP_IF
    OP_HASH160 <payment_hash> OP_EQUALVERIFY
    <recipient_pubkey> OP_CHECKSIG
OP_ELSE
    <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <sender_pubkey> OP_CHECKSIG
OP_ENDIF

HTLC in Commitment Transactions

When an HTLC is added to a channel, commitment transactions include additional outputs:

Channel State with HTLC

Funding: 1.0 BTC total

Alice balance: 0.4 BTC

Bob balance: 0.3 BTC

HTLC (Alice → Bob): 0.3 BTC, hash=abc123, timeout=block 700000

Alice: 0.4
HTLC: 0.3
Bob: 0.3

HTLC Resolution

Algorithm 23.3 (HTLC Lifecycle)

// Adding an HTLC
1. Alice sends update_add_htlc:
   - Amount, payment_hash, expiry
2. Both create new commitment txs with HTLC output
3. Exchange signatures, revoke old state

// Success (Bob knows preimage)
4a. Bob sends update_fulfill_htlc with preimage R
5a. Both create new commitments moving HTLC amount to Bob
6a. Exchange signatures, revoke HTLC state

// Timeout (expiry passes)
4b. Alice sends update_fail_htlc
5b. Both create new commitments returning amount to Alice
6b. Exchange signatures, revoke HTLC state

23.7 Watchtowers

A key requirement of LN-Penalty channels: the honest party must monitor the blockchain during the timelock period. Watchtowers provide this service.

Definition 23.10 (Watchtower)

A watchtower is a service that:

  1. Receives encrypted breach remedy data from channel participants
  2. Monitors the blockchain for revoked commitments
  3. Broadcasts punishment transactions if breach detected
  4. Optionally collects a fee from recovered funds

Watchtower Privacy

Theorem 23.4 (Watchtower Privacy)

Watchtowers can operate without learning channel balances:

  • Client provides encrypted blob keyed to commitment txid
  • Watchtower cannot decrypt without seeing breach on-chain
  • Blob contains only enough info to construct punishment

Exercises

Exercise 23.1

Design a unidirectional payment channel using only OP_CHECKLOCKTIMEVERIFY and multisig. What are the limitations compared to bidirectional channels?

Exercise 23.2

Prove that in an LN-Penalty channel, a rational actor will never broadcast an old state, assuming they value funds more than the cost of the punishment.

Exercise 23.3

Calculate the maximum number of state updates before the commitment transaction becomes too large to broadcast (assuming ~100 bytes per HTLC and standard transaction size limits).

Exercise 23.4

Alice and Bob have a channel. Alice goes offline for 1 week. Bob broadcasts a state from 3 days ago. Analyze the security implications if the timelock is (a) 144 blocks, (b) 2016 blocks.

Exercise 23.5

Design an HTLC that uses Schnorr signatures instead of hash preimages. What privacy benefits does this provide? (Hint: adaptor signatures)

Exercise 23.6

Calculate the on-chain footprint reduction for 1000 users each making 100 payments per day via payment channels vs. on-chain transactions.

Chapter Summary