Course outline · 10 lessons
Lightning Network & Bitcoin Nodes

Lightning Network Explained: How Bitcoin Scales With Fast Payments

A cream cup and saucer beside an open charcoal bill folder containing three blank slips on pale stone.

The lightning network is a second layer built on top of Bitcoin: a way to send bitcoin in seconds, for small fees, without waiting for each payment to be written into a block. If you have followed Courses 1 through 3, you already know how Bitcoin transactions work on the base layer. This lesson explains how Lightning moves most payments off that base layer while still relying on it for security.

Lightning does not replace Bitcoin’s blockchain. It works alongside it. Think of a bar tab: you open a tab, order drinks all night, and pay once at the end instead of running your card for every drink. In Lightning terms, opening the tab is one on-chain transaction that locks some bitcoin, each round is a new balance that both sides sign, and paying the bill is one closing transaction, with one on-chain fee.

What Is the Lightning Network?

The lightning network is a network of payment channels: shared balances between two parties, each backed by bitcoin locked on the blockchain. It was described by Joseph Poon and Thaddeus Dryja in a paper dated January 2016, and its first software for Bitcoin’s main network appeared in 2018. Its aim is to let people pay each other many times while touching the blockchain only rarely, without handing their bitcoin to a company.

It relies on four building blocks, each explained in this lesson:

  • A shared address (2-of-2 multisignature): the two parties lock bitcoin in an address that needs both of their signatures to spend.
  • Commitment transactions: signed but unpublished transactions that record the current split of the channel. Either party can publish theirs at any time to take their share on-chain.
  • Revocation keys: a penalty that makes publishing an old, outdated split a losing move.
  • Hash Time-Locked Contracts (HTLCs): conditional payments that let a payment pass through several channels without anyone in the middle being able to keep it.

The result: two parties can pay each other thousands of times, and only two on-chain transactions are needed, one to open the channel and one to close it.

Why Bitcoin Needs the Lightning Network

Bitcoin adds a block roughly every ten minutes, and each block has a size limit (4 million “weight units”, set in BIP 141). In October 2026 that meant about 5,000 transactions per block and about 720,000 a day, or roughly 8 transactions per second for the whole world (blockchain.com). The limit is deliberate: every full node checks every transaction, and small blocks keep running a node affordable for ordinary people.

When more people want block space than there is room for, they bid against each other with fees (Course 3’s lesson on transaction fees explains how). Most of the time fees are low: in October 2026 the average was well under one dollar per transaction. But on the busiest days they jump. Using blockchain.com’s daily data, the average fee per transaction was about $56 on 22 December 2017 and about $128 on 20 April 2024. Paying for a coffee on-chain on such a day makes no sense.

Lightning splits the work. The blockchain becomes the settlement layer, used to open and close channels and for larger transfers; Lightning becomes the payment layer for everyday amounts. Payments inside a channel need no block at all, so their number isn’t limited by block space, only by how much bitcoin sits in channels and whether a route can be found.

How the Lightning Network Works

Payment Channels

A payment channel is a private balance between two parties. Both lock bitcoin into a 2-of-2 address on the blockchain. The amount locked is the channel capacity: the most that can ever sit on one side of the channel.

Once the channel is open, the two parties can move bitcoin back and forth as often as they like. None of these updates touch the blockchain. Each one is a new agreement, signed by both, about how the locked funds are split.

For example, Alice and Bob open a channel with 0.1 BTC capacity. Alice funded it, so the starting split is:

  • Alice’s balance: 0.1 BTC
  • Bob’s balance: 0 BTC

After Alice pays Bob 0.02 BTC:

  • Alice’s balance: 0.08 BTC
  • Bob’s balance: 0.02 BTC

The update happened in a moment. No miner processed it and no block was needed. A payment straight to your channel partner pays no routing fee.

Three stages of Alice and Bob's channel. 1 Open: Alice locks 0.1 BTC in a 2-of-2 address with one on-chain transaction, the funding transaction, so the split is Alice 0.1, Bob 0. 2 Pay, again and again: Alice pays Bob 0.02 BTC and both sign the new split, Alice 0.08, Bob 0.02; no miner and no block are involved. 3 Close: one closing transaction pays each of them their latest balance on-chain, 0.08 BTC to Alice and 0.02 BTC to Bob. Only the opening and the closing go into blocks on the blockchain.
Opening and closing a channel touch the blockchain; payments don’t. In between, Alice and Bob just sign a new split each time one pays the other. The total locked, the channel’s capacity, stays the same; only how it is divided changes.

Opening a Channel

