How the Lightning Network actually works

“Bitcoin is too slow to be money”.

The Bitcoin network gets a lot of stick for supposed lack of speed. Sceptics highlight that Bitcoin can handle roughly seven transactions per second, and contrast this with Visa’s ability to process tens of thousands per second. Fans of some new cryptocurrency (or “altcoin”) will often point to its speed as proof it leapfrogs Bitcoin toward becoming practical digital cash.

These comparisons are misguided. Visa is a private credit network sitting atop the slow, central-bank settlement layer that Bitcoin sets out to replace; the meaningful comparison is to those central banking rails, not the plastic in your wallet (a case Parker Lewis makes well). What’s more, the pace of Bitcoin’s base layer is actually the price of its core characteristics. Once you understand what the slowness buys, the interesting question becomes “how do you build something fast on top of Bitcoin?”

That “something” is Bitcoin’s first Layer 2 network, or L2: the Lightning Network. In this guide I’ll show you how it works from the ground up, using interactive diagrams - we’ll open a single channel between two people, scale it into a network, and route a payment through it ourselves, liquidity constraints and all.

1. A deliberately slow settlement layer
2. The payment channel
3. Channels in action
4. Paying a stranger
5. The liquidity puzzle
6. Slow on purpose

1. A deliberately slow settlement layer

Bitcoin’s base layer does one job, and it does it exceptionally well: maintaining a single shared history that everyone agrees on and no one can rewrite. It achieves this by having every full node - tens of thousands of them distributed worldwide - independently check and store every transaction ever made. No node trusts any other, each verifies the rules for itself, and anyone can run a node.

That redundancy provides security, but it comes at a price. You can’t maximise security, decentralisation, and scalability all at once - the so-called “blockchain trilemma” - and Bitcoin deliberately prioritises the first two. Bigger or more frequent blocks would make running a node more expensive, until only a few well-funded operations can keep up. Eventually you’ve recreated the legacy model and reintroduced trusted intermediaries.

So, the base layer optimises for verification by everyone and accepts low throughput as the cost. It’s less a payment network than a settlement network: the final court of record where transactions become permanent.

You don’t speed up a court by holding more trials per second. You handle the everyday business elsewhere and settle up when it matters. In other words, you build a second layer network on top of Bitcoin.

2. The payment channel

Let’s start with two people who pay each other constantly: me and my favourite coffee shop. Broadcasting to the entire world every time I buy an Americano is clearly wasteful, not least because I’m asking every node globally to keep a permanent record of those transactions in their finite storage.

Instead, let’s open a payment channel.

To do this, the coffee shop and I lock some bitcoin into a shared address that requires both of our signatures to spend from - a 2-of-2 multisig. This takes a single on-chain transaction, and in practice it’s usually one party who funds it (remember that detail for later). The amount we lock is the channel’s capacity, and it doesn’t change for as long as the channel stays open.

With the funds locked, the two of us can transact directly without touching the chain. We update the running balances by signing a new split between us: “another Americano, that’s 5,000 sats deducted from my side and added to yours.” Each new balance is a valid transaction that could be broadcast to settle on-chain - but isn’t. We can do this thousands of times, instantly, for free, without telling anyone. The base layer sees a channel opening and, eventually, a channel closing (settling up). Everything in between is private and costs next to nothing.

One detail matters more than all the rest, and it’s called liquidity. It’s easiest to grasp with a visual example - I’ve switched to Alice and Bob as the names, instead of me and the coffee shop, because this is a serious website.

As you can see, a channel’s capacity is split between the participants, and the split has a direction: Alice’s balance is the ceiling on what she can send to Bob. Every payment shifts the split, and a channel can end up heavily weighted to one side if funds mostly flow one way. A channel’s liquidity, then, has a direction as well as a size.

The channel above has a total capacity of 200,000 sats. The sats on Alice’s side - 150k - are outbound liquidity (what she can send). The sats on Bob’s side - 50k - are Alice’s inbound liquidity (what she can receive). Make a payment and the split shifts, but the total holds. The two figures always sum to 200k, because that’s the amount locked in the funding transaction on-chain.

3. Channels in action

A static diagram only gets you so far. Here’s the same channel, made fun. You’ll see how it’s a bit like an abacus:

Send some payments back and forth, and watch what happens: the Transactions counter climbs with every click, but on-chain transactions stays at one. That single transaction was the channel opening; everything since has been nothing more than Alice and Bob agreeing on a new split. The sats slide along the channel, the balances update, and the chain hears nothing.

That’s the whole efficiency argument, shown visually: an unbounded number of payments for the cost of two on-chain transactions. Multiply that across millions of channels and the throughput ceiling we opened with effectively becomes a non-issue.

