Lightning, honestly.

Bitcoin's base layer is built to settle, not to chat. About seven transactions per second when blocks are full. That's deliberate: every transaction has to be validated by every node for as long as Bitcoin exists, so the protocol is stingy with what it lets through. The cost is that you can't pay for a coffee on it. Not at peak, not for the fee.

Lightning is the canonical answer to that. Two parties open a payment channel anchored by a single on-chain transaction, then update their balances privately as many times as they want. Other channels chain together so you can pay people you don't share a channel with. The base layer is involved only at channel open and close — millions of off-chain payments compress into two on-chain transactions eventually.

That's the elevator pitch. The actual machinery — the HTLCs, the timelocks, the inbound-vs-outbound liquidity dance, the routing graph — is what this lesson is for. We'll also look at where Lightning has fallen short of its early ambitions, because that's the half people gloss over.

1.The throughput problem

A Bitcoin block holds about 4 MB of weighted data and arrives every ~10 minutes. After overheads, that pencils out to roughly 7 transactions per second sustained. Visa runs at ~1,700 transactions per second on average and bursts above 65,000 during peak load. Lightning's entire reason for existing is to close that gap without changing Bitcoin's base-layer constraints.

Why not just bigger blocks? That was litigated bitterly between 2015 and 2017 — see the history timeline for the full account. The small-block side won, on the argument that every doubling of block size makes running a full node twice as expensive — and a network where nobody validates is a network with no security floor.

The trade-off baked in: keep the base layer small and conservative, layer everything else on top. Lightning is the most successful of those layers; Liquid, Statechains, Ark, RGB, and Fedimint are some of the others.

2.The channel

A Lightning channel is a 2-of-2 multisig output between two peers. The on-chain transaction that creates it is the funding transaction; everything after that happens off-chain. Both peers hold pre-signed transactions that spend the funding output back to themselves in agreed proportions. Updating the balance means swapping new signed versions and invalidating the old ones.

Play with it. Open a channel, shuffle balances back and forth, close it. The on-chain footprint is the funding transaction plus the closing transaction — nothing else, no matter how many updates happened in between.

Cooperative close: both peers agree on the final state, broadcast it, get paid out cleanly. Lowest fees, fastest finality, looks identical to any other transaction on-chain (Taproot helps here).

Force close: one peer broadcasts their latest commitment transaction unilaterally. Works without cooperation — that's the point, since your peer might be offline or actively trying to cheat. The cost: more fees, and a time-locked output that delays access to your funds (the timelock is what gives a watchtower a window to catch a cheating peer publishing an old state).

The penalty mechanism is what keeps Lightning honest without trusted parties. If a peer publishes an old commitment to claim a stale balance in their favor, you can broadcast a counter-transaction that sweeps the entire channel balance to your side as a penalty. The threat is enough; in practice this almost never happens.

3.Routing & HTLCs

Two-party channels are a tab. The interesting part is that you can pay someone you don't share a channel with — by hopping across other people's channels. The primitive that makes this safe is the HTLC: a conditional payment that settles only if the recipient reveals a secret preimage before a deadline, and refunds otherwise.

Eve generates a random secret S, hashes it to H, and sends Alice an invoice referencing H. Alice constructs a route through her Lightning graph and sets up HTLCs hop by hop — each one locking slightly less BTC, with slightly shorter timeouts, so the inner hops can never be left holding a one-sided obligation. When Eve reveals S to claim the final hop, the preimage cascades backwards. Either every hop settles, or none of them do.

That's the protocol piece. The actually-hard part is routing — figuring out which sequence of channels to use. Your wallet knows channel capacities (announced on the gossip layer) but not directional balances. So it picks a route, tries it, often watches it fail mid-flight because some channel didn't have liquidity in the direction needed, and reroutes. Modern wallets use probabilistic balance estimators to get smarter at this; it's still a hard problem with no clean solution.

Each hop charges a small fee (a fixed base in millisats plus a proportional ppm). A typical hop fee is 1 sat plus 0.01%. For a 100,000-sat payment routed through three hops you might pay 5–20 sats total. Cheap, but not free — Lightning isn't a charity and routing nodes need a reason to keep capital locked up.

4.Liquidity

