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 // bitcoin

Code Review Practice

Review peer pull requests and learn what maintainers expect from contributors.

intermediate5 days

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

./sign-in

On this page

Learning objectives

  • Review diffs for correctness, tests, and clarity
  • Leave actionable comments without noise
  • Understand ACK culture and CI expectations

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
code review practiceACK NACKdiff review

Step 1 // Required reading

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

  • docsBitcoin Core CONTRIBUTING
  • articleConventional comments

Reflection prompts

  1. Explain Code Review Practice to a teammate without jargon - what problem does it solve?
  2. What would break in production if you misunderstood Code Review Practice?
  3. Which BIP, book chapter, or Core doc is authoritative here, and what did you verify?

Lab // Written review notes

Complete Steps 2–3. Review one open PR (Review Club or Bitcoin-track /issues). Leave or draft actionable comments covering correctness, tests, and clarity.

evidence required

  • ·PR URL reviewed
  • ·Written review notes (or link to your GitHub comments)
  • ·One sentence on whether you would ACK, NACK, or request changes — and why
  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.

Reviewing is how Bitcoin stays safe. You will learn more from careful review than from rushing another feature PR.

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

Step 2 — Context: what maintainers expect

Use Pull’s Review Club picks on this lesson, or browse open issues filtered for Bitcoin tracks.

What to check:

  1. Does it solve the claimed problem?
  2. Are there tests?
  3. Are edge cases handled?
  4. Is the diff minimal?

Loading diagram…

Description → diff → tests → informed ACK or change request.

Be precise

Prefer “This breaks reorg handling because X” over “Hmm not sure.”

Done when: You can explain why silence is not an ACK.

Step 3 — Practice: review one PR (lab)

Read the description, inspect the diff, run or reason about tests if feasible. Draft comments using conventional-comment prefixes where helpful (nit:, suggestion:, issue:).

Checklist

  • Comments are actionable (what + why)
  • You checked tests / verification claims
  • You stated ACK / NACK / request-changes clearly

Done when: Lab evidence (PR URL + notes + verdict sentence) is complete.

Next lesson

Contribution Rubric — score your own attempt before asking for review.

further reading

  • articleBitcoin Optech Newsletter

review // club

Review club

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

  • Recent Bitcoin Core PR for review practice

    Pick a small open Core 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.

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

prevFinding Good First IssuesnextContribution Rubric

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

No questions yet — be the first to ask.