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

Protocol Review Practice

Review BOLT-related changes and participate in specification discussions.

advanced1 week

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

./sign-in

On this page

Learning objectives

  • Read a BOLT PR or mailing-list proposal critically
  • Write a structured review of interoperability impact
  • Separate implementation bugs from spec ambiguities

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
BOLT spec reviewLightning interoperabilitybolts PRtest vectors

Step 1 // Required reading

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

  • boltlightning/bolts PRs

Reflection prompts

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

Lab // Spec review writeup

Complete Steps 2–3. Pick an open or recent bolts PR (or Optech Lightning note). Write a structured interop review: problem, rollout behavior, new failure modes, test vectors.

evidence required

  • ·BOLT PR or proposal URL
  • ·Structured review answering the four checklist questions
  • ·One sentence separating "implementation bug" vs "spec ambiguity" if relevant
  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.

Specification review keeps the network coherent. Practice evaluating proposals for clarity, edge cases, and backward compatibility.

Complete Step 1 // Required reading in the study plan above, then continue here. This closes the Lightning roadmap.

Step 2 — Context: interop first

Start with Review Club spec picks or open PRs on lightning/bolts.

Review checklist:

  1. What problem does this solve?
  2. How do existing nodes behave during rollout?
  3. What new failure modes appear?
  4. Are test vectors included?

Loading diagram…

Read, analyze interop, review, discuss.

Tone matters

Spec debates can be intense. Be precise, charitable, and evidence-based.

Done when: You can separate an implementation bug from a spec ambiguity in one example.

Step 3 — Practice: write the review (lab)

Pick a bolts PR or Optech Lightning note. Answer all four checklist questions. Note rollout risk for LND/CLN/LDK if relevant.

Checklist

  • Problem stated in your own words
  • Rollout / backward-compat considered
  • Failure modes and tests called out

Done when: Lab evidence (URL + structured review) is complete. Complete the chapter quiz when prompted.

You now have a full Lightning builder path — from invoices to protocol review. Keep building, keep testing on regtest, and keep contributing.

further reading

  • docsBOLT review process
  • articleBitcoin Optech Lightning notes

review // club

Chapter review picks

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.

  • Open BOLT pull requests

    Review an open BOLT PR using the spec checklist: problem, interop, failure modes, tests.

    spec review
    rollouttest vectorsambiguity
    60 min·advancedopen on GitHub

  • LND good first issue

    Shortlist two GFIs and write a one-paragraph approach for the better fit.

    gfi
    scopetests
    25 min·intermediateopen on GitHub

  • Recent LND PR for review practice

    Pick a small open PR and leave a conventional comment on one concrete improvement.

    pr review
    correctnesstestsscope
    45 min·intermediateopen 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.

discussion

Discussion

prevFirst Lightning PR

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

No questions yet — be the first to ask.