Each Lightning channel state is backed by a pair of commitment transactions — pre-signed on-chain settlements either party can broadcast if cooperation fails.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: revoke old bills, punish cheats
If commitments are wrong, someone can steal funds or deadlock value. This is the cryptographic spine of Lightning security.
Analogy: Every time you update the bar tab, you both sign a new “final bill” and destroy the ability to cash an older bill — because an old bill would be fraud and is punishable.
When state advances to n, state n-1 is revoked. Publishing a revoked commitment lets the peer sweep funds via a penalty (justice) transaction.
Loading diagram…
Commitment outputs typically pay each side with different conditions. The local party's output often includes a revocation path and a delayed CSV path. Modern channels use anchor outputs so fee bumping a force-close is more reliable under mempool pressure.
Treat updates as a state machine: proposed → signed → committed → previous revoked. Bugs are often off-by-one state indices.
Done when: You can explain why broadcasting an old commitment can forfeit funds.
Step 3 — Security brief (lab)
Write the half-page brief. Optional: after a Polar payment, note any state/balance fields that changed.
Common mistakes
- Treating commitments as “just accounting” without revocation
- Ignoring CSV delays on honest force-close
- Building fee logic without reading anchor behavior for your stack
Done when: Lab evidence (brief + watchtower sentence + source) is complete.
Next lesson
HTLC Mechanics — conditional payments on top of commitments for multi-hop routing.