The Lightning Network explained: payment channels, routing, and what it is good and bad at

The problem: a ledger everyone copies cannot carry every coffee

Every Bitcoin transaction is broadcast to every node and stored by every node forever. That is the point: anyone can check the whole history for themselves, which is what makes the system trustworthy without a bank in the middle. It is also the limit. The Lightning paper, by Joseph Poon and Thaddeus Dryja and dated 14 January 2016 in its published draft, put the numbers plainly: Bitcoin “supports less than 7 transactions per second with a 1 megabyte block limit,” while Visa had handled a peak of 47,000 per second.

The obvious fix, making blocks enormous, has a cost. The paper calculates that matching Visa’s peak would take nearly 8 gigabytes per block, and warns that “no home computer in the world can operate with that kind of bandwidth and storage.” Blocks that only data centers can validate mean only data centers can check the rules, which the authors argue would hand Bitcoin back to trusted intermediaries. Whether and how much to raise the limit was the fight behind the block size war.

Lightning takes a different route. Most payments between two people do not need the whole world to see each one. “If only two participants care about an everyday recurring transaction,” the paper says, “it’s not necessary for all other nodes in the bitcoin network to know about that transaction.” Keep the small payments between the two parties, and use the blockchain only to open, close and, if necessary, referee.

A payment channel is a running tab backed by a real bitcoin transaction

A channel starts with an ordinary on-chain transaction. Two parties, call them Alice and Bob, put coins into an output that needs both of their signatures to spend. The paper calls this the funding transaction. Before it is broadcast, they also sign a refund that returns the coins to each of them, so neither is trapped. Then they exchange signed transactions for each new balance, say 0.07 to Alice and 0.03 to Bob, without broadcasting any of them.

The trick is making only the latest balance count. Each time the balance changes, the previous version is revoked: each party hands the other a secret that would let the victim take all the funds in the channel if the cheater ever broadcast an old state. The paper describes it as a penalty in which “all old transactions are thereby invalidated.” Both parties keep the current state, and either can close the channel at any moment by publishing it. If they stay cooperative, the paper notes, the channel “can remain open indefinitely, possibly for many years.”

The BOLT specifications, which every Lightning implementation follows, turn this into a precise conversation between two nodes. BOLT 2 lays out the messages: open_channel and accept_channel to agree terms, funding_created and funding_signed to exchange signatures, channel_ready once the funding transaction has confirmed, then update_add_htlc, commitment_signed and revoke_and_ack for every payment, and shutdown and closing_signed to settle up on the chain. These are “real bitcoin transactions,” as the paper stresses, “not a separate trusted network on top of bitcoin.”

Routing: paying someone you have no channel with

Two-party tabs would not get far on their own. The paper’s central idea is that channels can be chained. If Alice has a channel with Bob, Bob with Carol, and Carol with Dave, Alice can pay Dave through the middle two, and the intermediaries cannot run off with the money. The mechanism is a hashed timelock contract, or HTLC: a conditional payment that can be claimed only by revealing a secret that matches a given hash, and that expires after a deadline if the secret never appears.

Dave generates the secret and gives Alice its hash. Alice offers Bob an HTLC: this money is yours if you show me the secret within, say, three days. Bob offers Carol the same with a shorter deadline, and Carol offers Dave a shorter one still. Dave reveals the secret to claim from Carol, Carol uses it to claim from Bob, and Bob from Alice. The paper describes the chain as “a series of decrementing timelocks,” and the shrinking deadlines are what guarantee that nobody in the middle can be left holding an obligation they cannot collect on.

On the live network, the route is wrapped in layers of encryption, one per hop, following BOLT 4. Each node decrypts its own layer, learns only “which node they should forward the packet to,” and passes the rest along. It does not learn who sent the payment, who will finally receive it, or how long the route is. Nodes that forward payments charge small fees for the use of their channel balance. Payment is near instant because nothing waits for a block; the blockchain is only consulted if someone misbehaves. This is why Lightning is called a second layer: Bitcoin is the court of last resort, and the second layer is where the everyday business happens.

Why it needed SegWit first

Lightning depends on signing transactions that spend from a funding transaction before that funding transaction is confirmed. That only works if the funding transaction’s ID cannot change between signing and confirmation. For most of Bitcoin’s history it could: a quirk called transaction malleability let anyone tweak a signature and thereby the ID. The paper lists the “malleability soft-fork” among the changes Bitcoin needed, and it was a large part of why the design stayed on paper.

The SegWit upgrade, activated in August 2017, moved signatures out of the data that produces a transaction ID. BIP141, its specification, names the benefit directly: it makes possible “unconfirmed transaction dependency chains without counterparty risk,” which is precisely what Lightning channels are. Seven months after SegWit activated, the first Lightning software declared itself ready for real coins.

From a paper to a network: the BOLTs and the 2018 beta

Several teams wrote independent Lightning software and needed it to interoperate, so they wrote a shared specification. The BOLTs, short for Basis of Lightning Technology, are numbered documents on GitHub covering messaging, channel management, transaction formats, onion routing, gossip about the network’s channels, and invoices. The repository still calls itself a work in progress, and changes are discussed in public before they are merged.

On 15 March 2018, Lightning Labs released lnd 0.4-beta and called it “the first Lightning mainnet beta, an important milestone.” The post was careful: the software was for developers and technical users, and everyone was told to “experiment with only small amounts.” CoinDesk reported that around 1,000 nodes were already running Lightning software on the main Bitcoin network before the release, that the software capped channels at roughly $1,400 and single payments at around $400, and quoted the company’s chief executive, Elizabeth Stark, warning users not to risk more than they could afford to lose.

The network has since been drawn into national policy. When El Salvador made bitcoin legal tender in September 2021, CoinDesk reported that Lightning payments were being used by wallets including the government’s own Chivo app. Our dossier on the El Salvador Bitcoin law explains why counting Chivo transfers as Bitcoin transactions is harder than it sounds.

What Lightning is good at, and what it is not

It is good at exactly what the paper promised: small, frequent, instant payments at fees far below an on-chain transaction, with amounts that can go “down to the satoshi.” Once a channel is open, paying is a matter of exchanging a few messages. For a merchant taking many small payments, or for anyone who wants to send a few cents, that is something the base layer cannot offer.

The trade-offs are real, and the paper is candid about them in its section on risks. You, or someone acting for you, must watch the blockchain and be ready to respond if a counterparty broadcasts an old state; the authors suggest “a designated third party” to do this on your behalf. Losing your channel data can cost you the funds in it. Deadlines must be chosen carefully, since a too-short timelock is a theft opportunity. And a coordinated attack that forces many channels to close at once could, the paper warns, “overwhelm block data capacity.”

One practical limit is easy to miss. A channel can only move what is in it: the paper is explicit that balances must stay within the funds committed in the funding transaction. A payment larger than the balance on your counterparty’s side cannot arrive, and a route across several channels needs enough balance at every hop. Opening and closing channels are on-chain transactions that pay on-chain fees, so Lightning does not make the fee market go away; it means you pay it less often. For savings you rarely touch, the paper itself suggests keeping keys offline and leaving Lightning to everyday payments.