Opening a channel takes one on-chain transaction, the funding transaction, which sends bitcoin to the shared 2-of-2 address. Before it is published, the two parties exchange keys and sign the first commitment transactions. That order matters: if your partner disappears the moment the channel opens, you can still publish your commitment transaction and get your money back.

Normally the funding transaction must be confirmed before the channel can be used. How many confirmations depends on the software; LND, for example, asks for 3 to 6 depending on the channel’s size (LND sample configuration). This is the one moment where you wait for the blockchain. A zero-confirmation channel skips the wait, but only when the side that didn’t fund it trusts the funder not to double-spend the funding transaction (BOLT 2); Phoenix opens channels this way (see Lightning Wallets Compared).

Off-Chain Transactions

Each payment inside the channel replaces the old split with a new one. Both parties sign a new commitment transaction showing the new balances, and the old one is cancelled through revocation:

  1. Alice wants to pay Bob 0.01 BTC.
  2. Both sign new commitment transactions with the new balances.
  3. Alice gives Bob a revocation key for her previous commitment transaction.
  4. Bob gives Alice a revocation key for his previous one.
  5. If Alice later publishes the old split, the one that gave her more, Bob can use her revocation key to claim all the funds in the channel as a penalty.

That penalty is why you don’t have to trust your channel partner: cheating risks losing everything in the channel.

Who Watches for Cheating?

The penalty only works if someone notices the old transaction on the blockchain in time. When a party publishes a commitment transaction, its own funds stay locked for a waiting period, so the other side has a window to respond. Someone has to be watching during that window: your own Lightning software, which does this while it is running and online, or a watchtower, a separate service that watches the blockchain for you and publishes the penalty if needed.

Alice publishes an old, revoked split of the channel, Alice 0.1 and Bob 0, which gave her more than the 0.08 she now owns. Bob holds Alice's revocation key for that old split. Once it is on the blockchain, Alice's funds stay locked for a waiting period. If someone is watching, Bob's node or a watchtower spots it in time, uses Alice's revocation key, and Bob claims all 0.1 BTC in the channel as a penalty. If nobody is watching, the waiting period ends, the penalty can't happen, and the old split stands.
Cheating risks everything in the channel, but only if someone is watching. An old split is revoked: if Alice publishes it, Bob can use her revocation key to take all the funds. His node, or a watchtower, has to spot it before her waiting period ends.

That is why node operators are told to keep their node online. On LND, the most common node software, the watchtower client is off until you turn it on. Our lesson on Lightning backups and watchtowers explains when you need one, and Lesson 4.8 shows how to switch it on.

Closing a Channel

There are two ways to close a channel:

Cooperative close: both parties agree and sign one closing transaction that pays each side its latest balance. It is the cheap, quick and normal way.

Force close: one party publishes its latest commitment transaction alone, usually because the other side is offline or unresponsive. It costs more in on-chain fees, and the party who closes must wait a set number of blocks before spending its share; that is the waiting period described above.

Either way, the final balances are settled on-chain and the bitcoin returns to ordinary, single-owner addresses. A force close usually needs two or more on-chain transactions instead of one, so it costs roughly twice as much in mining fees, or more. Our lesson on Lightning backups and watchtowers works out what opening and each kind of closing cost in sats.

Routing Payments Across the Lightning Network

You don’t need a channel with everyone you pay. A payment can be routed through other people’s channels, hopping from node to node until it reaches the recipient.

Suppose Alice wants to pay Dave. Alice has a channel with Bob, Bob with Carol, and Carol with Dave. The payment can go Alice → Bob → Carol → Dave, usually in a few seconds.

Two terms first. A hash is a fingerprint of some data: easy to compute from the data, practically impossible to reverse. The preimage is the original data behind a hash. Picture a padlock that only one key opens: Dave hands out the padlock (the hash) and keeps the key (the preimage).

Routing uses Hash Time-Locked Contracts (HTLCs), payments that unlock only with the key and expire after a deadline:

  1. Dave makes up a random secret (the preimage) and puts its hash in the invoice he gives Alice.
  2. Alice offers Bob an HTLC: “you get X sats if you show me the preimage of this hash within, say, 60 blocks; otherwise the money comes back to me.”
  3. Bob offers Carol a similar HTLC with a slightly shorter deadline.
  4. Carol offers Dave one with a shorter deadline still.
  5. Dave reveals the preimage to Carol and takes his payment.
  6. Carol uses the same preimage to take her payment from Bob.
  7. Bob uses it to take his payment from Alice.
