Timechain Wiki

Lightning channels

11 min read

A Lightning channel is a 2-of-2 multisig output on the Bitcoin base layer plus a sequence of off-chain commitment transactions between the two participants. The participants fund the multisig with an opening transaction, then exchange signed-but-unbroadcast commitments redistributing the locked funds as payments accumulate; each new commitment supersedes the prior, and a revocation mechanism hands the cheater's penalty key to the honest party if a stale state is broadcast. Channels close cooperatively (both sign a final settlement; clean and cheap) or by force-close (unilateral broadcast of the latest commitment; expensive and triggers HTLC timeouts). The malleability fix from SegWit upgrade is the load-bearing precondition — without it, chained commitments cannot reliably reference the funding output. Modern features include anchor outputs for fee bumping, dual-funded channels, splicing, and the proposed eltoo / SIGHASH_NOINPUT path that would obviate revocation-and-penalty. Scope here is the channel layer; routing lives in Lightning routing, outsourced monitoring in Watchtowers, the overview in The Lightning Network.

Why this note matters

The channel construction is the foundational mechanism of Lightning. Understanding what a channel is, how its state advances, and how it closes is the necessary precondition for understanding everything else in the Lightning stack: routing depends on channel-by-channel HTLC propagation; watchtowers monitor for malicious force-close; LSPs operate by maintaining many well-capitalized channels.

The construction is also conceptually instructive. It illustrates how Bitcoin’s base-layer primitives (multisig, timelocks, signed-but-unbroadcast transactions) compose to produce a Layer-2 system without requiring custodial trust between participants. The cleverness of the design — and its specific complexity — repays close treatment.

The 2-of-2 multisig funding output

A Lightning channel between Alice and Bob begins with a funding transaction. Alice and Bob each contribute funds to a single 2-of-2 multisig output controlled by both their public keys. Spending this output requires both signatures.

In the original Lightning design, channels were single-funded (only one party provided funds at open). The current standard supports both single-funded and dual-funded channels:

  • Single-funded channels are the historical default. One party funds the channel; the other party’s balance is zero at open. The funder has all outbound liquidity; the non-funder has all inbound liquidity. This is fine for one-directional payment flows but constrains liquidity provision.
  • Dual-funded channels (BOLT specification in progress, with implementation support in CLN and partial support in LND) allow both parties to contribute funds at open. Both participants have non-zero balances and bidirectional liquidity from the start.

The funding output is a P2WSH script (or P2TR script under Taproot Channels, which uses a different commitment construction). The 2-of-2 multisig requires both Alice’s and Bob’s signatures to spend.

Commitment transactions and state advancement

Once the channel is funded, payments between Alice and Bob change channel state by updating the commitment transaction — a transaction that spends the funding output back to Alice and Bob’s individual addresses in some specific proportion. The commitment transaction is signed but not broadcast. As payments accumulate, Alice and Bob exchange new commitment transactions reflecting the updated balance.

A simplified state advancement. The initial commitment transaction reflects the channel’s funding split (e.g., Alice 0.1 BTC, Bob 0 BTC). When Alice sends Bob 0.001 BTC over Lightning:

  1. Alice and Bob both compute the new commitment transaction (Alice 0.099 BTC, Bob 0.001 BTC).
  2. Alice signs Bob’s copy of the new commitment.
  3. Bob signs Alice’s copy of the new commitment.
  4. Both parties exchange revocation keys for the prior commitment transaction (this is the invalidation mechanism, treated below).

At this point, either Alice or Bob can unilaterally broadcast the new commitment transaction. The prior commitment transaction is also still technically valid — neither party has rendered it cryptographically impossible to broadcast — but a special punishment mechanism makes broadcasting it actively dangerous.

The asymmetric commitment construction. Each party holds a slightly different version of the commitment transaction. Alice’s version pays Bob immediately if broadcast, but pays Alice through a timelock that gives Bob a window to challenge if Alice broadcasts an old commitment. Bob’s version is symmetric. This asymmetry is what makes the punishment mechanism possible.

The revocation mechanism

