The Lightning Network scales Bitcoin payments by moving most transfers off-chain into bilateral payment channels. Users update balances locally and only settle on-chain when opening or closing channels.
Complete Step 1 // Required reading in the study plan above, then continue here. Prefer completing the Bitcoin roadmap first — Lightning assumes UTXOs, fees, scripts/timelocks, and regtest comfort.
Step 2 — Core idea: channels, HTLCs, invoices
On-chain block space is scarce. Instant coffee payments should not compete with large settlements for the same limited capacity.
Analogy: A channel is a bar tab between two friends. You keep a running tally (signed IOUs). When you are done, you settle once at the bank (on-chain). Routing asks mutual friends to help settle tabs across a network of tabs.
| Concept | Meaning |
|---|---|
| Payment channel | Two parties lock bitcoin; update balances with signed commitments off-chain |
| HTLC | Hash Time Locked Contract — multi-hop payments complete atomically or unwind |
| Invoice | BOLT11 payment request (amount, expiry, routing hints) |
Loading diagram…
Loading diagram…
Done when: You can explain why Lightning still needs on-chain Bitcoin for open/close.
Step 3 — Try it: map + local peek (lab)
Open Amboss (or another explorer) and note one public fact (capacity, channel count). Then check Polar/regtest: nodes up, or write your plan to install Polar before channel labs.
Common mistakes
- Treating Lightning as a separate coin
- Assuming every payment is free and instant with no liquidity constraints
- Skipping Bitcoin foundations and jumping straight to mainnet nodes
Done when: Lab evidence (explorer note + local/Polar status + source link) is complete.
Next lesson
BOLTs & Spec Landscape — how LND, CLN, and LDK stay interoperable.