LearnBitcoin

Glossary

Lightning Channel

A two-party off-chain payment channel on the Lightning Network, allowing rapid, low-fee transactions prior to on-chain settlement.

A Lightning channel is a payment pipe between two parties on the Lightning Network. Bitcoin is locked into a shared 2-of-2 multisig on-chain output (the funding transaction), and from there the two parties can exchange unlimited off-chain payments by signing successive commitment transactions that update the channel's balance allocation. Usually the side that opens the channel puts up all of that bitcoin.

How a channel works, end to end:

  1. Opening. Alice funds a 2-of-2 multisig that needs both her signature and Bob's. (With dual funding, a newer option, Bob can add funds too.) The funding transaction goes on-chain and confirms.
  2. Transacting. To pay Bob, Alice constructs a new commitment transaction that allocates less of the channel's balance to herself and more to Bob, signs it, and shares it. Bob signs and stores it too. The old commitment is invalidated using a revocation key. The new state is now the "current truth" between them, even though nothing is on-chain.
  3. Many updates. They can repeat this back and forth, in either direction, thousands of times. Each update is just a signed transaction sitting in their wallets.
  4. Closing. Either party can broadcast the latest commitment to the chain at any time. The commitment itself is a kind of rescue transaction - pre-signed at every state update, ready to broadcast if the channel partner goes offline or misbehaves. The funds settle according to the latest state. Cooperative close is signed by both and clean. Force close is unilateral and includes a delay window during which the other party can punish a cheating counterparty (broadcasting an outdated state) using the revocation key.

The cheating protection is what makes Lightning trustless. If Bob ever tries to broadcast an old commitment that favored him more, Alice can use the revocation key to claim all of the channel's funds, including Bob's. The mechanism is mutually assured destruction at the channel level.

A few practical realities:

  • Channels don't expire. As long as neither side closes it, a channel can stay open indefinitely. One that hasn't been used in months still works, and you can come back to it.
  • You must watch for cheating. If you're offline when your counterparty cheats, you miss the dispute window. Watchtower services exist for this.
  • Capacity is set by the funding transaction. A channel funded with 0.05 BTC holds 0.05 BTC in total, split between the two sides. Swap services like Loop In/Out shift that split, refilling or emptying one side, but the total stays the same. Only splicing, which replaces the funding transaction with a new one, changes a channel's capacity. The other way to get more room is to open another channel.

See Lightning Network for the network-level view and HTLC routing.

Key takeaways

  • Locks BTC in a 2-of-2 multi-sig address for off-chain transfers
  • Allows near-instant, fee-efficient payments
  • Eventually settles on-chain when the channel is closed

Corrected

  • Was: The entry said a channel's capacity is fixed at open time and that rebalancing through swap services like Loop In/Out, or splicing, is required for more.

    Now: The funding transaction sets a channel's capacity, split between the two sides. Swap services like Loop In/Out shift that split, refilling or emptying one side, but the total stays the same. Only splicing, which replaces the funding transaction, changes a channel's capacity. Details

  • Was: The entry opened by saying both parties lock funds into a channel's shared output, and its walkthrough mentioned funding by one side only as a variant.

    Now: Usually the side that opens a channel puts up all of the bitcoin. A newer option, dual funding, lets the other side add funds too. Details

Sources (7)

External references (3)

Related terms (26)

Published . Revised . Two corrections logged for this page.

Edit this page on GitHub