The Lightning Network explained: fast, cheap bitcoin payments and their trade-offs
How bitcoin's Lightning Network uses payment channels for near-instant, low-fee payments, how channels open and close, invoices, custodial wallets and the risks.
Figures checked against 9 official and primary sources on . See the sources · How we check
Key points
- The Lightning Network is a payment layer on top of bitcoin. Bitcoin.org says payments are near-instant and typically cost less than a cent.
- It works through payment channels: two parties lock bitcoin on-chain, then update who owns what off-chain. Only opening and closing hit the blockchain.
- Channels link into a network, so payments can hop through intermediaries without trusting them, using conditional payments.
- Bitcoin.org calls Lightning well suited to small, frequent payments; on-chain bitcoin remains the standard for larger transfers and long-term storage.
In this guide
Bitcoin’s main blockchain is deliberately slow and limited: a new block about every ten minutes, and fees that rise when demand is high. That’s fine for moving large amounts or saving long term, but awkward for buying a coffee. The Lightning Network was built to handle that kind of payment.
This guide explains how Lightning works, in plain terms, what it’s good for and what to watch out for.
What Lightning is
Bitcoin.org describes the Lightning Network as a payment layer built on top of bitcoin. Payments are near-instant and typically cost less than a cent, using payment channels that settle back to the bitcoin blockchain. It’s well suited to small, frequent payments, while on-chain transactions remain the standard for larger transfers and long-term storage.
ethereum.org gives Lightning as an example of a layer 2: a system that handles activity off the main chain while relying on it for security. See what is a layer 2?
How a payment channel works
The Lightning specifications, known as BOLTs (“Basis of Lightning Technology”), describe a protocol for off-chain bitcoin transfers by mutual cooperation, relying on on-chain transactions for enforcement if necessary. Their introduction explains channels with an example:
- Open: two participants lock an amount of bitcoin, say 0.1 BTC, in an on-chain transaction that can only be spent with both their signatures.
- Pay: instead of broadcasting every payment, they sign a new transaction that splits the funds differently, for example 0.09 to one and 0.01 to the other, and invalidate the previous version.
- Repeat: they can update the split many times without touching the blockchain.
- Close: when they’re done, the latest split is settled on the bitcoin blockchain.
Bitcoin.org’s glossary summarizes it: channels open and close on the bitcoin blockchain, while payments between participants happen off-chain without each one being recorded individually.
From channels to a network
A single channel only connects two people. Lightning becomes a network by linking channels together, using conditional payments. The BOLT introduction gives an example: “you get 0.01 bitcoin if you reveal the secret within 6 hours”. Such a payment can be forwarded to the next participant with a shorter time limit, which lets payments travel through several channels without trusting the intermediaries.
A routed payment, step by step
The BOLT glossary explains the building blocks: a payment preimage, a secret known only to the recipient, and its payment hash. Conditional payments using them are called HTLCs (hashed time-locked contracts): the next node can claim the money by revealing the preimage, otherwise the payer can cancel after a set time. Suppose Alice pays Carol through Bob:
- Carol creates a secret and puts its hash in her invoice.
- Alice offers Bob a conditional payment: “this is yours if you show me the secret behind this hash; if not, I can take it back after a set time.”
- Bob offers Carol the same deal, for slightly less (Bob keeps a fee) and with a shorter time limit.
- Carol reveals the secret to claim Bob’s payment. Bob now knows it too, and uses it to claim Alice’s payment.
- Alice ends up holding the secret, which the BOLT glossary describes as proof that the payment was received.
The shorter time limit at each step protects intermediaries: Bob always has time to claim from Alice after Carol claims from him.
Privacy: onion routing
Payments travel in onion-encrypted packets (BOLT 4). Each intermediate node can check the packet and see which node to forward it to, but can’t learn the other nodes on the route, besides the one before and the one after it, nor the length of the route or its own position in it. The specification notes that this doesn’t rule out linking packets through traffic analysis.
Routing fees
Each node that forwards a payment can charge a fee, made up of a fixed base fee in millisatoshis plus a proportional fee set in millionths of the amount (BOLT 7). The specification’s own example: forwarding 4,999,999 millisatoshis (just under 5,000 sats) through a node charging 200 millisats + 2,000 millionths (0.2%) costs 10,199 millisats, about 10 sats.
Nodes tell each other about new channels and updates, so wallets can find a route, and the recipient issues an invoice saying how much to pay and where. Invoices can include an expiry; under the BOLT 11 standard, the default is one hour if none is set.
What if someone cheats?
Each party keeps a signed transaction that it can broadcast to close the channel on its own. The BOLT glossary describes three ways a channel can close:
- Mutual close: both agree, and the final balances are paid out. This is the simple, efficient route.
- Unilateral close: one side closes alone by broadcasting its latest transaction. It’s less efficient, and the side that broadcast it can’t access its own funds for a pre-agreed period.
- Revoked transaction close: if one side tries to cheat by broadcasting an old, revoked state, the other side can use a penalty transaction to claim all of the channel’s funds.
That penalty mechanism is what keeps channels honest. It also explains why the specification (BOLT 5) says that once a node has funds at stake, monitoring the blockchain is required, so it can respond if a counterparty tries to cheat.
Custodial vs non-custodial wallets
Lightning wallets come in two broad kinds:
- Non-custodial: your wallet holds the keys and its own channels. More control, more responsibility.
- Custodial: a company holds the bitcoin and runs the channels for you, and you see a balance in an app. Easier, but you’re trusting that company, much like an exchange. See hot vs cold wallets and what happens if an exchange goes bust.
What Lightning is good for, and not
Good for:
- small, frequent payments, such as tips or everyday purchases where merchants accept it;
- payments where speed matters;
- amounts so small that on-chain fees would be disproportionate. See satoshis and bitcoin’s units.
Less suited to:
- long-term savings, which bitcoin.org says remain the job of on-chain bitcoin;
- large transfers, where an on-chain transaction is standard.
Safety tips
- Start small while you learn how your wallet works.
- Back up your wallet exactly as its instructions say, and read them carefully: recovering a Lightning wallet can involve different steps from an ordinary bitcoin wallet. See seed phrase security.
- Check the amount and expiry on every invoice before paying.
- Don’t keep large sums in a custodial Lightning app.
- Beware of fake wallet apps. Download only from official sources. See fake crypto apps and phishing.
For more on bitcoin itself, see what is bitcoin? and bitcoin transaction stuck?
Frequently asked questions
Is Lightning a different cryptocurrency?
Why did my Lightning invoice expire?
Do I need to run my own node to use Lightning?
Can the nodes that forward my payment see who I'm paying?
How are Lightning routing fees worked out?
Are Lightning payments taxed differently?
Sources
- Frequently Asked Questions (What is the Lightning Network?) — Bitcoin.org
- Vocabulary (Lightning Network) — Bitcoin.org
- BOLT #0: Introduction and Index — Lightning Network specifications (lightning/bolts)
- BOLT #2: Peer Protocol for Channel Management (cltv_expiry_delta selection) — Lightning Network specifications (lightning/bolts)
- BOLT #4: Onion Routing Protocol — Lightning Network specifications (lightning/bolts)
- BOLT #7: P2P Node and Channel Discovery (HTLC fees) — Lightning Network specifications (lightning/bolts)
- BOLT #11: Invoice Protocol for Lightning Payments — Lightning Network specifications (lightning/bolts)
- BOLT #5: Recommendations for On-chain Transaction Handling — Lightning Network specifications (lightning/bolts)
- What is layer 2? — ethereum.org (Ethereum documentation)
First published . Spotted an error or an outdated figure? Tell us and we will check it against the source.