Lightning Network explained: how Bitcoin payment channels work

Why does Bitcoin need something like Lightning?#

Every ordinary Bitcoin transaction is broadcast to every node, stored in a block and checked by everyone. That is what makes Bitcoin trustworthy, but it also limits how many payments fit through. Blocks have a size limit — today 4 million weight units ^[3] — and arrive about every ten minutes, so space is scarce and users bid for it with fees.

The Lightning Network paper, published in draft in 2016, set out the problem with a comparison. It said Visa had reached 47,000 transactions per second at peak, while Bitcoin then supported fewer than 7. Matching Visa’s peak on-chain would need blocks of nearly 8 gigabytes every ten minutes — over 400 terabytes a year — which no home computer could handle, pushing validation into a few large hands ^[2]. The authors’ answer was to move most payments off the blockchain while keeping the blockchain as the final judge.

What is a payment channel?#

A payment channel is a private running tab between two people, backed by real bitcoin. To open one, the two sides create a funding transaction that sends coins to a 2-of-2 multisignature output — an output that can be spent only if both of them sign ^[2]. Before that funding transaction is broadcast, they each sign a commitment transaction that would pay each person their share if the channel closed right now ^[2].

From then on, every payment is just a new commitment transaction with updated balances, signed by both and kept, not broadcast. The paper stresses that these are real bitcoin transactions whose broadcast is deferred, not IOUs on a separate network ^[2]. Only the latest balance matters, and either side can publish it to the blockchain whenever they want to cash out.

The life of a Lightning channel

All 50 payments stay off-chain; only the opening and closing transactions use block space. A satoshi (sat) is 0.00000001 BTC. Single-funded channels like this are described in the Bitcoin Wiki’s Lightning glossary ^[1].

What stops someone from closing with an old balance?#

This is the clever part. In the coffee example, the café would never want to publish an early balance where Alice still had more money — but Alice might. If both old and new commitment transactions were equally valid, whoever was worse off under the latest balance would be tempted to broadcast an older one ^[2].

Lightning prevents this with a penalty. When the two sides agree a new balance, each hands the other a half-signed breach remedy transaction that cancels the old one ^[2]. Whoever publishes their own commitment transaction must wait before taking their share: the paper calls this lock a Revocable Sequence Maturity Contract (RSMC) and uses 1,000 blocks as its example ^[2]. If what they published was an old, revoked balance, the other side can broadcast the breach remedy during that waiting period and take all the money in the channel ^[2]. The Bitcoin Wiki calls this window the dispute period ^[1].

How can I pay someone I have no channel with?#

Opening a channel with every person you pay would defeat the purpose. Instead, payments are passed along a chain of existing channels: Alice → Bob → Carol. The risk is obvious — why would Alice trust Bob to forward the money? Lightning solves this with a Hashed Timelock Contract (HTLC), which combines a hash lock and a time lock ^[1]. The paper explains that a channel on its own only secures payments inside that channel; sending across several hops needs this extra contract ^[2].

1. Carol creates a secret

   She picks a random secret (the pre-image) and gives Alice only its hash, usually inside a payment request.

2. Alice pays Bob, conditionally

   Bob can claim the payment only by revealing the secret that matches the hash, and only before a deadline.

3. Bob pays Carol, on the same condition

   Same hash, but a slightly shorter deadline, so Bob always has time to claim from Alice after Carol claims from him.

4. Carol reveals the secret to get paid

   Revealing it to claim Bob’s payment hands Bob exactly what he needs.

5. Bob uses the secret to claim from Alice

   Either every hop completes, or the deadlines pass and every payment is cancelled.

Because each hop uses the same hash, Bob cannot take Alice’s payment without paying Carol ^[1]. In the paper’s worked example, Alice pays Dave through Bob and Carol: Alice’s HTLC with Bob expires after 3 days, Bob’s with Carol after 2 days and Carol’s with Dave after 1 day ^[2]. Each later hop has a shorter deadline, so every intermediary can still claim from the previous hop after paying the next one ^[2]. The paper adds that real deadlines should be set in block heights rather than days, with 3 days equal to 432 blocks ^[2].

From section 8.1 of the Lightning Network paper (Poon and Dryja, 2016). The paper equates 3 days with 432 blocks, which is 144 blocks a day at one block per ten minutes.