When Alice and Bob create a new commitment transaction, they invalidate the previous one through a revocation-key exchange:

  1. Each party constructs commitment transactions with a punishment path: if a party broadcasts an old commitment, the other party can sweep the broadcaster’s funds with a revealed revocation key.
  2. When advancing to a new commitment, each party reveals the revocation key for the prior commitment to the other party.
  3. After revealing, each party can construct a punishment transaction that sweeps the prior commitment’s funds entirely to the honest party, if the misbehaving party broadcasts the revoked commitment.

The economic consequence. A party who broadcasts an old commitment risks losing the entire channel balance to the counterparty. Honest behavior is the strictly dominant strategy; broadcasting old state is economically suicidal.

The liveness requirement. The punishment mechanism only works if the honest party (or their delegated watchtower; see Watchtowers) observes the misbehaving broadcast in time to construct and broadcast the punishment transaction before the timelock expires. This is the source of Lightning’s “must be online” requirement.

HTLCs as in-flight payment primitive

Single-channel payments between Alice and Bob update the commitment transaction directly. Multi-hop payments require an additional construct: the Hashed Timelock Contract (HTLC).

The HTLC mechanism. An HTLC is an output on the commitment transaction with two spending conditions:

  1. Hash preimage path: the recipient can claim the HTLC by revealing a preimage whose hash matches a publicly committed value.
  2. Timeout path: if the preimage is not revealed within a specified blockheight, the sender can reclaim the HTLC.

For a multi-hop payment, the sender chooses a random preimage and constructs an HTLC at each hop locked by the preimage’s hash. The final recipient knows the preimage (from the invoice) and reveals it to claim; each intermediate hop receives the preimage from its outbound neighbor and uses it to claim from its inbound neighbor. The preimage cascade is the atomicity guarantee.

Per-hop timelock buffer. Each HTLC’s timeout decreases by a buffer at each hop closer to the recipient. This ensures that if the preimage is revealed late along the path, intermediate hops have time to claim their outbound HTLC before their inbound HTLC times out. The cltv-delta buffer is per-hop configurable (typical values: 40-144 blocks per hop).

In-flight commitment-state. While HTLCs are in flight, the commitment transactions for affected channels include the HTLC outputs in addition to the participant balances. When HTLCs resolve (claim or timeout), a new commitment transaction without the resolved HTLC is exchanged.

Channel close — cooperative vs force close

Two close modes:

Cooperative close (mutual close). Both participants agree to close the channel by signing a final settlement transaction that spends the funding output directly to participant addresses without the punishment-and-timeout infrastructure. The settlement transaction is a single base-layer transaction at the prevailing fee rate. Funds are spendable immediately (after on-chain confirmation) by both parties. This is the clean, cheap close path.

Force close (unilateral close). One participant broadcasts the most recent commitment transaction unilaterally. The commitment transaction settles to participant addresses, but with a timelock on the broadcaster’s side (the broadcaster cannot spend their funds for a window that allows the counterparty to challenge if the broadcaster cheated). Force close is more expensive than cooperative close because:

  • The broadcaster pays the full commitment transaction fee (calibrated at channel-open and updated over time).
  • The broadcaster’s funds are timelocked for the relative-time-lock window.
  • In-flight HTLCs must be resolved on-chain rather than off-chain.

Force close is the appropriate response when the counterparty is offline, unresponsive, or attempting malicious behavior. It is functionally a fallback, not a routine close mode.

Anchor outputs and fee-bumping

The original commitment-transaction design used a fixed fee rate calibrated at channel-open. When the broadcaster eventually needed to close the channel, the calibrated fee might be far below the current mempool fee rate, leaving the transaction unconfirmed for extended periods.

Anchor outputs (CLN’s anchor-channels; LND’s anchor-channels) address this by including small dust-value anchor outputs in the commitment transaction that either party can attach to with CPFP (child-pays-for-parent) fee-bumping after broadcast. The commitment-transaction fee can be effectively raised post-broadcast by adding a CPFP transaction.

The replace-by-fee (RBF) approach (Peter Todd’s BIP125) is also used for fee-bumping force-close attempts. Modern Lightning implementations support both CPFP-via-anchors and RBF.

