Channels are not accounts

A channel is a 2-of-2 multisig output on the bitcoin blockchain, funded once, plus a pair of signed transactions that neither side has published. That is the whole mechanism. Everything that feels strange about Lightning follows from it.

The strangeness is worth naming immediately, because it is the thing that makes newcomers think their node is broken:

A channel with money in it can be unable to send, unable to receive, or both. Which of those is true depends not on how much is in the channel but on where in the channel it sits.

§1Capacity is fixed; the balance moves

When a channel opens, one or both parties commit funds to the multisig output. That total is the channel’s capacity, and it does not change for the channel’s lifetime. There is no top-up. Adding funds means closing the channel and opening another, or opening a second one.

What does change is the split. At any moment the capacity is divided between your side — your local balance, which is what you can send — and the other side’s, your remote balance, which is the room you have to receive. The two always sum to the capacity, minus a small amount held back.

A payment does not move coins anywhere. It moves the line.

Three things follow from this, and each one surprises somebody every day.

You cannot receive into an empty remote side. If you funded the channel alone, your remote balance starts at zero. The channel is full of your money and it cannot accept a single satoshi until you have spent some of it outward. A brand-new node that opens five channels and then wonders why nobody can pay it has met this.

You cannot send more than one channel holds. A payment traverses a channel; it is not split across your channels unless your node deliberately splits it, and even then each part is bounded by the channel it takes. Five channels of one million satoshis are not a five-million-satoshi sending limit.

Both sides can be stuck at once. A channel drained to your side cannot receive; a channel drained away from you cannot send. Two channels in opposite states are, between them, a node that appears well funded and can do very little.

§2What the commitment transaction actually holds

The balances are not a ledger entry. Each side holds a commitment transaction, and the reason that works at all is worth taking from the source directly:

If someone holds a presigned bitcoin transaction that spends a 2-of-2 multisig output and gives them the exclusive ability to spend that bitcoin, they effectively own it — even if they never broadcast the transaction.

That is the whole trick. A commitment transaction is signed, held, and not published; it spends the funding output and pays each party their current balance. Making a payment means both sides sign a new pair reflecting the new split, and then revoke the old pair.

The revocation is what makes it safe. If a channel partner publishes a commitment transaction that has been revoked — an old state, one that paid them more — the protocol gives you a window in which you can take the entire channel balance as a penalty. That asymmetry is the whole security model, and it is why an old backup of a Lightning node is dangerous in a way an old backup of a wallet is not.

This is also why the two balances are not quite the capacity. Each side holds back a channel reserve, conventionally 1% of capacity, which it can never spend.1 A side with nothing at stake has nothing to lose by cheating, so the protocol makes sure neither side ever reaches zero.

The reserve is small and it is a nuisance at exactly the wrong moment. A rebalancing attempt sized to move “the whole balance” will fail against it, and the error will not say so in those words.

§3Reading a real channel

Every node keeps a view of every public channel, built from gossip. Here is one, taken from this operator’s node when the page was built — not invented, and not this node’s own:

Four things in it are worth reading together, and the fourth is the lesson.

The capacity is exactly what was committed to the funding output when the channel opened. It will be that number until the channel closes.

The two fee policies differ, and that is normal: each side sets what it charges to forward away from itself, so a channel between a patient node and an impatient one looks precisely like this.

The maximum HTLC is not a round number. It is 99% of capacity — the channel reserve, made visible. Each side holds back 1% it can never spend,1 so the largest payment the channel will accept is bounded by it. The reserve is not a footnote in the specification; it is sitting in the public data.

And the fourth: there is no balance anywhere in it. Gossip carries capacity, policy and limits. It does not carry the split, because the split is not public — it is known only to the two parties, and it changes every time a payment crosses.

That is why the three moments in Fig 1 are a worked example rather than a measurement. Nobody outside those two nodes can watch the line move. The operator of this node can run lncli listchannels and see their own, which is the one place the split appears:

$ lncli listchannels
{
    "channels":  []
}

Empty, and honestly so: the node is synced and running but has never opened a channel. When it does, this page will show a real split with its own as-of date. Until then it shows what is genuinely observable and says which is which — a fabricated listchannels row presented as real would undermine every measured figure on this site.

§4Why this shapes everything after it

Every later topic in this course is a consequence of the two-sided constraint.

Routing exists because your channel to one peer cannot pay someone you have no channel with, so a payment is a chain of these constraints, each of which must hold simultaneously. Rebalancing exists because the distribution drifts as you use the node, and moving the line back costs money. Fee policy exists because forwarding a payment consumes your outbound liquidity on one side and replenishes it on the other, which is a service with a cost and therefore a price.

An operator who has internalised “channels are not accounts” can predict most Lightning failures without reading the error. An operator who has not will keep meeting the same wall from different directions.

Which is the honest summary of this lesson: the mechanism is simple, and almost nothing about the experience of running a node makes sense until it is.