Alice pays Dave through Bob and Carol. 1 Dave's invoice gives Alice a padlock, the hash; Dave keeps the key, the preimage. Going forward, each node offers the next a payment locked with that padlock: 2 Alice offers Bob one with a deadline of 60 blocks, 3 Bob offers Carol one with a slightly shorter deadline, 4 Carol offers Dave one with a shorter deadline still. Coming back, the key unlocks each payment in turn: 5 Dave reveals the key and takes his payment, 6 Carol uses the key to collect from Bob, 7 Bob uses it to collect from Alice. Either every hop completes or none does.
The padlocks go forward; the key comes back. Each node can only collect from the hop before it by showing the key, and it only learns the key when the hop after it is paid. So nobody in the middle can keep the money, and the shrinking deadlines give each node time to collect after paying out.

The payment is atomic: either every hop completes or none does. Nobody in the middle can keep the money, because they can only collect from the hop before them by revealing the preimage, which they only learn when the hop after them is paid. The shrinking deadlines give each node time to collect after paying out.

For privacy, Lightning uses onion routing, similar in idea to Tor: each node only knows the hop before it and the hop after it. Bob knows he received something from Alice and must pass it to Carol, but not that Dave is the final recipient. Nodes along the way do see roughly how much is being paid; Lesson 4.2 explains why.

The payment goes Alice, Bob, Carol, Dave. Bob's view covers only Alice, himself and Carol: he knows he received it from Alice and that he must pass it to Carol, and he sees roughly how much is being paid. Dave is outside Bob's view, drawn faded: Bob doesn't know that Dave is the final recipient. Each node only knows the hop before it and the hop after it.
Bob sees only his neighbours on the route. Onion routing hides where a payment ends: Bob knows he received it from Alice and that Carol is next, but not that Dave is the final recipient. He does see roughly how much is being paid.

Lightning Network Fees

Routing nodes charge a fee for forwarding payments, which pays them for locking up bitcoin in channels and staying online. Each node sets two numbers:

  • Base fee: a flat amount per forwarded payment, set in thousandths of a satoshi (a satoshi, or sat, is a hundred-millionth of a bitcoin).
  • Fee rate: a percentage of the amount, written in parts per million (ppm). 100 ppm is 0.01%.

A worked example with real numbers: in mempool.space’s most recent snapshot of the public network (30 August 2026), the median node charged a base fee of 0.5 sat and a rate of 100 ppm. A 10,000-sat payment that passes through two routing nodes pays each of them 0.5 + 1 = 1.5 sats, about 3 sats in total. A 100,000-sat payment over the same route pays about 21 sats. The average rate in the same snapshot was 824 ppm, so some routes cost several times more (mempool.space Lightning statistics).

A payment goes from you through routing node 1 and routing node 2 to the recipient. Each routing node charges a base fee of 0.5 sat plus 100 ppm of the amount, the median policy on the public network in August 2026. Paying 10,000 sats, each node takes 0.5 + 1 = 1.5 sats, about 3 sats in total. Paying 100,000 sats, each takes 0.5 + 10 = 10.5 sats, about 21 sats in total.
Every routing node on the way takes a small fee. At the median policy of August 2026 (0.5 sat plus 100 ppm, where 100 ppm is 0.01%), going through two routing nodes costs about 3 sats on a 10,000-sat payment and about 21 sats on 100,000. Some routes cost several times more.

Some wallets charge one all-in price instead. Phoenix, the beginner wallet this course recommends, charges 0.4% + 4 sat for every Lightning payment you send, routing included (Phoenix FAQ): 44 sats on a 10,000-sat payment. Phoenix hands each payment to ACINQ’s node, which finds the rest of the route and pays those routing fees out of that charge, so you don’t add the two. Opening and closing channels also cost on-chain fees, which change with demand for block space.

For more scenarios and ways to keep fees down, read our complete guide to lightning network fees.

Lightning Network Capacity and Growth

Lightning has run on Bitcoin’s main network since 2018. mempool.space’s snapshot of 30 August 2026 counted:

  • Public nodes: about 16,200
  • Public channels: about 32,700
  • Bitcoin locked in public channels: about 3,800 BTC
  • Median channel: about 2 million sats

These figures only cover the public network; many channels, including most of those held by phone wallets, are private and can’t be counted. What they tell you: a few thousand bitcoin spread over tens of thousands of channels is why small and medium payments route easily while very large ones can struggle.

You will try sending and receiving yourself in Lesson 4.4.

Lightning Network Limitations

