Why can a Lightning node send but not receive?

Your balance is only one side of the story

Your node shows 80,000 sats on its side of a channel. The peer’s side holds 20,000. Together they make 100,000 sats of capacity. A customer now tries to pay you 50,000 sats through that direct channel.

It is tempting to say, “There is plenty of room; the channel is worth 100,000.” But the incoming payment has to move value from the peer’s side to yours. In our simplified model, only 20,000 is available on that side. The attempted 50,000 cannot be transferred.

We call your side local and the peer’s side remote. Under this model, local balance is your sending capacity, while remote balance is your receiving capacity. These are directional quantities, not two separate piles that you own.

Sending creates room to receive

Send 10,000 sats through the channel. The split changes from 80,000/20,000 to 70,000/30,000. You can now receive up to 30,000 in this model, because more of the fixed total sits on the remote side.

Receiving shifts the split back the other way. Neither action automatically increases total capacity. It changes which direction can carry the next payment.

Before using the controls, predict whether sending 30,000 from the initial state makes a later 50,000 receipt possible. Then test the sequence. The first action leaves 50,000 on each side; the second uses the entire remote side in the simplified model.

The model’s answer is intentionally bounded

Real channel balances are constrained by more than the two displayed numbers. Reserves, commitment and routing fees, pending HTLCs, minimum and maximum payment constraints, and channel availability can reduce usable liquidity. Lightning commonly accounts internally in millisatoshis; this teaching model uses whole sats.

A multi-hop route adds another distinction: local receiving capacity is not proof of a working route from every sender. Other channels along the path need enough capacity in the appropriate directions, and their participants must be available under the payment’s conditions.

The diagram therefore answers a precise question: Does this one idealized direct channel have enough value on the side from which the requested transfer starts? It does not diagnose a live node or recommend a liquidity purchase.

A failed transfer must leave state unchanged

An attempted 50,000 receipt from the initial 80,000/20,000 state is rejected. The interface tells you which side was short. Both balances remain unchanged, so a failed experiment cannot quietly manufacture liquidity.

Reset restores the known initial state. Use it between predictions so you can tell whether an outcome comes from your new input or a prior successful transfer.

Write the invariant before the renderer

The two core checks are simple:

local + remote = 100,000
local >= 0 and remote >= 0

Sending n subtracts n from local and adds it to remote. Receiving does the reverse. A transfer is allowed only if n is a positive whole number and the source side has at least n.

Try these cases from the initial state:

Action	Expected result
Receive 50,000	Reject; remain 80,000/20,000
Send 10,000	Accept; become 70,000/30,000
Receive 30,000 after that send	Accept; become 100,000/0
Receive 1 more	Reject; remain 100,000/0

Reaching a zero balance is allowed by the teaching arithmetic, not a claim about a real channel’s reserves. A useful unit test checks both conservation and unchanged state after rejection. Testing only the total would miss invalid negative balances.