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. Both parties lock funds into a shared 2-of-2 multisig on-chain output (the funding transaction), and from there they can exchange unlimited off-chain payments by signing successive commitment transactions that update the channel's balance allocation.
How a channel works, end to end:
- Opening. Alice and Bob both contribute (or one contributes, depending on the protocol variant) to a 2-of-2 multisig. The funding transaction goes on-chain and confirms.
- 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.
- 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.
- 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. In practice, attempted cheating is extremely rare.
A few practical realities:
- Inactive channels expose nothing. A channel that hasn't been updated in months still works fine. 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 fixed at open time. A channel funded with 0.05 BTC can route up to 0.05 BTC; rebalancing (via submarine-swap services like Loop In/Out) or splicing is required for more.
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
External references (3)
Related terms (26)
- Atomic Multi-Path Payment (AMP)
- Audiobook Model (Lightning)
- Autopilot (Lightning)
- BOLT
- BOLT 11
- Bridge Node (Lightning)
- Churn (Lightning)
- Core Lightning (c-lightning)
- Custodial Lightning Wallet
- Eltoo
- Escrowed Lightning Channel
- Fraudulent Channel Close
- HTLC (Hashed Time-Locked Contract)
- HTLC Invoice
- HTLC Preimage Manager
- Inactive Channel
- Lightning Channel Capacity
- Lightning Channel Splicing
- Lightning Network
- Lightning Network Daemon (lnd)
- Lightning Node
- Lightning Routing
- Loop In/Out
- Payment Channel
- Rescue Transaction
- Wumbo Channels (Lightning)