Splicing

Splicing is the protocol-level capability to change a channel’s funding amount (add funds, remove funds) without closing and reopening the channel. Splicing requires a coordinated on-chain transaction that spends the existing funding output and creates a new funding output with the updated balance.

Splicing is supported in BOLT 09’s splicing extension; production support landed in CLN first (2023-2024) and is being added in LND and Eclair. Splicing is the operational answer to many channel-management questions that previously required close-and-reopen: rebalancing inbound liquidity, adding capacity to a heavily-used channel, withdrawing partial channel funds for on-chain use.

Tradeoffs and design choices

The punishment-and-revocation mechanism vs eltoo. The current LN-Penalty (also called Poon-Dryja) construction makes broadcasting old state economically suicidal but requires online monitoring to detect and punish. The proposed eltoo construction (using SIGHASH_NOINPUT or its equivalent) would replace punishment with a simple “newest state always wins” mechanism, obviating watchtowers and allowing safe offline periods. Eltoo requires a soft fork to activate the necessary sighash flag; no concrete activation timeline is published. The tradeoff: current channels work today with the operational complexity; eltoo would be cleaner but is not yet deployed.

Single-funded vs dual-funded defaults. Single-funded channels are simpler and have been the operational default; dual-funded channels are more flexible and better suited for routing-node operations but add protocol complexity. The transition to dual-funded as the default is in progress; the design choice has been pragmatic.

The malleability dependency. The entire commitment-chain construction depends on the funding-transaction’s txid being stable. Pre-SegWit, the malleability vulnerability made this construction fundamentally fragile. The dependency on SegWit-format funding outputs is not optional; it is structural. See SegWit upgrade for the malleability-fix treatment.

Force-close expense and the channel-management economics. Force close is the visible cost of the unilateral-exit capability. The expense is real (commitment-transaction fee + timelock-wait + on-chain HTLC resolution) and discourages casual channel use. The design choice prioritized robust unilateral exit over cheap closing; the tradeoff is the dominant UX friction in self-sovereign Lightning. See Lightning Network operational critiques for the substantive engagement.

Substantive analytical critique of channel-management complexity, force-close economics, and the watchtower-liveness requirement lives in Lightning Network operational critiques.

Open questions for further development

  • Will eltoo activate, and on what timeline? SIGHASH_NOINPUT (or the equivalent SIGHASH_ANYPREVOUT) requires a soft-fork upgrade. The current covenants-debate landscape (see OP_CAT and the covenants programmability debate) includes eltoo-relevant proposals but no consensus activation path is published.
  • What is the right calibration of channel-open fees vs typical close fees? The mismatch between channel-open-time fee calibration and channel-close-time fee market continues to produce force-close-fee problems even with anchor outputs.
  • How widespread will dual-funded channels become as the default? The implementation-by-implementation rollout has been gradual; the operational benefits are clearest for routing nodes and LSPs.
  • What is the right mechanism for splicing-out without on-chain transactions? Splicing is a base-layer operation; some use cases would benefit from off-chain-only balance adjustments that current splicing cannot provide.

Canonical sources for this note

Specifications

  • BOLT 02 — Peer Protocol for Channel Management: github.com/lightning/bolts/blob/master/02-peer-protocol.md
  • BOLT 03 — Bitcoin Transaction and Script Formats: github.com/lightning/bolts/blob/master/03-transactions.md
  • BOLT 09 — Protocol Extensions: github.com/lightning/bolts/blob/master/09-features.md (splicing extension)

Foundational references

  • Mastering the Lightning Network (Antonopoulos, Osuntokun, Pickhardt; O’Reilly 2021) — Chapters 6-9 treat channels, commitments, and HTLCs at depth
  • Joseph Poon and Thaddeus Dryja, “The Bitcoin Lightning Network” (2015 white paper) — the original commitment-and-penalty construction
  • Christian Decker and Roger Wattenhofer, “Duplex Micropayment Channels” (2015) — historical context for the channel-construction lineage

Graph View

Backlinks