Part VI · Protocol Layer Chapter 18

Lightning Network: Payment Channels

Every transaction type we have studied—P2PKH, P2WSH, multisig, timelocks, RBF, CPFP—converges in the Lightning Network. Lightning is not a separate blockchain or token; it is a protocol for constructing Bitcoin transactions that parties hold but do not broadcast, updating them off-chain until a final settlement is written to the blockchain.

This chapter examines the on-chain transaction anatomy of Lightning: the funding transaction that opens a channel, the commitment transactions that track balances, the HTLC outputs that route payments, and the closing transactions that settle on-chain. All formats follow BOLT 3^†, the Lightning specification for on-chain transactions.

18.1The Funding Transaction

A Lightning channel begins with a funding transaction: an on-chain transaction that locks bitcoin into a 2-of-2 P2WSH multisig output.

18.1.1The Funding Output Script

The funding output is a P2WSH whose witness script is:

where pubkey1 is the lexicographically lesser of the two funding public keys (compressed, 33 bytes each) and pubkey2 is the greater. The canonical ordering ensures both parties derive the same script and the same P2WSH address.

18.1.2Channel Lifecycle

Once the funding transaction confirms on-chain, the channel passes through three phases — only the first and last touch the blockchain:

The funding output is never spent during normal operation. It sits on-chain, holding the channel's capacity, while the commitment transactions (held off-chain) track the current balance. Hundreds or thousands of payments can flow through a channel before either party touches the blockchain again.

18.2Commitment Transactions

The core innovation of Lightning is the commitment transaction: a pre-signed Bitcoin transaction that both parties hold but do not broadcast. Each commitment transaction spends the funding output and distributes the channel's balance according to the current state.

18.2.1Asymmetric Commitments

The problem. A Lightning channel must support unilateral exit — either party should be able to settle on chain at any time, even if the other has gone offline or become hostile. The funding output is a 2-of-2 multisig, so no party can spend it alone with a fresh signature; the only way out is to broadcast a transaction that has already been signed by both parties. Lightning therefore has both parties pre-sign settlement transactions in advance — one per channel state — and hold them privately until they're needed.

This raises an immediate problem: every new payment creates a new state, but the OLD signed settlements never disappear. Alice could simply broadcast a stale commitment from a moment when she held a more favorable balance. What stops her?

The answer: an asymmetric design with a built-in kill-switch. Three ingredients work together to make stale-state broadcasts an objectively losing bet:

1. Each party holds a different version of the commitment for the same state. When the channel is at state #N, Alice holds commitment_A(N); Bob holds commitment_B(N). Same balances, different shape.
2. The party who broadcasts their commitment puts their own funds in jail. The version Alice holds locks Alice's payout under a 144-block CSV delay; Bob's payout is immediately spendable. Bob's version mirrors this. The CSV always lands on the broadcaster's own funds.
3. Every state transition exchanges a "revocation secret" for the previous state. When state #6 is negotiated, Alice gives Bob her revocation secret for state #5, and Bob gives Alice his. From that moment on, anyone who broadcasts a state for which the counterparty holds the revocation secret can be punished within the 144-block CSV window: the counterparty derives a revocation key from the secret and uses it to sweep both their own to_remote AND the broadcaster's CSV-locked to_local in a single penalty transaction. Total balance, not just the cheating delta.

The diagram below shows both versions of state #1 for the specimen channel — same 60M/40M split, but with the CSV encumbrance on opposite outputs.

