BOLTs & Spec Landscape

BOLTs (Basis of Lightning Technology) are the interoperability specs for Lightning. LND, Core Lightning, and LDK aim to speak the same protocol so heterogeneous nodes can route.

Why this matters

Without shared specs, every implementation would be an island. Builders reading BOLTs can debug wire mismatches and evaluate new features (offers, splicing) before they are universal.

Analogy

BOLTs are the electrical code for Lightning. Different manufacturers (LND/CLN/LDK) can ship distinct products, but plugs must still fit.

Map of essentials

Common mistakes

• Assuming a feature in one implementation is already a ratified BOLT everywhere
• Treating blog posts as authoritative over the spec text
• Ignoring feature bits / negotiations between peers

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 Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

Hands-on habit

Every protocol idea should be paired with one local experiment:

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)

That habit turns reading into builder instinct.

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.

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.

Next steps

Study BOLT11 invoices, the payment requests wallets actually scan.