What Is the Lightning Network? How Bitcoin Payment Channels Work

Bitcoin is designed to settle transactions on a shared blockchain, but not every payment needs to wait for a block or appear individually on that ledger. The Lightning Network is a payment layer built on Bitcoin that lets participants exchange bitcoin through payment channels, then use the blockchain to open or close those channels when needed.

That design can make frequent, smaller payments fast and inexpensive. It also introduces a different set of trade-offs: funds are committed to channels, payment success depends on available liquidity and reachable routes, and wallet design affects who controls the keys. Understanding those distinctions is more useful than treating Lightning as simply “Bitcoin, but faster.”

What the Lightning Network is—and what it is not

Lightning is a peer-to-peer network of payment channels anchored to Bitcoin. The Bitcoin blockchain remains the base layer: it records channel funding and can enforce the agreed rules if participants cannot settle cooperatively. Most individual Lightning payments update channel balances without creating a new Bitcoin transaction for every payment.

This is why Lightning is called a second layer. It does not replace Bitcoin’s blockchain or change bitcoin’s supply. It moves repeated payment activity off-chain while relying on Bitcoin transactions and scripts for channel security and eventual settlement.

Lightning is not one company’s payment app, nor does it make every transfer instant, free or private. Wallets may rely on hosted services, and routing can fail. Protocol design and wallet custody are separate questions.

A payment channel, step by step

A channel begins with an on-chain funding transaction. The two participants jointly control the funds, normally through a two-of-two arrangement: both sides’ signatures are needed for a cooperative settlement.

After the channel is funded, the participants can make payments back and forth by exchanging updated, signed commitment states. Imagine Alice and Bob put 100,000 satoshis into a channel, with 60,000 initially allocated to Alice and 40,000 to Bob. If Alice pays Bob 5,000 satoshis, the updated balance becomes 55,000 for Alice and 45,000 for Bob. No new Bitcoin block is needed for that update.

Modern channel protocols discourage publishing outdated states. Wallet software and backups still matter: channel funds are not managed exactly like a simple on-chain address.

When both parties agree to finish, they can cooperatively close the channel by signing a final on-chain transaction that pays each participant’s balance. If one side disappears or refuses to cooperate, the other can initiate a unilateral, or force, close using the channel’s on-chain rules. That takes blockchain space and may involve waiting periods before some funds can be spent.

How a payment travels through other people’s channels

You do not need a direct channel to everyone you pay. If Alice has a channel with Bob and Bob has one with Carol, Alice may pay Carol through that path. Each channel needs enough usable capacity in the right direction for the payment and fees.

Lightning uses hash time-locked contracts (HTLCs) to make multi-hop payments conditional. The recipient generates a secret and shares information derived from it. Intermediaries can claim their portions only when the condition is satisfied; if it is not, the conditional transfers can be reversed after time limits expire. Lightning developer documentation describes the payment as atomic: it completes in full or fails rather than leaving an intermediary with a partial payment.

A sender’s wallet searches for a route using available network information and tries to satisfy the fees and timing conditions along it. The entire route is not necessarily visible to every node. Onion-style routing limits what intermediaries learn about the wider path, but that does not make every wallet or payment completely anonymous. Network participants can still observe information available to them, and wallet providers may have their own data practices.

Why liquidity matters

Channel capacity is directional. If you open a channel and initially fund it entirely from your side, you can generally send from that balance, but you may have little or no capacity to receive until the balance shifts or another participant provides liquidity in your direction. A channel’s total size alone does not tell you how much you can send or receive right now.

As payments move, balances move too. A merchant who mostly receives payments may accumulate funds on one side of channels and need ways to move liquidity back or obtain channels with inbound capacity. Routing nodes face a related job: they need usable balance in both directions across their channels, and may set fees to compensate for the capital they make available.

This is why a Lightning payment can fail even when the network is online and the recipient is legitimate. There may be no workable route with sufficient liquidity for that amount at that moment. Trying a smaller payment, a different wallet route, or a later attempt may help, but none is a guarantee. A failed route is not the same as losing bitcoin: it means that payment did not complete through that attempt.

Invoices are payment requests, not ordinary Bitcoin addresses

On-chain Bitcoin payments typically use an address as a destination. Lightning commonly uses an invoice created by the recipient. An invoice can encode details such as the recipient, amount, expiry and payment-specific information. The sender’s wallet reads the invoice and attempts to route the payment.

That difference matters in everyday use. An invoice may expire, may be for a specific amount, and generally should not be treated as a reusable address. Some wallet experiences provide other ways to request Lightning payments, but the underlying payment request and channel mechanics still matter. Always check the network and amount shown by your wallet before confirming.

Costs, speed and the role of the Bitcoin blockchain

Lightning can be useful when two parties make repeated payments, because they do not need to publish each balance update to Bitcoin. But it is not accurate to say that Lightning has no on-chain costs. Opening a channel requires an on-chain transaction, and closing one can require another. Network fees on Bitcoin vary with demand, so the cost of setting up or closing a channel can be meaningful relative to a small payment.

A routed Lightning payment may include fees charged by forwarding nodes. Those fees depend on the route and its policies; “low cost” is not a universal price promise. A force close also uses block space, and on-chain settlement may take longer than an ordinary in-channel payment. Lightning is therefore best understood as a different settlement pattern, not a way to remove Bitcoin’s base-layer constraints.

Custody, uptime and backups

Some Lightning wallets hold the keys and manage channels for the user; others give users more direct control. A custodial wallet may feel simpler, but the provider can control or intermediate access to funds. A self-custodial wallet puts more responsibility on the user and its software, including seed security and channel-specific recovery data.

Lightning nodes need to stay sufficiently connected to participate in payments. A temporarily offline wallet may not send or receive in the same way as an always-available service. The exact behavior depends on the wallet and its architecture. Watchtowers can help monitor for certain channel breaches while a user’s node is offline, but they are not a substitute for understanding the wallet’s recovery model.

Backups deserve particular care. LND’s recovery documentation says a static channel backup is intended as an emergency recovery method that can cause channels to close; it is not a way to restore a channel to its previous active state. The same documentation warns that restoring an outdated channel database can be risky. Follow the wallet’s own backup instructions, keep recovery material private, and do not restore old channel files casually.

When Lightning makes sense

Lightning is suited to use cases where a quick Bitcoin payment is more useful than recording every transfer separately on-chain: small purchases, tips, repeated payments or transfers between people whose wallets can route through the network. Bitcoin.org describes it as a payment layer for near-instant, typically low-cost payments, while also distinguishing it from on-chain transfers.

For a large, infrequent transfer, a user may prefer an on-chain transaction or another settlement arrangement. For Lightning, check whether the recipient supports it, whether the wallet is custodial or self-custodial, what fees may apply, and how the wallet handles backups and channel liquidity. These practical details often matter more than the label “Lightning enabled.”

The bottom line

The Lightning Network lets Bitcoin users make repeated payments through channels, with Bitcoin’s blockchain providing the funding and settlement layer. HTLCs help route conditional payments across multiple channels, while channel balances and liquidity determine whether a particular route can work.

The trade-off is added operational complexity: channels must be funded and managed, liquidity is directional, and recovery is not identical to restoring a standard on-chain wallet. For everyday payments, Lightning can be a useful complement to Bitcoin’s base layer—as long as users understand what their wallet controls and how their funds can be recovered.