The least-glamorous Lightning concept, and arguably the most operationally important. A channel has fixed total capacity but directional liquidity: outbound (your side, what you can spend) and inbound (your peer's side, what you can receive).

A fresh channel you funded yourself has 100% outbound and zero inbound. You can send up to the capacity but can't receive a single sat through it until some balance shifts to your peer. This is the famous new-node problem: opening a channel doesn't make you receivable; only spending through it does.

Acquiring inbound liquidity is its own little economy:

• Pay a service (LNBig, Voltage, Magma) for an inbound channel — they open a channel to you so the funded side is theirs.
• Do a submarine swap: convert on-chain BTC into Lightning inbound by paying a counterparty who pre-loads liquidity on your peer side, secured by HTLCs.
• Open channels to nodes whose typical payment direction is toward you, so flow eventually balances itself.
• Use dual-funded channels (BOLT 1.1) where both sides commit to the channel from the start.

Routing nodes spend most of their operational energy on rebalancing — keeping liquidity flowing across many channels so they remain usable in both directions. It's a real-time inventory management problem with non-trivial economics.

5.What the marketing leaves out

The Lightning lesson that everyone's seen oversells the upside and waves away the costs. Here's the half that earns its skepticism — steel-manned, not strawmanned.

Custodial dominance

Most Lightning users today are on custodial services — Wallet of Satoshi, Strike, Cash App, Phoenix in some modes, exchanges offering Lightning rails. The user experience is so much better on a custodial wallet (no liquidity management, no channel backups, no always-online requirement) that self-custodial Lightning users are a minority of the network's actual flow.

That's a real critique. "Not your keys, not your coins" was supposed to be the whole point, and Lightning in custodial form is exactly the thing Bitcoin was meant to escape. Self-custodial Lightning wallets (Phoenix non-trampoline, Breez, Zeus + your own LND) are improving fast and the gap is closing — but as of today, custodial UX still wins for most users, and that's a structural problem, not a marketing one.

Channel jamming

Cheap to mount, hard to defend against. An attacker initiates many large payments along a route, stalls them until HTLCs time out, and meanwhile the targeted channels can't route legitimate traffic. The economic cost to the attacker is essentially zero — they only have to pay if a payment succeeds, and they deliberately make it fail.

Proposed defenses (upfront fees, reputation systems, unconditional forwarding fees) all have trade-offs and none has shipped as a standard. For now this is mostly a theoretical problem because no one's been particularly motivated to grief the network — but it's a live research area, not a solved one.

Always-online (or trust a watchtower)

Lightning's penalty mechanism only works if someone is watching the chain. If you're offline for a long time and your peer broadcasts an old state, nobody catches them. You either run your node continuously, trust a third-party watchtower, or run the risk. None of those is a great answer for a phone wallet that sleeps overnight.

On-chain fee dependency

Opening, closing, and force-closing all cost on-chain fees. During fee spikes those costs can be larger than the channel capacity for small channels — making Lightning effectively unusable for casual users at exactly the moments the base layer is busiest. Mitigations like splice-in/splice-out (BOLT 1.1) help, but Lightning's economics still depend on the L1 fee environment being civil enough to open and close channels.

The honest verdict

Lightning works. It's not theoretical. People send millions of payments through it every day. But it's a system with sharp edges that reward users who put in the work to understand it, and punishes the rest into either custodial wallets or back onto L1. That's a fair description of where it is in 2026; whether that's good enough depends on what you wanted Lightning to be.

6.Where Lightning is today

Public-network numbers (this is the visible Lightning — there's also a large opaque slice of private channels run by custodial wallets and routing operators that doesn't show up in gossip statistics):

Snapshot from mempool.space's public Lightning index as of 2026-01-06. Refreshed via npm run refresh-lightning.

Capacity has roughly tripled since 2021 but has been roughly flat in BTC terms since 2023 — most growth is now in custodial Lightning and in private channels, which the public stats don't see. The average channel is ~14M sats; the median is ~2M sats, which tells you the distribution is skewed by a small number of very large routing channels.

7.Sources & further reading

• Poon & Dryja, "The Bitcoin Lightning Network" (2016) — the original paper. Dense; the section on revocation is the load-bearing one.
• BOLT specs (Basis of Lightning Technology) — the actual protocol. BOLT 2 (channels), BOLT 4 (routing onion), BOLT 11 (invoices), BOLT 12 (offers).
• mempool.space Lightning explorer — the live network. This page's stats come from its public API.
• Bastien Teinturier's notes on channel jamming — the clearest write-up of the attack and the proposed defenses.
• Lightning Labs docs on HTLCs — implementation-flavored explanation of the contract structure.