For privacy, the sender wraps the route in layers of encryption, like an onion. Each intermediary learns only the previous hop and the next one, not who started the payment or where it ends — unless intermediaries compare records ^[1].

How is Lightning different from a normal Bitcoin transaction?#

Summarised from the Bitcoin Wiki’s list of Lightning features and the Lightning Network paper.

The wiki lists the main benefits: rapid payments within an established channel, no third party controlling funds, reduced load on the blockchain because only opens, closes and rare anti-fraud transactions are recorded, and channels that can stay open indefinitely as long as both sides cooperate ^[1]. It even describes probabilistic payments for amounts smaller than one satoshi: a 1-satoshi payment that happens with 10% odds is worth 0.1 satoshi on average ^[1].

How big is the Lightning Network?#

Size figures for Lightning come from data services that track the network. One of them, mempool.space, publishes a statistics snapshot; its latest entry, dated 30 August 2026, counted 16,222 nodes and 32,511 channels ^[4].

Total capacity is the bitcoin locked in those channels: 375,362,393,018 sats, or about 3,753.62 BTC at 100,000,000 sats per bitcoin ^[4]. Treat these numbers as a dated snapshot from one data provider, not a live or complete count. The median channel is much smaller than the average, so a typical channel holds far less than the average suggests ^[4].

Routing is not free. The paper describes Lightning fees as separate from blockchain fees and paid directly between participants within a channel ^[2]. They pay for tying up channel funds for a set time and for the risk that a counterparty stops responding ^[2].

How does Lightning relate to the SegWit upgrade?#

The original paper needed a change to Bitcoin so that a transaction could be safely spent before it was signed and broadcast; without one, a channel’s funds could be held hostage during setup ^[2]. The SegWit specification, BIP141, addresses transaction malleability in a different way. It makes non-intentional malleability impossible and allows chains of unconfirmed transactions without counterparty risk — which it names as an important feature for off-chain protocols such as the Lightning Network ^[5].

What are the risks and limits for a beginner?#

• You must stay alert, or delegate. A counterparty who broadcasts an old state can keep the money if you miss the dispute period ^[1].
• Backups matter. The paper warns that when one party loses data, the counterparty may be able to steal funds ^[2]. Even advanced channel designs do not remove the need for watchful online behaviour or backups, as the wiki puts it ^[1].
• Capacity is limited. You can only send what is on your side of a channel, and a route only works if every hop has enough balance in the right direction. A channel with nothing left on one side is called exhausted ^[1].
• Closing without the other side is slower. Cooperative closes can happen immediately; non-cooperative ones take longer ^[1].
• Privacy is good, not perfect. Onion routing hides the endpoints from each hop, but intermediaries that compare records can learn more, and some features can link payments ^[1].
• Routing nodes are hot wallets. Nodes that forward payments must keep their keys online, so the paper advises them not to hold large amounts that way ^[2].
• Mass forced closures are a system-wide risk. The paper calls the forced expiration of many transactions possibly the greatest systemic risk: if a malicious participant forced many channels to expire at once, the transactions could overwhelm block space and delay others until their time locks run out ^[2].

What mistakes do beginners make here?#

• Thinking Lightning is a different coin

  Lightning moves ordinary bitcoin. Channel balances are backed by bitcoin locked in an on-chain output.

• Treating a Lightning node like a full node

  A Lightning node is a wallet with open channels; it is not the same thing as a Bitcoin full node that validates blocks, although one computer can run both ^[1].

• Leaving a self-custody Lightning wallet offline for months

  If your counterparty publishes an old state while you are away and nobody is watching for you, you can lose funds.

• Ignoring where the keys are

  A custodial Lightning app is convenient but carries the same counterparty risk as leaving coins on an exchange.

Frequently asked questions#

The bottom line#

Lightning keeps Bitcoin’s blockchain as the court of final appeal while letting everyday payments happen between the parties who care about them. Channels hold real bitcoin, routed payments are protected by hash locks and staggered deadlines, and cheating with an old balance is punished.

The price is responsibility: watch your channels or delegate that job, keep backups, and understand whether your wallet is custodial. For the on-chain side of the story, read how Bitcoin transactions work and what a UTXO is.

Sources#