Channels are anchored to Bitcoin
A Lightning channel begins with a Bitcoin transaction that commits funds to a shared spending arrangement. Participants can then update their channel balance without publishing every update.
A later closing transaction settles the final state on Bitcoin. Cryptographic enforcement prevents a participant from safely claiming an outdated balance.
Payments can cross several channels
A sender does not need a direct channel with every recipient. Lightning nodes find a route through connected channels and use conditional payments so the route succeeds or fails atomically.
Routing nodes may charge fees. Onion-style routing limits what each intermediary learns, although Lightning is not perfectly private.
Liquidity determines capacity
Channel capacity is divided between its two sides. Outbound liquidity supports sending, while inbound liquidity supports receiving.
A channel can have enough total capacity but insufficient balance in the required direction. Operating a node therefore includes liquidity, backup and availability responsibilities.
Lightning channels
Lock once, update off-chain, settle when needed
Follow a channel from its on-chain funding output through signed balance updates to cooperative or unilateral close.
Fund
Participants create an on-chain funding output. Channel capacity cannot exceed the bitcoin committed to it.
Key vocabulary
Terms worth knowing
- Payment channel
- A shared on-chain output whose allocation can be updated off-chain under agreed rules.
- HTLC
- A conditional payment construction using a hash and timeout to support routed payments.
- Liquidity
- Channel capacity positioned in the direction needed to send or receive a payment.
Worked example
A routed payment fails despite enough wallet balance
A learner has Lightning funds, but the available routes do not have enough correctly directed liquidity for the payment amount.
- 1Separate total balance from outbound liquidity
- 2Check payment amount and invoice expiry
- 3Allow the wallet to retry alternate routes
- 4Consider channel or service constraints before opening new channels
Lightning payments depend on channel state and route liquidity, not only a displayed total balance.
Common misconceptions
What learners often get wrong
Misconception
Lightning removes the need for the Bitcoin blockchain.
More accurate
Channels are opened and closed with Bitcoin transactions, and their security model ultimately relies on enforceable on-chain outcomes.
Misconception
Every Lightning wallet has the same custody model.
More accurate
Some users control keys and channels; others rely on a custodian. The interface alone does not reveal the trust model.
Try it yourself
Map a three-hop Lightning payment.
- Name sender, two routing nodes and receiver
- Mark the direction of liquidity on each channel
- Identify what prevents an intermediary from changing the final amount
- Explain what could cause the route to fail
Use fictional values and public information only. Never enter seed words, private keys or other wallet secrets into a learning exercise.
Key takeaways
- Lightning channels are anchored by Bitcoin transactions.
- Payments can route without a direct sender-recipient channel.
- Liquidity direction affects whether value can be sent or received.
- Lightning introduces additional operational trade-offs.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
Why can a channel with enough total capacity still fail to route a payment?
References
