The Lightning Network

Bitcoin’s base layer settles roughly a block every ten minutes and asks every node on Earth to store every payment forever. That is wonderful for a global settlement ledger and terrible for buying coffee. Lightning is the most successful answer to “can we keep Bitcoin’s trust model but make payments instant and cheap?” — and the answer it gives is profound: most payments never need to touch the chain at all.

Built on Part 10 primitives

Lightning is timelocks + hashlocks wearing a trench coat. The mechanics of timelocks → HTLCs are the prerequisite for this page; here we assemble them into a network.

A payment channel is a 2-of-2 contract

Two parties open a channel by locking funds into a single 2-of-2 multisig output — a coin that can only move if both sign. That one on-chain transaction is the only thing the network sees up front.

From then on, they pay each other by re-signing the split of that locked balance, off-chain, privately, instantly. Each new signed balance is a channel state. Neither has to broadcast anything; they just hold the latest mutually-signed state, ready to settle on-chain whenever they choose.

                 OPEN (on-chain, once)
   Alice  ──┐                                        ┌──  Bob
            └──►  2-of-2 multisig: 1.0 BTC  ◄────────┘
                          │
        ───── off-chain, instant, free ─────────────────────
        state 1:  Alice 0.6 | Bob 0.4   (both sign)
        state 2:  Alice 0.3 | Bob 0.7   (both sign)   ← thousands of these
        ...
                          │
                 CLOSE (on-chain, once)
        broadcast the latest state → settle final balances

Two on-chain transactions (open and close) can carry an unlimited number of off-chain payments. That is the entire scaling idea.

Routing across strangers: HTLCs

A channel only connects two people. The network part is being able to pay someone you have no channel with, by hopping through people who do — without trusting the intermediaries.

This is exactly the HTLC construction. The recipient picks a secret R and shares its hash H. Each hop forwards a conditional payment: “you get paid if you reveal R, else I’m refunded after a timelock.” Revealing R to claim payment publishes the secret upstream, so each hop can in turn claim from the one before it.

Carol picks secret R, sends H = SHA256(R) to Alice.

Alice ──HTLC(pay if R, refund 3d)──► Bob ──HTLC(pay if R, refund 2d)──► Carol
                                                                          │
Carol reveals R to claim  ◄───────────────────────────────────────────  ┘
Bob learns R, uses it to claim from Alice.   Everyone is square — atomically.

The staggered timelocks (3 days, then 2 days) guarantee each forwarder can claim after the downstream secret appears but before their own refund expires. No honest router can be left out of pocket. None of this requires trusting Bob — the protocol, not the person, guarantees the outcome.

Keeping people honest: the penalty mechanism

Off-chain state raises an obvious attack: what stops Bob from broadcasting an old state where he held more money — say, before he paid Alice back?

Lightning’s answer is a penalty built on revocation. Each time the channel advances, the parties exchange a secret that lets the other side punish them if they ever publish that now-revoked state. When you broadcast a channel close, your own output is encumbered by a relative timelock (CSV); during that window, if you published an old state, your counterparty can use the revocation secret to sweep the entire channel balance as a penalty.

Bob broadcasts a REVOKED old state (where he had more).
  → Bob's payout is timelocked for N blocks.
  → Alice (or her watchtower) sees it, uses the revocation key,
     and takes ALL the funds before the timelock expires.
Cheating is not just blocked — it's punished. Expected value of cheating < 0.

This is why old state is dangerous to publish: the timelock turns “trying to cheat” into “handing your counterparty everything.” Honesty is the only rational strategy.

What Lightning solves — and what it costs

Solves: payments that are instant (no block wait), cheap (no per-payment on-chain fee), and scalable (millions of off-chain payments per on-chain footprint), with strong privacy (hops don’t see the whole route).

Costs — and these are real, not footnotes:

• Inbound/outbound liquidity. You can only send up to your side of a channel’s balance and only receive up to the other side’s. Capacity must be positioned, which is a genuine UX hurdle.
• Routing. A payment needs a connected path with enough liquidity at every hop. Large or unusual payments can simply fail to find a route.
• Online requirement. To accept payments and to defend against an old-state broadcast, you generally need to be online — Lightning is “hot” by nature, unlike cold base-layer storage.
• Watchtowers. Because you must catch a cheating close within its timelock, offline users can delegate monitoring to a watchtower that watches the chain and punishes fraud on their behalf. Useful, but another moving part (and a trust/availability consideration).

Lightning is a different tradeoff, not a strict upgrade

Lightning leans on the base chain for settlement and dispute resolution but does day-to-day payments off it. That buys speed and cost — at the price of liquidity management, routing uncertainty, and an online/watchtower requirement. It’s the right tool for many payments and the wrong tool for cold, long-term storage.

The thread

How does this help untrusting strangers agree on one ledger? Lightning’s insight is that strangers don’t have to agree on every payment — they only have to agree on the opening and final balances, and to know that if anyone cheats in between, the base ledger will adjudicate. The shared chain stops being a record of every coffee and becomes a court of last resort that the off-chain contracts can always fall back to. That fallback is what lets two people — or a chain of them — transact trustlessly at the speed of the internet.

Check your understanding

1. What single on-chain object is a payment channel, and what does “updating channel state” actually mean off-chain?
2. In a 3-hop route, why does revealing the secret make the whole payment atomic, and why must the timelocks be staggered (longer upstream, shorter downstream)?
3. Describe the penalty mechanism. Why does it make broadcasting an old state irrational rather than merely invalid?
4. List Lightning’s main tradeoffs (liquidity, routing, online requirement, watchtowers) and explain why each arises from being off-chain.
5. In what sense does Lightning treat the base chain as a “court of last resort,” and how does that preserve trustlessness?