Lightning has trade-offs every user should understand:

  • Receiving needs inbound liquidity: you can only receive as much as your channel partners have on their side. This confuses many newcomers and is covered in Lesson 4.2.
  • Being online: your wallet or node must be online to receive a payment, unlike an on-chain address, which receives whether or not your wallet is open. It also needs to come online regularly to watch for cheating.
  • Channel management: keeping channels useful in both directions takes attention and sometimes costs money. Wallets like Phoenix do this for you; on your own node it is your job (Lesson 4.8).
  • Large payments: very large payments may not find a route with enough liquidity.
  • Complexity and backups: Lightning has more moving parts than on-chain Bitcoin, and backing up a channel is not as simple as writing down a seed. Our lesson on Lightning backups and watchtowers explains what to keep.

Developers are working on these. Splicing lets a channel be resized with one on-chain transaction instead of closing it, and pathfinding keeps improving.

Key Takeaways

  • Lightning is a second layer on top of Bitcoin: payments move inside channels backed by bitcoin locked on the blockchain
  • A channel needs one on-chain transaction to open, one to close and one for each resize (splice); the payments in between are signed agreements between the two parties
  • Revocation keys make publishing an old balance a losing move, but only if your node or a watchtower is watching the blockchain in time
  • HTLCs let a payment cross several channels so that either every hop completes or none does
  • Routing fees are small: at the median policy in August 2026, about 3 sats for a 10,000-sat payment over two hops. Some wallets charge one all-in price instead (Phoenix: 0.4% + 4 sat per payment, routing included)
  • Channels close cooperatively (cheap, quick) or by force close (more expensive, with a waiting period)

Frequently Asked Questions

Is the lightning network safe?

Its design lets you get your money back without trusting your channel partner, but that protection has conditions. Your node, or a watchtower, has to see a cheating attempt before the waiting period runs out. A force close during a period of high on-chain fees can eat a large part of a small balance. You need the right backups (our lesson on Lightning backups and watchtowers explains which). And like all software, Lightning implementations have bugs: check our security advisories and keep your wallet updated. Well-tested lightning wallets handle most of this for you.

How much does it cost to use the lightning network?

A few sats in routing fees on small payments (see the worked example above), or your wallet’s own price if it charges one instead (Phoenix: 0.4% + 4 sat per payment sent, routing included), plus on-chain fees when a channel opens, is resized (spliced) or closes. Lesson 4.3 works through what a first deposit costs in Phoenix.

Do I need to run a node to use the lightning network?

No. Wallets like Phoenix and Zeus run small lightning nodes on your phone. Running your own full node gives you more control and privacy, and the option to route payments for others. Lesson 4.5 covers the reasons in detail.

Can the lightning network handle large payments?

It works best for small and medium payments. Large payments may not find a route with enough liquidity on every hop. Multi-path payments (MPP) help by splitting one payment across several routes. For very large transfers, an on-chain transaction is usually the better choice.

What happens if my channel partner goes offline?

You can force-close the channel by publishing your latest commitment transaction. Your share returns to you on-chain after a waiting period that your partner’s software set when the channel opened. With LND’s defaults it ranges from 144 blocks (about a day) for channels under about 1.2 million sats to 2,016 blocks (about two weeks) for the largest (LND sample configuration). In Phoenix it is 720 blocks, about five days, and ACINQ says to force-close only as a last resort because “high fees apply” (Phoenix FAQ). You never need your partner’s cooperation to recover your funds, but you do pay on-chain fees and wait.

Check Your Understanding

1. Alice and Bob have a channel. Alice publishes an old commitment transaction that gives her more than she now owns. What stops her, and what has to be true for that to work?

Answer

Bob holds the revocation key Alice gave him when that old balance was replaced. With it he can claim all the funds in the channel as a penalty. But Bob’s node, or a watchtower working for him, has to notice Alice’s transaction on the blockchain before her waiting period ends. If nobody is watching, the penalty can’t happen.

2. In a payment Alice → Bob → Carol → Dave, why can’t Bob keep Alice’s money without paying Carol?

Answer

Alice’s payment to Bob only unlocks with the preimage, the secret behind the hash in Dave’s invoice. Bob only learns that secret when Carol reveals it to collect her own payment from him, and Carol only learns it when Dave is paid. So Bob can only collect from Alice after the payment has gone through. If it never does, Alice’s HTLC expires and her money returns to her.

3. You send a 100,000-sat payment through two routing nodes that both charge 0.5 sat plus 100 ppm. Roughly how much do you pay in routing fees?

Answer

Each node charges 0.5 sat plus 100 millionths of 100,000 sats (10 sats), so about 10.5 sats each and about 21 sats in total. A wallet like Phoenix charges its own all-in price instead (0.4% + 4 sat, routing included), which on this payment would be 404 sats.

Practical guides