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:
- 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.
- 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.
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
Related chapters
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)
- BOLT #2 - Peer Protocol for Channel Management (the funder opens and funds a v1 channel; v2 adds dual funding; mutual close; splicing replaces the funding transaction and sets a new channel capacity)
- BOLT #3 - Bitcoin Transaction and Script Formats (2-of-2 funding output, commitment transactions, revocation keys, to_self_delay for penalty transactions)
- BOLT #5 - On-chain Transaction Handling (unilateral close; on a revoked commitment the other node can claim all the channel's funds)
- Poon and Dryja - The Bitcoin Lightning Network paper: if both parties cooperate, a channel can remain open indefinitely (2016)
- LND docs - Private altruist watchtowers (watch for a breach and publish the penalty transaction while the user is offline)
- Lightning Labs docs - Managing liquidity: --local-amt sets a channel's full capacity; Loop refills or empties channels without opening new ones
- Lightning Labs docs - Loop: submarine swaps that empty out or refill a channel
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)
Published . Revised . Two corrections logged for this page.
Edit this page on GitHub