No block, no confirmation, no permanent record. And yet nobody along the way can take a single sat. Lightning's security does not come from writing everything down. It comes from what each side could write down at any moment.
Why does a bar run you a tab instead of charging your card for every single beer?
Because settling is the expensive part. The drinks are quick; the paperwork is not. So the bar writes your drinks on a slip and settles once, at the end.
Bitcoin has the same problem, magnified. Every on-chain payment is written into a ledger that thousands of computers store forever, and the whole planet shares about five transactions per second of space in it. Visa alone averages around 7,500. Buying coffee on the blockchain means bidding for a seat in a small global auction, ten minutes at a time.
Lightning's answer is the tab. Two people lock some bitcoin into a shared pot with one on-chain transaction, then pass value back and forth between themselves as fast as they can send a message. One more on-chain transaction, whenever they choose, settles the final score. Everything in between touches no block at all. Try it:
The last number never changes. One transaction opened this tab; one will close it. Everything in between is just the two of you agreeing on a new split.
Notice what moved and what did not. The split of the pot changes with every coffee. The pot itself sits still on the chain, in one unspent transaction, the entire time. Lightning does not move bitcoin around. It renegotiates who owns a shared pot, instantly and as often as you like.
Which raises the only question that matters: this tab lives outside the blockchain, so what stops the shop from simply keeping all of it?
If the money sits in a shared pot, what stops the other side from walking away with it?
Start with the pot. The opening transaction pays into an address that needs both signatures to spend. Neither of you can touch the money alone. That solves theft and creates a new problem: if your partner disappears, the money is stuck forever. A shared lock is just a shared hostage.
So Lightning adds the crucial piece. Before the pot is even funded, both sides sign a commitment transaction: a fully valid Bitcoin transaction that spends the pot and pays each side its current balance. You hold it. You do not broadcast it. It is a signed exit sitting in your pocket, and you can use it at any moment without asking anyone.
Every payment is just a new version of that exit. Buy a coffee and the two of you sign a fresh commitment paying you 4,500 less and the shop 4,500 more. The channel is the latest signed exit. Watch the exit get rewritten:
Each update follows the same little dance:
If the shop vanishes tomorrow, you broadcast your latest commitment and collect your balance on-chain. No permission, no customer support, no counterparty required. That is why a Lightning channel is not an IOU: an IOU is a promise, a commitment transaction is a signed fact.
But step three should bother you. Old commitments are still perfectly valid Bitcoin transactions. You kept copies. Somewhere in your pocket is version #1, the one where you still had all your money.
What happens if you broadcast an old commitment, from back when you had more money?
The blockchain cannot help here. An old commitment is signed by both of you; to the chain it looks exactly as valid as the new one. Lightning's defence is not to make cheating impossible. It is to make cheating a catastrophically bad trade.
Two details in every commitment transaction set the trap. First, your own payout is delayed: broadcast your commitment and your money sits frozen for a waiting period, typically up to two weeks, while your partner's side pays out normally. Second, that revocation secret you handed over in the update dance gives your partner a master key to your old commitments: if one ever appears on-chain, they can spend your frozen output instantly, before your delay expires.
Run both endings yourself. The channel holds 200,000 sats. Right now you have 40,000. Back at version #12, you had 150,000.
Sit with the arithmetic for a second. Cheating was an attempt to take 110,000 sats that belonged to your partner, and it cost you the 40,000 you honestly owned. The moment you handed over that revocation secret, the old state stopped being a lottery ticket and became poison in your own pocket.
This is the quiet reversal at the heart of Lightning. The blockchain is not Lightning's ledger. It is Lightning's courtroom: rarely visited, always available, and with the verdict pre-signed by both parties. Honest people never see the inside of it, which is exactly the point.
One tab with one coffee shop, secured. But you cannot open a tab with every shop on Earth. The next step is the one that turns tabs into a network.
You have a channel with B. B has one with C. C has one with the shop. How does your money cross two nodes you have no reason to trust?
The naive answer fails immediately: hand 25,000 sats to B and ask them to pass it along, and B's cheapest move is to stop passing. Lightning never lets that situation exist. No node along the path ever holds free money.
The trick is a lock made from a hash, the fingerprint function from our hashing explainer. The shop invents a random secret and puts its fingerprint H in your invoice. Then every hop on the path makes the same conditional promise: "this money is yours if you show me the secret behind H, before a deadline." Nobody can claim anything without the secret, and only the shop has it.
Here is the beautiful part: claiming the money is the same act as revealing the secret. The shop takes its 25,000 by showing the secret to C. Now C knows it, and uses it to collect from B. B collects from you. The payment settles backwards, like a zipper closing, and every hop is made whole in the same breath. If anyone refuses to play, the deadlines expire and every lock unwinds. The payment either completes everywhere or fails everywhere. Watch it, with a real secret and real SHA-256 locks:
Two things worth noticing. The deadlines shrink toward the destination, so a middle node always has more time to collect its incoming money than it gave the next hop: it can never be left holding the bag. And the route travelled inside layered encryption, like a series of sealed envelopes: B knows only who handed it the payment and where to send it next. It does not know whether you were the origin, or whether the shop was the destination.
That is the whole network. Thousands of tabs, stitched together by hash locks, with nobody trusted and nobody in charge. Your payment crossed three channels, updated three pairs of commitment transactions, and the blockchain slept through all of it.
This has all been theory holding hands with mathematics. When did it actually go wrong in public?
In the late summer of 2019, Rusty Russell, one of Lightning's original specification authors, quietly told node operators to upgrade immediately. The full story came out that September as CVE-2019-12998, -12999 and -13000: one bug, independently present in all three major Lightning implementations.
The bug was not clever mathematics. It was a missing look. When a partner said "our channel is now funded, here is the transaction," vulnerable nodes did not properly check the blockchain to confirm that transaction actually paid the right amount to the right two-signature address. An attacker could announce a channel backed by a transaction that paid the wrong script, or the wrong amount, or paid themselves. The victim's node showed a healthy channel. The money behind it did not exist.
Then the attacker "pays" you through the phantom channel, you hand over real goods or route out real sats, and when the channel finally closes you discover the chain owes you nothing. The bug was exploited in the wild before everyone patched. The sums lost were small. The lesson was not.
Notice what failed and what held. The protocol's design was fine; the penalty mechanism was fine; the hash locks were fine. What failed was software skipping the single most Bitcoin instruction there is: don't trust, verify. The chain had the truth on display the entire time. The vulnerable nodes just didn't look.
It rhymes with everything else in this series. The maths almost never fails. Implementations fail, checks get skipped, randomness runs dry. Which is why the fix was boring and effective: patch, and look at the chain.
So what does it cost to move money across this thing?
Routing nodes earn fees for the liquidity they provide, and the fees are set by a market, not a company. A typical node charges a flat base fee, often a single sat or nothing, plus a proportional rate measured in parts per million. Not percent: parts per million. A node charging 300 ppm takes 0.03%.
Play with a route. The comparison rows update against the same amount:
| Rail | Fee | Share of the payment |
|---|---|---|
| Lightning, this route | — | — |
| One on-chain transaction | — | — |
| Card processing | 2.9% + $0.30 | 2.9%, before the fixed part |
Base fee assumed 1 sat per hop; on-chain assumes a typical 141-vbyte transaction. The card row ignores its $0.30 fixed component, which makes small payments dramatically worse for cards, not better.
The shape of the result matters more than any single number. On-chain fees are flat per transaction, so they crush small payments and vanish into large ones. Card fees take their percentage forever. Lightning fees are typically a few hundredths of a percent, and they get cheaper as the network gets denser.
The catch is that a channel is not a bank balance, it is a tube with money on both ends. You can only push out what sits on your side, and you can only receive what sits on the other side. That far side is called inbound liquidity, and for a merchant it is the scarce resource: a shop expecting a million sats of sales needs partners willing to commit a million sats toward it. There are open marketplaces where nodes buy and sell exactly that.
The public network today: tens of thousands of channels between thousands of nodes, holding several thousand BTC of announced capacity. Nobody knows the true size, because private channels never announce themselves. The public part is fully inspectable by anyone, live, at amboss.space.
Instant, nearly free, no trusted middleman. What's the catch?
Vigilance. The penalty system from section three only works if someone is watching the chain for stale commitments. On the base layer your keys can sleep in a vault for a decade. On Lightning, your money is safe because someone can respond in time, and that someone is you, or a watchtower you hire to watch on your behalf.
| What's affected | Status |
|---|---|
| Sending and receiving payments | |
| Money already parked in your channels | |
| Catching a cheater's old state in time |
Be honest about the rest of the bill, too. Big payments can fail to find a route and need to be split across paths. Receiving requires being online, which is why your phone wallet cannot receive while it sleeps. And the most popular shortcut around all of this is a custodial wallet, where a company runs the node and holds the keys. It works beautifully, and it quietly reintroduces everything Lightning was built to remove: an account, a password, and a party you must trust. Our signatures explainer is one long argument about how that trade tends to end.
None of this is fatal, and all of it is being engineered at: multipath payments, async receive, better watchtowers. But a reader of this series deserves the honest version: Lightning trades the blockchain's total passivity for speed, and pays for it with an attention requirement.
Know which kind of wallet you are holding. A self-custodial Lightning wallet gives you a signed exit nobody can take away. A custodial one gives you an account at a company. Both have their place; confusing them is how people get hurt.
Your safety budget is attention, not just keys. Keep your node online, or hire a watchtower, and treat the penalty window like the hard deadline it is. A channel is a hot wallet: fund it like one.
Update your node software promptly. The one public failure in this story was a skipped verification step, patched months before some operators applied it. The maths held; the laggards paid.
Look at the network yourself. The public graph, every announced channel and its capacity, is open for inspection at amboss.space. The entire system is auditable by anyone. That only matters if someone actually audits, and there is no reason it should not be you.