The Lightning Network, and what it does not change

Two parties who share a channel can pay each other directly. To pay someone you have no channel with, the payment is routed through a path of channels, with each intermediate node forwarding it onward. The forwarding is secured by a hash time-locked contract: the sender commits to a payment hash, each hop passes the same hash along, and the final recipient reveals the preimage that unlocks every hop in the path at once. Either the whole path settles or none of it does. BOLT #4 specifies the onion packet that carries these instructions and the failure messages that come back when a hop cannot forward.

The route is chosen by the sender, not by the network. The sender needs to know which channels exist and what each one charges, and it learns that from the gossip protocol described in BOLT #7, in which nodes announce their public channels and their fee policy. A node that does not want its channels announced can keep them private and supply route hints inside the invoice instead, which is what the optional route field in BOLT #11 is for. There is no central router and no directory that must be consulted; the sender assembles the path from what it has learned.

Each forwarding node takes a fee, quoted as a fixed base amount plus a proportional component, and each one also imposes a time lock that must be long enough for it to claim its own funds if the next hop fails. Those two parameters — the fee and the expiry delta — are the economic content of a routing node's policy, and they are what the sender weighs when choosing between competing paths. A payment that cannot find a path with sufficient capacity and acceptable fees simply fails, and the sender may retry along a different route or split the payment into several parts.

What it changes is the cost and the latency of a small payment. A Lightning payment settles in the time it takes the onion to traverse its hops, which is a matter of seconds, and the fee is a fraction of the base-layer fee because no block space is consumed. That makes payments of a few dollars economically sensible in a way that an on-chain transaction is not when fees are high. It is the reason Lightning is the layer most often proposed for retail payments, tips and machine-to-machine micropayments.

What it does not change is the base chain's role as the final arbiter. A Lightning payment is a transfer of a claim, and the claim is only as good as the ability to enforce it on-chain. If a channel partner disappears, if a routing node goes offline mid-payment, or if the two parties disagree about the current state, the resolution is a base-layer transaction and the wait that comes with it. The specification is explicit that the on-chain fallback is part of the design rather than an edge case: BOLT #5 exists precisely to set out how participants should behave when a channel must be closed unilaterally.

There is also a capital cost that is easy to miss. Funds committed to a channel are not available for anything else, and a node that wants to receive payments needs inbound capacity — bitcoin on the other side of a channel — which is a different resource from simply owning bitcoin. Routing nodes tie up capital in both directions and earn fees for doing so. For an ordinary user, the practical effect is that Lightning is well suited to spending and poorly suited to holding: the same bitcoin cannot be simultaneously a long-term reserve and working liquidity in a channel.

The honest summary is that Lightning is a settlement layer for small, frequent payments that inherits its security from the base chain and pays for its speed with capital lock-up and an online requirement. The liquidity page explains why the depth available on the base chain matters to every layer built on top of it, and the comparison with traditional payment rails sets out where the two models genuinely differ.