Both transactions distribute the same 60M / 40M balance (less the two 330-sat anchors, paid from the initiator Alice's side; the commitment fee is ignored here for clarity), but the CSV delay always lands on the broadcaster's own funds. Three consequences fall out of this single architectural choice:

1. Force-closing the current state is just a UX tax, not a security risk. If you broadcast the latest state, you wait 144 blocks (~24 hours) to access your own funds. Inconvenient, but safe — no one holds the revocation secret for a state that hasn't yet been replaced. This is the small price of being able to exit a channel without your counterparty's cooperation.
2. Broadcasting an OLD state is a strict net-loss bet. If you publish a stale commitment, the other party uses the revocation secret to construct a single penalty transaction that sweeps the entire 100M-sat channel balance — both their to_remote and your CSV-locked to_local. You don't merely forfeit the cheating profit; you forfeit everything you legitimately held, plus everything they legitimately held, in one unified swing of the hammer.
3. The penalty is total, not proportional, and that's the point. A proportional penalty (only losing the cheating delta) would still permit rational cheating whenever detection probability fell below some threshold — high-stakes cheats with low expected detection would clear positive expected value. A total penalty makes cheating a losing bet for any non-zero detection probability. This is the property that allows hundreds of off-chain state updates to safely accumulate between on-chain transactions: the strategy "broadcast whichever historical state is most favorable to me" has negative expected value at every moment.

The interactive widget below lets you move through six states of the specimen channel and see — visually — what happens when either party broadcasts each one, current or revoked.

18.2.2Commitment Transaction Structure

Per BOLT 3, a commitment transaction has:

Field	Value
Version	2
Input	Funding outpoint (2-of-2 P2WSH)
nSequence	Upper 8 bits = 0x80, lower 24 bits = upper 24 bits of obscured commitment #
nLockTime	Upper 8 bits = 0x20, lower 24 bits = lower 24 bits of obscured commitment #
Outputs	to_local, to_remote, HTLCs, anchors

The 48-bit commitment number is obscured by XOR with the lower 48 bits of: \[ \text{SHA256}(\textit{payment\_basepoint}_A \| \textit{payment\_basepoint}_B) \] This hides how many state updates have occurred, so a passive on-chain observer cannot infer channel activity, payment frequency, or the number of failed payment attempts from a broadcast commitment. The nLockTime carries the lower 24 bits and nSequence carries the upper 24 bits, so together they reconstruct the full obscured value. The 0x20 prefix places nLockTime above 500,000,000 (interpreted as a past Unix timestamp), and the 0x80 prefix sets bit 31 of nSequence (disabling BIP 68)—neither field imposes an actual lock.

18.2.3The to_local Output

The to_local output returns funds to the commitment's owner, but with two spending paths:

• Normal path (OP_ELSE): The owner spends after waiting to_self_delay blocks (typically 144–2,016). Witness: <local_sig> <>
• Revocation path (OP_IF): If this is a revoked commitment, the counterparty can spend immediately using the revocation key. Witness: <revocation_sig> 1

The trailing witness element selects the branch: OP_IF executes its then block when the top of stack is non-zero (here, 1 selects the revocation path) and falls through to OP_ELSE when the top of stack is empty or zero (here, <>—OP_FALSE—selects the normal path).

18.2.4The to_remote Output

The counterparty's funds. In the simplest case, this is a standard P2WPKH output, immediately spendable with no delay.

With option_anchors (the modern default), the to_remote output adds a 1-block CSV lock:

This 1-block delay ensures the output cannot be spent in the same block as the commitment, preventing certain fee-manipulation attacks.

18.2.5Worked Example: A Single Payment Update

Walk through the very first payment after the channel opens. Starting state is #1 (60M / 40M from the specimen above); Alice pays Bob 10,000,000 sats; the result is state #2 (50M / 50M).

18.3Revoking Old States

Every time the channel state updates (a payment is made), both parties:

1. Exchange signatures for the new commitment transaction.
2. Reveal the revocation secret for the old commitment.

Once Alice reveals her old revocation secret, she has effectively "destroyed" her old commitment: if she broadcasts it, Bob can use the revocation key to claim all channel funds (not just his share—all of it). This is the penalty mechanism that keeps Lightning honest.

18.3.1Worked Example: Bob Tries to Cheat

The specimen channel has been busy. Many payments have flowed both ways since state #1 (Alice 60M / Bob 40M from the specimen). At state #5, Bob had been ahead: Alice 30M / Bob 70M. By state #20, the pendulum has swung back: Alice 80M / Bob 20M. Bob is currently holding his commitment for state #20 — but he never deleted his old commitment for state #5, and he's tempted. If he can broadcast state #5 and have it confirm before Alice notices, he claims 70M sats instead of the 20M he is honestly owed.

18.4HTLC Outputs

So far our specimen has just two parties — but the real power of Lightning is routed payments: paying a third party (Carol) by hopping through intermediaries (Bob). To make a multi-hop payment atomic, the same payment_hash appears as an HTLC output on every channel along the route. Carol controls the preimage; revealing it on her last hop cascades back through every intermediate channel.

Red arrows: HTLCs locked forward (sender → receiver)   ·   Green arrows: preimage revealed backward, HTLCs settle

Each in-flight payment adds an HTLC output with two spending paths:

• Success path: The recipient reveals the hash preimage and claims the funds.
• Timeout path: If the preimage is not revealed before the CLTV expiry, the sender reclaims the funds.

Both paths additionally include a revocation clause (if the commitment is revoked, the counterparty claims everything).

BOLT 3 defines two HTLC types:

• Offered HTLC: An HTLC the local node is offering (outgoing payment).
• Received HTLC: An HTLC the local node has received (incoming payment).

The offered HTLC witness script (without option_anchors) illustrates all three spending paths:

• Revocation path: The counterparty pushes <revocation_sig> <revocationpubkey>. The script hashes the key, matches it against the revocation hash, and verifies the signature.
• Preimage (success) path: The remote node pushes <remote_sig> <payment_preimage>. The OP_SIZE 32 OP_EQUAL check distinguishes a 32-byte preimage from a public key; the script verifies the hash and signature.
• Timeout path: The local node uses an HTLC-timeout transaction (with nLockTime set to the CLTV expiry). The 2-of-2 OP_CHECKMULTISIG requires both local and remote HTLC signatures, ensuring the timeout cannot be claimed unilaterally before expiry.

HTLC outputs are resolved via separate HTLC-success and HTLC-timeout transactions (second-stage transactions), each of which includes its own CSV delay. This two-stage design separates the HTLC resolution from the to_self_delay, preventing the delay from extending HTLC timeouts across the network.

18.4.1Worked Example: Alice Pays Carol 5M Sats via Bob

Assume two channels: our specimen Alice↔Bob (state #2 from §18.2.5: 50M / 50M), plus a Bob↔Carol channel that opened separately (50M / 50M). Carol has been waiting for a payment of 5,000,000 sats. Bob is willing to forward for a 1,000-sat fee.

18.5Closing Transactions

A Lightning channel can close in three ways. Which path the channel takes depends on the answers to two questions: are both parties online and cooperating? and has either party already broadcast a revoked commitment?

18.5.1Cooperative Close

Both parties agree on the final balance and co-sign a closing transaction that spends the funding output directly to each party's address. No timelocks, no HTLCs, no delays—the simplest and most efficient close.

18.5.2Force Close (Unilateral)

One party broadcasts their latest commitment transaction. The broadcaster's funds are subject to the CSV delay (to_local); the counterparty receives their funds immediately (to_remote). Any in-flight HTLCs are resolved on-chain via HTLC-success or HTLC-timeout transactions.

Force closes are expensive: multiple on-chain transactions, each paying fees, and funds locked for the delay period.

18.5.3Breach Remedy (Penalty)

If a party broadcasts a revoked commitment, the counterparty detects it (directly or via a watchtower) and broadcasts a penalty transaction that sweeps all outputs using the revocation key. The cheating party loses their entire channel balance.

18.6Anchor Outputs and Fee Management

Commitment transactions are pre-signed, so their fee is fixed at signing time. If the fee market changes between signing and broadcast, the commitment may be too expensive (wasting funds) or too cheap (failing to confirm).

Anchor outputs solve this by attaching small, spendable outputs (330 sats each, per BOLT 3) to the commitment. Each party gets its own anchor, locked to their funding key:

The keyholder spends immediately with <sig>. If the anchor remains unspent for 16 blocks, anyone can sweep it with an empty witness (<>), preventing UTXO set pollution. This "self-cleaning" design ensures abandoned anchors do not bloat the UTXO set indefinitely.

Either party can use CPFP (Chapter 17) to attach a high-fee child to their anchor, adjusting the effective feerate at broadcast time.

With TRUC transactions and package relay (also Chapter 17), this mechanism is further improved: the commitment can pay minimal or even zero fees, with the child transaction covering the full cost.

18.7What We Learned

• A Lightning channel is opened by a funding transaction: a 2-of-2 P2WSH multisig output (BOLT 3).
• Commitment transactions are asymmetric: the broadcaster's funds are CSV-delayed, the counterparty's are immediate.
• The to_local output has two paths: normal (CSV delay) and revocation (immediate, for penalty).
• Old states are revoked by exchanging secrets; broadcasting a revoked commitment forfeits the entire balance.
• HTLC outputs route payments: success (preimage) or timeout (CLTV). Resolved via second-stage transactions.
• Channels close cooperatively (efficient), by force close (unilateral), or by penalty (breach remedy).
• Anchor outputs (330 sats) enable fee-bumping via CPFP after broadcast.

18.7.1Looking Ahead

Lightning uses Bitcoin's transaction primitives for payments. Chapter 19 explores a very different use of transaction anatomy: Ordinals and Inscriptions, which embed arbitrary data—images, text, even programs—into the witness field, turning Bitcoin into a data layer.

Exercises

Litmus (L)

1. What type of output does a Lightning funding transaction create?
2. Why does the to_local output have a CSV delay?
3. What happens if a party broadcasts a revoked commitment transaction?
4. Name the three types of channel closure.
5. What is the purpose of anchor outputs?

Hands-On (H)

1. Write the to_local witness script for a channel with to_self_delay = 144 blocks. What nSequence value must the spending input use?
2. A commitment transaction has a 500-sat fee but needs 20 sat/vB to confirm. The commitment is 900 vB and the anchor output is 330 sats. Design a CPFP strategy: how large and how expensive must the child transaction be?
3. In a multi-hop payment A → B → C, the HTLC from A to B has CLTV expiry at block \(n+40\) and B to C expires at block \(n+20\). Why must A's timeout be larger than B's?

Proofs and Reasoning (P)

1. Explain why commitment transactions are asymmetric. What would go wrong if both parties held identical commitment transactions?
2. Why are HTLC outputs resolved via second-stage transactions (HTLC-success, HTLC-timeout) rather than directly from the commitment?
3. Explain the economic game theory behind the penalty mechanism. Under what conditions is it rational for a party to broadcast a revoked commitment?

Connections (C)

1. Timelock layers. Identify every timelock mechanism (nLockTime, CSV, CLTV) used in a Lightning force close with in-flight HTLCs. Describe what each one protects against.
2. SegWit dependency. Explain why Lightning requires SegWit (BIP 141). What problem would transaction malleability cause for the commitment transaction chain?

Bridge (B)

1. Chapter 19 covers Ordinals inscriptions, which embed data in the witness. Could an Ordinals inscription be embedded inside a Lightning commitment transaction? Why or why not?
2. Compare the efficiency of Lightning (off-chain payments settled via commitment transactions) with on-chain batching (Chapter 15's OP_RETURN discussion). When is each approach more appropriate?

Solutions

L1. A 2-of-2 P2WSH multisig output. The witness script is OP_2 <pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG, with keys in lexicographic order.

L2. The CSV delay creates a time window during which the counterparty can detect and punish a revoked commitment. Without the delay, the broadcaster could spend their output immediately, leaving no opportunity for the penalty transaction.

L3. The counterparty can claim the entire channel balance using the revocation key. The broadcaster loses all funds—not just the counterparty's share, but their own share too. This is the penalty mechanism.

L4. (1) Cooperative close (both parties agree, no delays). (2) Force close (one party broadcasts their latest commitment, CSV delays apply). (3) Breach remedy / penalty (revoked commitment detected, all funds swept).

L5. Anchor outputs (330 sats each) allow either party to fee-bump the commitment transaction via CPFP after broadcast. This decouples the fee decision from the signing time.

H1. The to_local witness script:

The spending input must set \(\texttt{nSequence} = 144 = \texttt{0x00000090}\) (BIP 68 block-based relative timelock). In the witness: <local_sig> <> (the empty vector selects the OP_ELSE branch).

H2. Target: 20 sat/vB for the package. Package = commitment (900 vB, 500 sats) + child. Assume, for round numbers, a 141-vB child spending the 330-sat anchor (in practice the anchor spend is a P2WSH witness-script input, and the extra funding input adds roughly 70 vB, raising the required fee accordingly).

Required package feerate: \((500 + f) / (900 + 141) = 20\), so \(f = 20 \times 1,041 - 500 = 20,320\) sats.

The child must pay 20,320 sats in fees (144 sat/vB for the child alone). The child spends the 330-sat anchor, so it needs an additional input providing at least \(20,320 - 330 = 19,990\) sats.

H3. If C claims the preimage from B (settling the BC HTLC), B must relay the preimage upstream to settle the AB HTLC before A's timeout. If A's timeout were \(\leq\) B's, then A could reclaim funds via timeout before B can settle—B would lose the payment. The decreasing timeouts (\(n+40 > n+20\)) give each hop a safety margin to propagate the preimage upstream.

P1. If both parties held identical commitments, the revocation mechanism would fail. When Alice reveals her revocation secret, she would also be revealing the key to her own commitment—Bob could use it against her even if she broadcast the current (non-revoked) state. Asymmetric commitments solve this: Alice's revocation secret only compromises Alice's version of the commitment. Bob's version has a different revocation key derived from Bob's secret. Each party can safely reveal old secrets without compromising their current commitment.

P2. If HTLC outputs were resolved directly from the commitment (without second-stage transactions), the CSV to_self_delay would apply to HTLC resolution. This would extend the effective HTLC timeout by the delay period. For multi-hop payments, each hop adds delay, so a 144-block delay per hop on a 5-hop route would add 720 blocks (5 days) to the HTLC timeout. Second-stage transactions decouple the CSV delay from HTLC resolution: the HTLC can be resolved (success or timeout) immediately, and only the resulting output is delayed. This keeps HTLC timeouts reasonable across the network.

P3. Broadcasting a revoked commitment is economically rational only if the counterparty cannot detect it before the CSV delay expires—i.e., the counterparty is offline and has no watchtower. If detected, the broadcaster loses their entire balance (penalty). The expected value of cheating is: \(P(undetected) \times gain - P(detected) \times entire_{balance}\). As long as the counterparty (or their watchtower) monitors the chain, \(P(detected) \approx 1\), making cheating deeply irrational. The penalty must be total (not proportional) to ensure the expected value is negative even for small probability of detection.

C1. Timelocks in a Lightning force close:

• nLockTime on the commitment: lower 24 bits carry the lower half of the 48-bit obscured commitment number. The 0x20 prefix makes it a past Unix timestamp—not a functional lock.
• nSequence on the commitment input: lower 24 bits carry the upper half of the obscured commitment number. The 0x80 prefix disables BIP 68.
• CSV on to_local: prevents the broadcaster from spending their own funds for the delay period—the revocation window.
• CSV on to_remote (anchors): 1-block delay prevents same-block spending.
• CLTV on HTLC outputs: absolute timeout for the hash-lock; if the preimage is not revealed by this block, the sender reclaims.
• CSV on second-stage HTLC transactions: delays the resolution output, providing a revocation window.

C2. Pre-SegWit, transaction malleability allowed third parties (or miners) to modify the txid of the funding transaction without invalidating it. If the funding txid changes, every commitment transaction (which references the funding outpoint) becomes invalid—the entire channel breaks. SegWit fixes this by moving the witness (the malleable part) outside the txid calculation. The funding transaction's txid is stable, so all commitment transactions remain valid. This is why Lightning was not practical before SegWit's activation in August 2017.

B1. In theory, witness data in a commitment transaction could contain an inscription envelope. In practice, this is impractical: commitment transactions are pre-signed by both parties, and the witness data is tightly specified by BOLT 3 (signatures, keys, hash preimages). Adding arbitrary inscription data would require both parties to agree to include it and would increase the transaction's weight, raising fees. Lightning commitment transactions are designed for minimal on-chain footprint, which is the opposite of inscriptions' goal.

B2. Lightning excels for frequent, small payments between parties with established channels: near-zero marginal cost, instant finality, and no on-chain footprint. On-chain batching excels for one-time payments to many recipients: a single transaction with many outputs. Lightning requires channel setup (on-chain funding transaction) and liquidity management; batching requires only one on-chain transaction but no persistent relationship. For recurring payments to the same parties, Lightning is far more efficient. For one-time distributions (e.g., exchange withdrawals), batching is simpler.