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

Opening Channels

Fund channels, configure policies, and monitor inbound capacity.

intermediate5 days

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

./sign-in

On this page

Learning objectives

  • Open a channel on a local Lightning lab
  • Explain funding outputs and confirmation requirements
  • Configure fees and understand inbound vs outbound capacity

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

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. 7: Payment Channels

Reflection prompts

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

Lab // Open a lab channel

Complete Steps 2–3. On Polar/regtest, connect two nodes and open a channel. Note funding confirmation depth and local/remote balance after open.

evidence required

  • ·connect + openchannel (or Polar UI) proof
  • ·Balance split after open (local vs remote)
  • ·Link to Mastering Lightning Ch. 7 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.

Opening a channel locks on-chain funds into a collaborative contract so you can send many off-chain payments later.

Complete Step 1 // Required reading in the study plan above, then continue here. This opens Channels & HTLCs.

Step 2 — Core idea: fund, confirm, activate

Channel opens lock capital on-chain. Whether you can send or receive depends on how balance is split — covered next in Channel Liquidity.

Analogy: Stocking a cash drawer between two cashiers. Total cash is fixed until you restock (splice/dual-fund) or close.

Loading diagram…

Fund on-chain, wait for depth, then activate the channel.
# Illustrative LND-style flow
lncli connect <pubkey>@host:port
lncli openchannel <pubkey> <local_amt>

Single-funded opens usually leave the funder outbound-heavy. Do not route large value before your configured confirmation depth.

Confirmations matter

Wait for channel readiness (and your depth policy) before treating the channel as operational.

Done when: You can narrate open → funding tx → confirmations → channel_ready.

Step 3 — Try it: open on Polar (lab)

Connect two lab nodes and open a channel. Record local vs remote balance right after open.

Common mistakes

  • Opening to random public nodes without operational needs
  • Ignoring on-chain fees and reserve requirements
  • Forgetting backups after open

Done when: Lab evidence (open proof + balance split + source link) is complete.

Next lesson

Channel Liquidity — why balance direction matters before you route a single payment.

further reading

  • boltBOLT2 Peer Protocol
  • docsLND openchannel

review // club

Review club

Practice on real Lightning OSS changes tied to this chapter. Read the diff, use the checklist, and optionally paste your review comment URL in your lab notes.

  • Polar local dev GFI

    Polar powers most labs - review a small issue that improves local Lightning learning.

    gfi
    developer UXregtest
    25 min·beginneropen on GitHub

  • CLN plugin docs good first issue

    Pick a documentation GFI related to channels or plugins and draft a review comment on clarity.

    gfi
    readabilityexamples
    30 min·beginneropen on GitHub
review checklist
  1. Does the change solve the stated problem?
  2. Are edge cases and rollout behavior covered?
  3. Are tests or test vectors included?
  4. Is the diff minimal and clearly explained?

More repos and GFIs on /discover and /issues.

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

prevLNURLnextChannel Liquidity

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

No questions yet — be the first to ask.