4. Paying a stranger

A channel is perfect for two parties who transact often. But you can’t open one with everyone you might ever pay - that would mean an on-chain transaction, and locked-up capital, for every relationship in your life. Impractical.

Alice has no channel with Carol. But she has one with Bob, and Bob has one with Carol - so Alice can pay Carol through Bob: he receives her sats on one channel and sends the same amount on to Carol on the other. The sats pass through Bob without ever really being his. This is the leap that turns a pile of separate channels into a network.

Pick any sender and recipient and send a payment. The route lights up hop by hop, and the dots redistribute as each intermediary’s balances shift:

Notice that no sats are ever created or destroyed - they just move from one side of a channel to the other. The network’s total liquidity is fixed; payments only shuffle it around.

The obvious worry is trust: in our Alice-to-Carol example, why won’t Bob just pocket the money? Because the payment is atomic: either every hop along the route completes, or the whole thing unwinds and nobody moves a sat. No intermediary can keep funds it didn’t pass on.

This is enforced with a hash time-locked contract, or HTLC:

• Carol, the recipient, invents a secret and gives Alice only its hash - a fingerprint of the secret.
• Alice locks her payment to Bob with a condition - claim this once you can reveal the secret behind this fingerprint - and Bob locks his payment to Carol the same way.
• To take her money, Carol must reveal the secret, which hands Bob the proof he needs to claim from Alice. The secret zips back up the route, settling each hop in turn.

If Carol never claims, every lock simply expires (the time-locked part of the name) and the funds return home.

Bob doesn’t forward payments out of kindness, either. Each hop keeps a small routing fee - often just a sat or two - for its trouble. The fee sounds trivial, but it’s what makes the network function: it’s the reason anyone locks up capital in channels and keeps liquidity available for strangers’ payments to flow through.

5. The liquidity puzzle

If you route enough payments in my last example, you’ll eventually run into a snag: “no route available”. You might assume it’s because Bennet’s built a clunky demo, but it’s actually the thing that makes Lightning genuinely hard!

A path between two nodes is not yet a route. Every hop needs enough balance in the right direction to carry the payment. A channel can be wide open one way and bone dry the other. Two nodes can be directly connected and still unable to pay each other, simply because the liquidity is sitting on the wrong side.

So connectivity isn’t enough. Below, your job is to get 30,000 sats from Alice to Carol. The direct path is right there - but the balances are working against you. Tap the nodes to try various routes.

The direct-looking route fails because one hop doesn’t have its sats pointed the right way - and you can’t tell which hop just by looking at the shape of the network. The route that works is longer and harder to spot: it only appears once you account for who holds what, and where.

That’s the core challenge of the Lightning Network in miniature. At full scale it’s harder still: the network’s map is public - nodes, channels, and capacities are broadcast for anyone to see - but the split inside each channel is private. Your wallet can see where routes might exist, not which ones will actually work, so it has to probe: pick a promising route, try it, and fall back to the next when a hop turns out to be dry.

You’ll rarely notice any of this happening. Your wallet does it in seconds, every time you pay. What’s more, in many modern Lightning wallets - not to mention the networks being built atop Lightning - much of this complexity is completely abstracted away.

6. Slow on purpose

Remember the number we opened with: seven transactions per second, held up as Bitcoin’s fatal flaw.

Hopefully now you can see this in a different light. The base layer is slow on purpose, because being slow is inseparable from being verifiable by everyone, unstoppable, and final. It’s the wrong layer for buying my coffee, but exactly the right one for the net result of all those coffees to eventually settle to.

Lightning is the fast layer that sits on top of Bitcoin. It optimises for speed and cost; the base layer optimises for security and decentralisation. Neither has to compromise the other. And none of this is a retrofit, either - the direction of travel was visible almost from the start. In 2010, a year after Bitcoin launched and years before Lightning existed, Hal Finney - the recipient of the very first Bitcoin transaction - wrote:

“Bitcoin itself cannot scale to have every single financial transaction in the world be broadcast to everyone and included in the block chain. There needs to be a secondary level of payment systems which is lighter weight and more efficient.”

Lightning is one answer to Finney’s challenge, but it isn’t the only one - other Layer 2 designs strike different bargains between trust, cost, and convenience, and they’re the subject of a follow-up article I’m planning.

For now, the next time someone tells you Bitcoin is too slow to be money, you’ll know exactly what that slowness buys - and what’s been built on top of it.

Thanks for reading. If this made the Lightning Network click for you, a few sats - sent over Lightning, naturally - help keep these guides coming: