How does the Lightning Network work?

Bitcoin can be impractical as a payments network because transactions on the base layer can be slow and fees can spike when the blockchain is congested. Most people treat BTC as a store of value rather than everyday money, but “payments” is still the original sales pitch.

The Lightning Network (LN) is a Layer 2 protocol proposed to move many payments off-chain, settling only occasionally back to Bitcoin.

The intent is legitimate. The execution is... complicated.

This post explains LN in plain language, then updates the state of LN in 2026, including the reasons it still doesn’t magically become “Visa on Bitcoin”.

The basics (what LN is trying to do)

The Lightning Network was described in the classic paper by Joseph Poon and Thaddeus Dryja: The Bitcoin Lightning Network.

At the core is a simple trick:

• Alice and Bob lock some BTC into a shared setup on-chain (a channel)
• inside that channel they can update balances many times off-chain
• only the final result gets published on-chain when they close the channel

This is done using bidirectional payment channels backed by on-chain enforceability.

The protocol details are standardized in the BOLTs (Basis of Lightning Technology), which define how nodes talk to each other and route payments.

What a payment channel really is

A Lightning channel is not “magic off-chain money”. It’s a contract-like agreement backed by Bitcoin transactions.

The simplified mental model:

• open a 2-of-2 multisig between two parties
• both parties hold “exit transactions” that can close the channel
• the latest signed state is the one that should win

This part is reasonable.

The complexity comes from preventing cheating when one side tries to publish an old state.

The classic Alice/Bob walkthrough (still useful)

My original post on the old blog site used a simple story: Bob pays Alice 0.1 BTC per article, repeatedly, without spamming the base chain.

I’ll keep the same high-level flow because it’s still the right intuition.

Step 1: Open the channel on-chain

Bob creates an on-chain transaction that locks BTC into the channel.

Step 2: Both parties sign the channel setup

Alice signs, and the channel becomes real on-chain.

The core distinction still matters:

• signing an off-chain update = agreement, not on-chain
• broadcasting = publishing to the blockchain and settling

Step 3+: Update balances off-chain

Each time Bob “pays” Alice, they sign a new state reflecting the updated balance split.

The “latest signed state wins” is the whole concept.

What routing adds (and why it’s hard)

LN’s promise is not just “Alice and Bob can pay each other”, but:

Alice can pay Carol even if she doesn’t have a channel with Carol, as long as there’s a route through intermediaries.

That’s routing. It’s why LN is called a “network”.

But routing introduces constraints that don’t exist on the base layer:

• Channels have limited liquidity
• Liquidity is directional (you need the balance on the correct side)
• Paths can fail because the network can’t publicly prove where the liquidity is

Legacy diagram:

This is where LN starts to look like a payment network with fragmented pre-funded pipes rather than a universally liquid cash system.

What changed since 2018 (the honest 2026 update)

LN is no longer a toy. It works in the real world for many use cases.

Some measurable signals:

• Public channel capacity hit record highs around late 2025; trackers like Bitcoin Visuals and 1ML statistics publish rolling numbers (note: they only count public channels; private channels don’t gossip).
• LN implementations matured and diversified: LND, Core Lightning, Eclair, etc.
• “Watchtowers” exist in production as a mitigation for offline risk; Core Lightning explicitly supports BOLT13-compatible watchtowers (Core Lightning watchtower docs, and a draft BOLT13 spec exists: BOLT13 Watchtowers draft).

So yes: LN improved.

But the core criticisms didn’t vanish.

The critical parts (what still makes LN not a universal scaling solution)

1) Liquidity is a hard constraint, not a bug

LN payments require a path where every hop has sufficient liquidity in the right direction. This leads to:

• frequent payment failures for larger amounts
• constant need to rebalance channels
• incentive to use well-connected hubs

This is not “mathematically unsound” — it’s simply the consequence of trying to route value through pre-funded channels.

2) Jamming attacks are a real, long-standing issue

A major class of DoS attacks is channel jamming, where an attacker locks up liquidity along a route using unresolved HTLCs (payments-in-flight).

Bitcoin Optech keeps an up-to-date topic page on it: Channel jamming attacks.

There’s also academic work on probing/jamming and extracting channel balances (e.g. Biryukov et al., FC’22 preproceedings: Analysis and Probing of Parallel Channels in the Lightning Network).

These aren’t theoretical paper cuts. They affect reliability and push users toward custodial solutions that hide the pain.

3) Privacy is not "automatic"

LN can leak information in multiple ways:

• payment attempts can reveal constraints
• adversarial routing nodes can infer sender/receiver under some models

Example of research in this area: ETH Zürich work on LN privacy attacks (“Revelio”): PDF.

4) The penalty model still makes “offline forever” unsafe

Classic LN channels are “punishment-based”: if someone publishes an old state, the other side must react within a window, or they can lose funds. Watchtowers reduce that burden, but they introduce operational and trust tradeoffs.

The original “you must be online” critique is less absolute today, but it did not disappear — it got outsourced.

5) Centralization pressure is structural

Because of liquidity management and routing reliability, LN tends to grow hubs and large nodes. There is academic work describing this as a path toward centralization (e.g. topology studies like “Lightning Network: a second path towards centralisation…”).

In practice, the biggest UX wins often come from custodial wallets, which defeats Bitcoin’s original “be your own bank” pitch.

The “future fix” people still talk about: Eltoo / ANYPREVOUT

A long-standing improvement proposal for LN is eltoo, which changes how channel updates work and can simplify some of the penalty complexity.

Eltoo depends on a Bitcoin soft fork called SIGHASH_ANYPREVOUT (BIP-118): BIP 118 text and Bitcoin Optech’s explainer: SIGHASH_ANYPREVOUT.

As of mid-2025, multiple explainer sources still note that eltoo is not active because ANYPREVOUT hasn’t been deployed (one example: Lightspark’s eltoo glossary entry). If that changes, it’s a big deal.

Conclusion

Lightning is a clever protocol that can make Bitcoin payments faster and cheaper in many cases.

But it is not a free lunch:

• it trades global simplicity for local complexity
• it introduces liquidity and routing constraints
• it adds new attack surfaces
• it nudges users toward hubs and custody for good UX

So yes: LN works. But if someone is selling it as a mathematically guaranteed “global scaling solution”, they’re overselling.

If you care about self-custody, start with the basics: understand wallets and consider a hardware wallet. Layer 2 convenience is not worth it if you’ve turned Bitcoin back into a bank account - virtually all other solutions, including L2s of Ethereum, are faster, cheaper, more reliable, more secure, and support custom assets allowing you to execute payments in stable currencies we've grown accustomed to.