Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu

Sikh Bitcoin · Advanced · Lesson 19 of 21

Lightning liquidity has direction

Capacity is not the same as the ability to receive.

About 14 minutes with practice. You only need something to take notes with. No real wallet details or payments are part of this lesson.

Course contents · Lesson 19 of 21
  1. Read the whitepaper as an argument
  2. Hashes and Merkle commitments
  3. UTXOs, change and accounting
  4. Scripts describe spending conditions
  5. Signatures and what they authorize
  6. Block headers and the chain of work
  7. Difficulty, hashrate and noisy observations
  8. Issuance, fees and incentives
  9. Mempools and policy are not consensus
  10. Fee changes: RBF and CPFP
  11. SegWit and transaction weight
  12. Taproot and Schnorr: useful, not magical
  13. HD wallets and derivation paths
  14. PSBT: separate construction from signing
  15. Descriptors make a wallet policy portable
  16. Full nodes, pruning and verification
  17. Reorganizations and lightweight evidence
  18. Lightning channels and HTLCs
  19. Lightning liquidity has direction
  20. Soft forks, proposals and human coordination
  21. Capstone: trace a payment end to end

What you will learn

  • Distinguish inbound and outbound capacity conceptually.
  • Explain why a route may fail despite visible channels.

Balances determine direction

A channel’s total capacity describes value committed to it, but the distribution of balances affects what can move in each direction. A node can have channels and still lack sufficient ability to receive a particular payment. Looking only at the capacity headline omits the practical direction of available liquidity.

A route is a set of constraints

The sender needs a usable path through channels whose participants are available and able to forward the amount. Public topology does not reveal every current balance or operational condition. Attempts can fail and alternative routes may be tried. Small successful payments therefore do not prove that an arbitrary larger payment will work at the same time.

Treat liquidity services as services

An operator may consider channels, liquidity providers or other arrangements, each with fees and assumptions. This lesson does not recommend a provider or ask for a channel opening. A comparison should describe costs, custody, uptime expectations, limits and recovery behavior. For a community checkout, communicate a failed attempt honestly and offer a verified alternative without pressuring the buyer to accept unfamiliar infrastructure.

Practice on paper

A fictional node has a channel of 100,000 sats, with almost all spendable balance on its own side. Why might an incoming 60,000-sat payment still fail?

Reveal the worked answer

Total capacity does not establish inbound liquidity. The remote side and the rest of the route must be able to carry the incoming payment, subject to channel constraints and current availability.

Check your understanding

Choose an answer in your head or on paper, then reveal the explanation. Retry whenever you like. Answers are not submitted or scored; completion marks are your own learning notes.

1. Does large total channel capacity guarantee any incoming payment succeeds?

  • Yes
  • No
Reveal answer 1

No. Direction and route conditions matter.

2. Does one successful small payment prove unlimited capacity?

  • Yes
  • No
Reveal answer 2

No. Amount and timing change the constraints.

Take this with you

Measure the direction and usable route, not only total capacity.

Your learning, at your pace

Read every lesson freely. Optional progress tracking needs JavaScript and browser storage; it does not require an account or wallet.