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

Watchtowers

Outsource breach detection so offline wallets stay protected.

advanced5 days

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

./sign-in

On this page

Learning objectives

  • Explain the watchtower threat model
  • Describe encrypted breach remedies at a high level
  • Configure or integrate a tower in a lab

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
watchtowerbreach detectionjustice transactionLightning security

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. 16: Security and Privacy

Reflection prompts

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

Lab // Tower threat model brief

Complete Steps 2–3. Write when a mobile/LDK wallet needs a tower, what the tower learns, and one mitigation (multi-tower, self-host). Optionally enable or inspect watchtower settings on LND Polar if available.

evidence required

  • ·Half-page threat model: offline breach → tower justice
  • ·Privacy tradeoff note (metadata the tower may learn)
  • ·Link to Ch. 16 or Optech watchtowers section
  • ·Optional: lab config/UI proof
  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.

A watchtower monitors the blockchain for revoked commitment broadcasts on your behalf and can publish justice transactions if you are offline.

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

Step 2 — Core idea: someone watches when you sleep

Phones sleep. Laptops close. Lightning’s penalty model needs someone watching. Towers extend security to intermittent devices.

Analogy: A neighborhood security camera that only unlocks the evidence locker if a specific break-in pattern appears — without learning your daily life (ideally).

Loading diagram…

Towers watch for breaches and act when you cannot.

Trust tradeoffs

Towers learn some metadata. Design privacy expectations; consider multiple towers.

Done when: You can explain why towers do not replace correct backups.

Step 3 — Threat model brief (lab)

Write offline-breach → tower justice, privacy tradeoffs, and one mitigation. Optional LND tower config on Polar.

Done when: Lab evidence (brief + privacy note + source) is complete. Complete the chapter quiz when prompted.

Next lesson

Lightning POS Project — invoices, webhooks, and settlement UX.

further reading

  • docsLND watchtower
  • articleBitcoin Optech: Watchtowers

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.

  • LND good first issue

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

    gfi
    scopetests
    25 min·intermediateopen on GitHub
  • LDK documentation GFI

    Pick an LDK docs issue and leave a constructive review or draft improvement.

    gfi
    API clarityexamples
    30 min·beginneropen on GitHub
  • CLN plugin example PR

    Review a CLN plugin PR for test coverage and hook safety.

    pr review
    hooksRPC surface
    40 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.

build // next

Apply this chapter in a project

You have the concepts — ship something small to prove it. These Pull projects connect directly to what you just studied.

  • project // lightning-pos

    Lightning POS
    ./spec./submit
  • project // ln-node-dashboard

    Node Ops Dashboard
    ./spec./submit

discussion

Discussion

prevLDKnextLightning POS

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

No questions yet — be the first to ask.