Lightning peers speak BOLT messages over an encrypted, authenticated transport. The ecosystem standardized on the Noise protocol framework, commonly the XK pattern, rather than inventing a bespoke handshake.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: authenticate the peer, encrypt the link
Channel state machines assume you are talking to the correct peer over a confidential link. Broken transport assumptions become fund-loss or privacy bugs.
Noise patterns compose Diffie–Hellman and symmetric crypto into documented handshakes. Lightning’s transport BOLT specifies how node static keys participate so peers authenticate identities as they set up sessions.
Loading diagram…
Builder rules:
- Never roll your own handshake — use the implementation’s transport
- Treat node pubkeys as identities; verify out-of-band for large channels
- Separate clearnet exposure, Tor, and key backup OPSEC
Done when: You can name what Noise provides that plain TCP lacks for Lightning peers.
Step 3 — Peer identity checklist (lab)
List your pubkey and peers. Write a production verification procedure and one phishing/misbinding scenario with mitigation.
Common mistakes
- Pasting node URIs from untrusted chats without verifying the pubkey
- Logging session secrets or static keys
- Assuming LAN Lightning needs no auth because “it’s private”
Done when: Lab evidence (pubkey/peers + procedure + scenario) is complete.
Next lesson
Pathfinding — algorithms that turn the channel graph into a route.