BitcoinMachine
TERM_DEF // LIGHTNING_NETWORK / CHANNEL_STATE_ADVANCEMENT
CHANNEL STATE
ADVANCEMENT
Channel State Advancement. Updating channel balances by signing new commitment txs and exchanging revocation secrets.

This page sits in the Lightning Network section — Off-chain payment channels and routed micropayments built on top of Bitcoin. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_CHANNEL_STATE_ADVANCEMENT_IS
Channel State Advancement — at a glance
LIGHTNING NETWORK
Channel State Advancement is part of the CHANNEL STATE sub-area of the Lightning Network. The current bilateral commitment between two channel participants — a pair of signed transactions reflecting their balances. Updating channel balances by signing new commitment txs and exchanging revocation secrets.
Why it exists
DESIGN
Bitcoin's base layer settles a few hundred thousand transactions per day — far fewer than a global payment network would need. Lightning solves the scaling problem by keeping most payments off-chain in two-party channels secured by the base layer, with the ability to settle on-chain at any time. Payments inside the network are routed atomically via HTLCs (Hash-Time-Locked Contracts), so a sender pays a receiver many hops away without trusting any intermediate.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
Two parties open a channel by locking BTC into a 2-of-2 multisig output on-chain. They then update the channel state off-chain by exchanging signed transactions — each new state revokes the previous one with a punishment mechanism. To pay someone far away, the sender constructs an HTLC payment that hops through several channels; each hop is cryptographically bound to the same preimage, so all hops succeed or none do.
1. Alice and Bob open a channel: 2-of-2 multisig funding tx on-chain, agreed initial state with their balances. 2. Alice pays Bob 100 sats → both sign a new state with the updated balances (state #2), revoking state #1. 3. Repeat: thousands of payments back and forth, all off-chain, instant, fees in millisats. 4. To pay Carol (no direct channel), Alice routes through Bob: HTLC #1 Alice→Bob, HTLC #2 Bob→Carol, both locked to the same preimage hash. 5. Carol reveals the preimage to claim from Bob → Bob uses it to claim from Alice. Atomic, trustless, all-or-nothing. 6. At any time either party can close the channel by broadcasting the latest signed state on-chain — the network settles to base-layer Bitcoin.
WORKED_EXAMPLE
Channel State Advancement — CHANNEL STATE
EXAMPLE
state #N: each party holds: • their counterparty's signature on the commitment tx • the revocation secret for state #N-1 (so they can punish if the other broadcasts old state) State transitions: state #N → state #N+1 happens off-chain via commit_sig + revoke_and_ack reverting to old state on-chain → counterparty publishes a justice tx within the timelock
KEY_PROPERTIES
OFF-CHAIN
Updates happen between two parties only. The base chain settles disputes if either party tries to cheat.
TRUST-MINIMISED
Each state revokes the previous one with a penalty mechanism; cheating loses you the entire channel balance.
INSTANT
~100–500 ms end-to-end, even across many hops. Compared to 10-minute on-chain confirmations, Lightning feels like a card payment.
PAY-TO-INVOICE
Senders pay BOLT-11 invoices: a destination, amount, preimage hash, and a route hint. The receiver can pre-commit to the payment.
COMMON_PITFALLS
Things that catch people out
PITFALLS
  • Channels need liquidity/">inbound liquidity to receive payments. New nodes often struggle to receive until they swap or pay an LSP for capacity.
  • Force-closes spam the on-chain mempool with extra transactions and incur larger fees than cooperative closes.
  • Routing fails silently — many implementations retry with different paths, but a payment can simply not find a route at high volumes.
  • A watchtower is needed if you go offline for long periods — without one, your counterparty could cheat with an old state.
RELATED_CONCEPTS
Other terms from Lightning Network — click any to read its page:
Lightning Network Payment Channel Channel Open Transaction Channel Close Transaction Cooperative Close Force Close Commitment Transaction Revocation Key
TERMINOLOGY_INDEX
TERMINOLOGY
Channel State Advancement
Updating channel balances by signing new commitment txs and exchanging revocation secrets.
Lightning Network
A network of payment channels enabling instant, cheap Bitcoin payments off-chain.
Payment Channel
A 2-of-2 multisig output funded by both parties; balance is rewritten off-chain via signed commitment txs.
Channel Open Transaction
The transaction/">funding transaction creating the channel's on-chain anchor UTXO.
Channel Close Transaction
Any on-chain transaction spending the channel UTXO, ending the channel.
Cooperative Close
Both parties sign a fresh tx splitting the current balance; lowest-fee close path.
Force Close
One party broadcasts the latest commitment tx unilaterally; pays higher fees and triggers timelocks.
Commitment Transaction
A pre-signed off-chain tx representing the current channel balance; spendable but penalized if old.