How a Lightning channel works

A changing allocation, backed by an exit

Imagine two participants, Asha and Ben, with 100,000 sats allocated to a channel. In a deliberately simplified starting state, Asha’s side has 80,000 and Ben’s has 20,000. After Asha pays Ben 10,000 through that channel, the allocation becomes 70,000 and 30,000.

The total has not grown. What changed is how the channel’s value is allocated between the participants. A successful update is not the same thing as placing a new ordinary payment transaction in a new Bitcoin block.

Why should either participant accept an off-chain update? The channel protocol provides commitments and paths to enforce claims on-chain. A channel is not just a shared spreadsheet whose balances work only while both people are friendly.

Funding, updating, closing

Funding establishes the on-chain basis of the channel. Updates revise the participants’ enforceable states under the protocol. Closing uses on-chain transactions to resolve the channel’s value, cooperatively or through unilateral procedures.

These phases are connected but distinct. Ordinary off-chain payments do not remove the need to handle on-chain fees and confirmation when the channel opens or closes. Nor does a fast successful payment imply that every possible channel exit completes immediately.

The balance diagram deliberately omits those costs so that the allocation is easy to follow. Its 100,000 sats are a teaching capacity, not a serialized funding and commitment transaction set.

Old states need a protocol response

If a participant could freely enforce any favorable old allocation, simply exchanging updated balances would be unsafe. The established Lightning commitment design uses mechanisms including revocation and delayed spending paths to make old-state publication contestable under the relevant conditions.

That statement has operational consequences. Participants or services acting for them need appropriate monitoring and recovery behavior. Channel state is more than a reusable address and key. Exact transaction forms and constraints depend on the negotiated channel type and implementation.

Lightning also routes payments across channels. A route does not pool every channel into one giant balance. Each hop has directional constraints and conditional payment machinery. Our two-party example isolates the local allocation question before introducing route finding and HTLC details.

Avoid two opposite mistakes: thinking Lightning payments are merely unsecured promises, and thinking the on-chain basis makes availability, backups, or liquidity irrelevant. The protocol provides enforcement tools, while using them reliably remains part of operating the system.

Keep a state ledger on paper

Begin with (Asha: 80,000, Ben: 20,000). Record these completed fictional transfers in order:

1. Asha pays Ben 10,000 → (70,000, 30,000).
2. Ben pays Asha 5,000 → (75,000, 25,000).
3. Asha tries to pay Ben 80,000 → reject under the simplified available-balance rule.

The rejected attempt must not create (−5,000, 105,000). Keeping totals constant is necessary but insufficient: neither balance may become negative.

For the deeper exercise, mark which events would require an on-chain transaction in the introductory model: funding, a completed off-chain update, and final close. Expected answer: funding and close have on-chain roles; each successful channel update does not require its own new block. This is not a complete trace of all possible on-chain resolution events.