Lightning Payment Channels

Payment channels are the fundamental building block of the Lightning Network. They enable off-chain transactions between two parties with on-chain settlement. A payment channel is a 2-of-2 multisig address that locks Bitcoin between two parties. The parties can update the channel balance off-chain without broadcasting to the Bitcoin network. Key properties:

2-of-2 Multisig: Both parties must sign to spend
Off-Chain Updates: Balance changes happen instantly without blockchain transactions
On-Chain Settlement: Final state broadcast to Bitcoin when closing
Bidirectional: Payments can flow in both directions

Channel Lifecycle

1. Channel Opening

Funding Transaction:

Creates 2-of-2 multisig output
Locks Bitcoin from one or both parties
Broadcast to Bitcoin network
Wait for confirmation (typically 3-6 blocks)

Opening Process:
1. Alice and Bob agree to open channel
2. Create funding transaction (2-of-2 multisig)
3. Exchange initial commitment transactions
4. Broadcast funding transaction
5. Wait for confirmation
6. Channel becomes active

2. Channel Active

Off-Chain Updates:

Parties exchange signed commitment transactions
Each update reflects new balance distribution
No blockchain transaction needed
Instant and free

Update Process:
1. Alice wants to send 10,000 sats to Bob
2. Create new commitment transaction:
   - Old: Alice 50,000, Bob 50,000
   - New: Alice 40,000, Bob 60,000
3. Exchange signatures on new commitments
4. Exchange revocation secrets for old state
5. Balance updated (off-chain)

3. Channel Closing

Closing Options:

Type	Description	Speed	Cost
Cooperative	Both parties agree	Fast	Low
Force Close	Unilateral broadcast	Slow (timelock)	Higher
Breach/Penalty	Punish cheating attempt	Varies	Attacker loses all

Commitment Transactions

Each commitment transaction represents the current channel state:

Input: Funding transaction output (2-of-2 multisig)
Outputs:
  - Alice's balance (to_local or to_remote)
  - Bob's balance (to_local or to_remote)
  - Any pending HTLCs

Asymmetric Commitments

Each party holds a different version of the commitment transaction:

Alice's version: Her output has a timelock (revocable)
Bob's version: His output has a timelock (revocable)

This asymmetry enables the revocation mechanism.

Revocation Mechanism

When the channel state updates:

Create new commitment transactions
Exchange signatures
Exchange revocation secrets for old state
Old commitments become toxic (broadcasting = penalty)

Channel Balance Queries

Channel Capacity and Liquidity

Total Capacity

Channel capacity equals the funding amount:

Alice funds: 100,000 sats
Bob funds: 0 sats (single-funded)
Total capacity: 100,000 sats

Liquidity Direction

For routing payments, liquidity must exist in the payment direction:

Direction	Requirement
Alice → Bob	Alice needs outbound liquidity
Bob → Alice	Bob needs outbound liquidity

Inbound vs Outbound Liquidity

Outbound: Funds you can send (your channel balance)
Inbound: Funds you can receive (peer's channel balance)

New nodes often struggle with inbound liquidity since opening channels only provides outbound.

Liquidity Management

To receive payments or route effectively, you need inbound liquidity. To send or route in the other direction, you need outbound liquidity. Common ways to adjust it:

Circular rebalancing: Pay yourself (e.g., between your own channels or via a loop) to move liquidity from one side to the other.
Submarine swaps / liquidity marketplaces: Use a service to swap on-chain BTC for Lightning inbound (or the reverse), or to buy/sell channel capacity.
Liquidity ads (e.g., BOLT 12 or implementation-specific): Some nodes advertise that they want to buy or sell inbound or outbound liquidity; you can open channels or splice with them.
Splicing: Add or remove on-chain capacity to an existing channel to rebalance.

Channel Splicing

Splicing (as specified in the Lightning BOLT process) allows you to add or remove on-chain capacity to or from an existing channel without closing it. That way you can top up or withdraw liquidity in a single transaction while keeping the same channel and HTLC state.

How It Works

Splice-in: You add an extra input (and possibly output) to a new funding transaction that spends the existing 2-of-2 multisig UTXO and creates a new 2-of-2 with a larger (or smaller) amount. Both parties sign; the channel capacity is updated on confirmation.
Splice-out: Part of the channel balance is sent to an address (yours or your peer’s) in the splice transaction, reducing the new 2-of-2 amount.

Splicing is dual-funded in the sense that the splice transaction is cooperatively built; typically it also uses anchor outputs or similar so fee bumping works.

Why Use Splicing

Add liquidity: Get more inbound or outbound without opening a new channel and without on-chain round-trips for a full close+reopen.
Withdraw liquidity: Reduce channel capacity and free BTC on-chain without closing the channel and losing your routing relationship.

Support for splicing varies by implementation (e.g., Core Lightning, LDK); check your node’s documentation.

Channel Types

Public Channels

Announced to the network gossip
Appear in the public channel graph
Can route payments for others
Required for earning routing fees

Private (Unannounced) Channels

Not broadcast to the network
Only known to the two parties
Can still be used with route hints
Better privacy for end users

Channel Security

Revocation Keys

Each commitment state has an associated revocation key. If a party broadcasts an old state, the counterparty can:

Detect the old commitment on-chain
Use the revocation secret to construct a penalty transaction
Claim all funds in the channel

Timelocks

Force-closed channels have timelocks (typically 144-2016 blocks) that give the counterparty time to detect and punish cheating attempts.

Watchtowers

Third-party services that monitor the blockchain for breach attempts when your node is offline. See Watchtowers for details.

Common Issues

Unbalanced Channels

Problem: All funds on one side prevents bidirectional payments.

Solutions:

Circular rebalancing (pay yourself through the network)
Submarine swaps (on-chain ↔ off-chain)
Open additional channels
Use liquidity marketplaces

Stuck Channels

Problem: Cannot cooperatively close (peer offline/unresponsive).

Solution: Force close and wait for timelock expiry.

Insufficient Capacity

Problem: Payment larger than available channel balance.