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.

By the numbers — how big is Lightning, really?

Public Lightning is small next to Bitcoin’s market cap — and even that understates it, because only announced channels are visible.

publicly-announced capacity:  ~4,000–5,600 BTC   (approx, as of the mid-2020s; it drifts)
public nodes / channels:      tens of thousands of each
private/unannounced channels: NOT counted above — true capacity is higher

Two things follow. First, the figures are inherently fuzzy: a network whose whole point is to keep payments off the public ledger also keeps much of its liquidity off the public graph. Second, the modest headline capacity is fine — a channel is reused indefinitely, so a few thousand BTC can settle a vastly larger flow of payments over time. Throughput, not locked capital, is the number that matters.

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.

The architect’s lens

Lightning is a deliberate second layer — interrogate the design, not just the mechanics:

• Why does it exist? Because the base layer settles ~1 block per ten minutes and stores every payment forever — great for settlement, terrible for coffee. Lightning’s insight is that strangers only need to agree on a channel’s opening and final balances, not on every payment in between.
• What problem does it solve? Throughput and cost: a single on-chain 2-of-2 multisig (open) plus a close can carry an unlimited number of instant, fee-free off-chain payments, and HTLCs route them across strangers trustlessly — the protocol, not the intermediaries, guarantees atomicity.
• What are the trade-offs? Inbound/outbound liquidity must be positioned; routing can fail to find a path; you must stay online (it’s “hot”); and defending against an old-state broadcast means you or a watchtower must catch it inside the CSV penalty window.
• When should I avoid it? It’s the wrong tool for cold, long-term storage (base-layer UTXOs win there) and for large or unusual payments that can’t find a route — Lightning is a different tradeoff, not a strict upgrade.
• What breaks if I remove it? Every payment falls back to competing for scarce block space at the fee market rate, so micro-payments become uneconomical and Bitcoin stays a settlement ledger rather than a payments network.

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?

Show answers

1. A payment channel is a single on-chain 2-of-2 multisig output — a coin that can only move if both parties sign. “Updating channel state” means re-signing a new split of that locked balance off-chain (state 1, state 2, …, thousands of them); neither party broadcasts anything, they just hold the latest mutually-signed state, ready to settle on-chain whenever they choose.
2. Revealing the secret R to claim payment publishes it upstream, so each hop can in turn claim from the one before it — the whole route settles or nothing does, which makes it atomic. The timelocks must be staggered (longer upstream, shorter downstream) so each forwarder can claim after the downstream secret appears but before its own refund expires; no honest router is left out of pocket.
3. Each time the channel advances, the parties exchange a revocation secret that lets the other side punish an old state. If you broadcast a revoked state, your payout is timelocked (CSV), and during that window your counterparty (or their watchtower) uses the revocation key to sweep the entire channel balance. Old state isn’t merely invalid — publishing it hands your counterparty everything, so the expected value of cheating is negative.
4. Liquidity — you can only send up to your side and receive up to the other side, so capacity must be positioned; this exists because off-chain balances aren’t fungible base-layer coins. Routing — a multi-hop payment needs a connected path with enough liquidity at every hop, so unusual payments can fail to find a route. Online requirement — you must be online to accept payments and to catch a cheating old-state broadcast within its timelock, making Lightning “hot.” Watchtowers — offline users delegate that monitoring, another moving part with its own trust/availability consideration.
5. Strangers don’t have to agree on every payment — only on the channel’s opening and final balances — and they know that if anyone cheats in between, the base chain will adjudicate (via the penalty/timelock mechanism). The shared chain becomes a court of last resort the off-chain contracts can always fall back to, which is what lets parties transact trustlessly at internet speed.