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

Sikh Bitcoin · Advanced · Lesson 18 of 21

Lightning channels and HTLCs

Follow conditional payments without assuming trusted routing intermediaries.

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 18 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

  • Describe hash and time conditions conceptually.
  • Explain why channel operation needs current state.

Channels keep an enforceable relationship

Lightning participants exchange updates to channel balances with commitments anchored to Bitcoin. Routed payments connect multiple channels. The protocol uses conditional mechanisms so a forwarding node can link what it pays onward to what it receives. The goal is coordinated completion or failure rather than simply trusting each intermediary to forward money.

Hashes and timeouts coordinate the path

An HTLC combines a hash-based condition with a timeout. Revealing the appropriate preimage can fulfill the payment condition; time constraints provide a recovery path when it is not fulfilled. Timeout differences along a route matter because intermediaries need time to resolve dependent claims. The exact commitment and channel rules belong to the relevant Lightning specification and implementation.

Operational details remain important

A correct protocol is not a substitute for current state, backups, monitoring and fee management. A self-hosted node operator must understand their implementation’s recovery method rather than assuming an on-chain seed restores every channel situation. This lesson deliberately uses a diagram, not a live channel. Draw payer, forwarding node and recipient, then label the information each needs and what happens when a participant becomes unavailable.

Practice on paper

Why should an intermediary’s incoming and outgoing conditions be coordinated rather than independent promises?

Reveal the worked answer

The intermediary needs a way to obtain what it is owed when the onward payment succeeds and to resolve failure within the allowed time. Independent informal promises would reintroduce trust and loss exposure.

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. Are forwarding nodes meant to rely only on a recipient’s verbal promise?

  • Yes
  • No
Reveal answer 1

No. Conditional protocol mechanisms coordinate outcomes.

2. Does an on-chain wallet backup automatically describe every Lightning recovery procedure?

  • Yes
  • No
Reveal answer 2

No. Channel-state and implementation-specific recovery requirements matter.

Take this with you

Understand the condition and the operational responsibility together.

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.