Feedback
Sign in./start

Site navigation

Theme

Learn

  • Roadmaps

Build

  • Projects
  • Developer Tools

Contribute

  • Open Source Projects
  • Issues
  • Reviews
  • First Contribution
  • BountiesSoon
  • Feedback

Prove

  • Builders

Ecosystem

  • Partners
  • Get Funded↗
  • HackathonsSoon
Sign in./start-building

Become an Open Source Builder. Learn. Build. Contribute. Prove.

Feedback welcome — open a GitHub issue.

Learn

RoadmapsStart Building

Build

ProjectsDeveloper Tools

Contribute

Open Source ProjectsIssuesReviewsFirst ContributionSupportFeedback

Prove

Builders Directory

Account

Sign in

Legal

PrivacyTermsCredits

© 2026 Pull // code MIT · curriculum CC BY-SA 4.0

PrivacyTermsCredits

lesson // lightning

Lightning Overview

Understand how payment channels enable instant, low-fee Bitcoin transfers.

intermediate4 days

Public lesson — sign in to track progress on this roadmap.

./sign-in

On this page

Learning objectives

  • Explain why Lightning exists and what problem it solves
  • Describe channels, HTLCs, and invoices at a high level
  • Connect Lightning concepts to prior Bitcoin roadmap knowledge

study // plan

Lessons are primers. Start with Step 1 (required reading) when present, then follow the numbered steps in the article. Depth comes from primary sources, labs, reflection, and evidence.

Research on Bitcoin Search
Lightning Networkpayment channelsHTLCLightning invoice

Step 1 // Required reading

Complete these before the numbered steps in the lesson body. Links are listed here once — not repeated below.

  • bookMastering the Lightning Network

    Ch. 1: Introduction to Lightning

Reflection prompts

  1. Explain Lightning Overview to a teammate without jargon - what problem does it solve?
  2. What would break in production if you misunderstood Lightning Overview?
  3. Which BOLT (or implementation doc) is the source of truth for this topic, and what did you verify there?

Lab // Network map + local peek

Complete Steps 2–3. Skim Amboss (or similar) for one public channel snapshot, then on Polar/regtest list your local nodes or note that you will stand up Polar before channel labs.

evidence required

  • ·Note or screenshot from Amboss (or explorer) of one node/channel fact
  • ·Polar screenshot or CLI note of your local lab status (or planned setup)
  • ·Link to Mastering Lightning Ch. 1 section you used
  1. 01

    Worked mental model

    Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit the Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

  2. 02

    Hands-on habit

    Every protocol idea should be paired with one local experiment. That habit turns reading into builder instinct.

    1. Reproduce the happy path on regtest (or Polar for Lightning)
    2. Break it on purpose (wrong fee, expired invoice, offline peer)
    3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)
  3. 03

    Glossary check

    Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

  4. 04

    Resource order

    Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

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.

ConceptMeaning
Payment channelTwo parties lock bitcoin; update balances with signed commitments off-chain
HTLCHash Time Locked Contract — multi-hop payments complete atomically or unwind
InvoiceBOLT11 payment request (amount, expiry, routing hints)

Loading diagram…

Total capacity is fixed until you splice or close; payments slide the balance boundary.

Loading diagram…

Lightning hops across channels; Bitcoin settles channel open/close.

Channels are bilateral

A channel exists between two nodes. Routing stitches channels into a network so payments can cross multiple peers.

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.

further reading

  • bookMastering the Lightning Network

    Ch. 3: How the Lightning Network Works

  • articleLightning Network Paper
  • toolAmboss Explorer

progress // sign in

Reading is public. Sign in to mark lessons complete, sync across devices, and unlock your roadmap.

./sign-in-to-track

discussion

Discussion

nextBOLTs & Spec Landscape

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

No questions yet — be the first to ask.