The Lightning Network is a second layer where bitcoin payments travel through pre-funded channels instead of on-chain transactions, settling in fractions of a second for fees measured in thousandths of a cent. A payment often crosses several nodes — none of which trusts the others — because each hop is locked to the same payment secret; if any hop fails, the whole path unwinds. Lightning's public channel capacity has stood in the low thousands of bitcoin in recent years, a small pool that turns over constantly.
Bitcoin Trader publishes information, not investment advice. Crypto payments carry risks and losses are possible; this explainer describes routing mechanics, not any product or service.
What is a payment channel?
Two parties open a channel with one on-chain transaction that funds a shared 2-of-2 multisig address — say one bitcoin split between them. Off chain, they then pass signed balance statements back and forth: first 0.7/0.3, then 0.6/0.4, and so on, each new statement invalidating the previous by construction. Every intermediate state could be broadcast on-chain, but never is; only the final one needs to be, when the channel closes.
The channel is a private ledger with a blockchain-enforced dispute process. Either party can close it unilaterally by broadcasting the latest state they hold, and protocol timelocks give the other side a window to publish a newer state if the closing party tries to settle on a stale one. Security does not depend on the counterparty staying honest — only on the watcher staying awake.
How does a payment cross nodes that do not trust each other?
Through HTLCs — hashed timelock contracts. The recipient generates a payment secret and hands its hash to the sender inside an invoice. The sender locks a payment to its neighbour against that hash with a timelock of, say, 40 blocks; the neighbour does the same one hop further with a slightly shorter lock, and so on to the recipient, each hop taking a small routing fee.
The recipient reveals the secret to collect, and the secret propagates backwards hop by hop, settling every contract along the path. Intermediaries never hold the sender's or recipient's funds freely — each one is either paid for a delivered payment or refunded when its timelock expires. The descending timelocks are the detail that makes cheating unprofitable: an intermediary cannot hold an earlier hop's money hostage without losing its own lock first.
Who decides the route?
Surprisingly, the sender. Lightning invoices carry the recipient's address in the network graph, and the sender's node runs pathfinding over the public gossip of channels, capacities and advertised fees — routing fees are quoted in parts per million plus a small base amount per hop. If a channel along the chosen path lacks capacity in the needed direction, the payment fails at that hop and the wallet automatically retries along another path.
Failed-then-retried payments are normal, not exceptional. Practical reliability numbers improve with well-connected wallets and with amounts that fit typical channel sizes; a payment of a few dollars routes easily, while moving thousands of dollars may take splitting across multiple paths — the protocol's version of billing in installments.
What happens when channels or nodes cheat?
The penalty is confiscation. If a node broadcasts an old channel state — attempting to claw back money it already spent — its counterparty (or a watchtower service watching on its behalf) can submit a justice transaction within the timelock and take the entire channel, not merely the disputed amount. The threat is designed to make honest closing the only rational strategy.
Watchtowers matter because the punishment requires someone to be watching. A wallet offline for months could miss a breach window, so users who cannot run always-on nodes delegate only the watching — watchtowers see channel hashes, not balances or identities. Trust is minimized, not eliminated: the design concentrates it in liveness rather than in any counterparty's honesty.
What is Lightning good and bad at?
Its strengths are small payments: fees near zero regardless of distance, instant settlement, and throughput bounded only by the machines routing, not by block space. Coffee, streaming micro-billing and cross-border remittances are the canonical use cases, and exchange withdrawals over Lightning reduce both fees and on-chain congestion.
The weaknesses are equally structural. Receiving requires inbound capacity — a channel must have bitcoin on the other side pointed toward you, which is why receiving more than you can route is a common first-week problem. Large payments outgrow channel capacity. And routing nodes must be online, which turns payments partly into an availability problem the base chain never has. Layer trade-offs are real: Lightning buys speed and cost by accepting constraints the base chain deliberately refuses.
How does Lightning relate to bitcoin's fee market?
As block-space demand pushes base-layer fees up, the economics of channel opens and closes shift too — every Lightning channel begins and ends as an on-chain transaction. High-fee periods make opening channels more expensive and therefore favour larger, longer-lived channels; cheap periods favour churn and small experiments. The two layers price each other, and wallet software that auto-suggests channel management during fee spikes is simply arbitraging that relationship.
What are inbound liquidity and channel management?
The most common first-week Lightning problem is being unable to receive: a fresh channel has all its capacity on your side, pointed outward. Spending pushes capacity toward the other party, and only then can payments flow back. Receiving capacity — inbound liquidity — is the scarce good, and an entire service layer has formed around supplying it: lightning service providers sell or lease channels pointed toward users, and some wallets hide the mechanics entirely by routing through provider-managed channels.
Channel management is the ongoing craft. Each channel locks capital that only earns when routed through, so professional node operators balance channel sizes against expected flow, rebalance periodically by pushing value around loops, and set routing fees to steer traffic. The network's public graph publishes channels, capacities and fees; the art is reading it well enough to keep a node profitable — a niche with real participants and real failure, exactly like market making on any other order book.
For users who never operate nodes, the practical translation is choosing between two models: self-managed channels, where fees and inbound are your problem and privacy is stronger, and custodial or provider-mediated wallets, where someone else runs the node and the trade is the familiar one — counterparty risk in exchange for convenience. The network does not distinguish between the two; the risk ledger does.
How private is a Lightning payment?
More than an on-chain transaction, less than the word 'private' promises. Each hop sees only its neighbors' channels and the hash lock it forwards — no intermediary learns both sender and recipient. But the recipient learns the preimage's origin path's first hop in some configurations, the public graph is transparent, and routing nodes can log what they carry. Payment proofs exist by design: the payment secret doubles as a receipt the recipient can present. Lightning shifts the visibility from 'everyone sees everything forever' to 'a few parties see fragments once' — a meaningful improvement over base-layer transparency and a categorical difference from anonymity.
For more context, read How Many Confirmations a Bitcoin Transaction Actually Needs.
For more context, read bitcoin transaction fees.
For more context, read What Happens When the Last Bitcoin Is Mined in 2140.
