Lightning Network & Layer 2

Lightning Network Explained for Bitcoiners

Jan 30, 2026 · 19 min read · Updated Latest correction
Stone blocks joined by fine threads with small ceramic beads, a physical editorial metaphor for linked payment channels.

Why Bitcoiners Need to Understand Lightning

In October 2026 Bitcoin’s base layer carried about 5,000 transactions per block, roughly 8 per second for the whole world; Visa says its network can process more than 65,000 transaction messages per second. This gap is not a flaw — it is a deliberate design choice that preserves decentralization and security. The Lightning Network exists to bridge this gap without compromising what makes Bitcoin valuable in the first place.

If you already hold bitcoin and understand its base layer, Lightning is the next piece of critical infrastructure you need to grasp. It is not an altcoin, not a sidechain, and not a competitor. It is Bitcoin’s native scaling solution, built directly on top of the protocol you already trust.

Payment Channels: The Foundation

The Lightning Network is built on payment channels — bilateral agreements between two parties to transact off-chain. Here is how they work at a fundamental level:

  1. Channel Opening: Two parties create a 2-of-2 multisignature transaction on the Bitcoin blockchain, locking funds into a shared address. This funding transaction is the only on-chain transaction needed to establish the channel.
  2. Off-Chain Updates: Once the channel is open, both parties exchange signed commitment transactions that reflect the current balance distribution. These transactions are valid Bitcoin transactions that could be broadcast, but they stay off-chain as long as both parties cooperate.
  3. Channel Closing: When either party wants to settle, the channel is closed on-chain. A cooperative close is a single new closing transaction that both parties sign, paying each side its latest balance at once. A unilateral close (force-close) is one party publishing its latest commitment transaction alone, with its timelock conditions.

The key innovation: thousands of off-chain balance updates happen between two on-chain transactions. Each update is cryptographically secured and enforceable on the Bitcoin blockchain if needed.

Three stages of Alice and Bob's channel. 1 Open: Alice funds it, so the split starts all hers and Bob has 0; the bitcoin goes into a 2-of-2 address that needs both signatures to spend, with one on-chain transaction, the funding transaction. 2 Update, again and again: each payment is a new commitment transaction showing the new split, signed by both; it is valid but kept off-chain, and the older ones are revoked. No block is needed for any update. 3 Close: in a cooperative close both sign one closing transaction and each is paid at once; in a force close one side publishes its latest commitment alone and its own share waits out a timelock. Either way the close goes on-chain, so only the opening and the closing touch the blockchain.
Thousands of updates, two transactions on the blockchain. Opening and closing are on-chain; every payment in between is a new split that both sign and keep. Closing together is quick and cheap; closing alone means waiting out a timelock.

How Routing Creates a Network

A single payment channel between two people has limited utility. The real power emerges when channels connect into a network. If Alice has a channel with Bob, and Bob has a channel with Carol, Alice can pay Carol through Bob — without Alice and Carol ever opening a direct channel.

Hash Time-Locked Contracts (HTLCs)

Routing payments through intermediaries requires a mechanism that guarantees atomicity: either the entire multi-hop payment succeeds, or none of it does. HTLCs provide this guarantee:

  1. The recipient (Carol) generates a random secret (preimage) and shares its hash with the sender (Alice).
  2. Alice creates an HTLC with Bob: “I will pay you X sats if you can produce the preimage of this hash within T blocks.”
  3. Bob creates a similar HTLC with Carol, using the same hash but a shorter timelock.
  4. Carol reveals the preimage to Bob to claim her payment. Bob now knows the preimage and reveals it to Alice to claim his payment.

This chain of conditional payments ensures that either everyone gets paid or no one does. The decreasing timelocks give each node in the middle time to collect from the hop before it once the hop after it has been paid. If the preimage never arrives, each HTLC expires at its deadline and the money returns to whoever offered it.

Alice pays Carol through Bob. 1 Carol's invoice gives Alice a padlock, the hash; Carol keeps the key, the secret or preimage. 2 Alice offers Bob a payment locked with that padlock. 3 Bob offers Carol one with the same padlock and an earlier deadline. 4 Carol shows Bob the key and collects her payment. 5 Bob shows Alice the key and collects from her. Below, two deadlines counted in blocks from now: Bob's payment to Carol expires earlier than Alice's payment to Bob. The gap is Bob's margin: once Carol collects, he still has time to collect from Alice. If the key never comes, each payment expires at its deadline and the money goes back. Everyone is paid, or no one is.
The padlocks go forward; the key comes back. Bob can only collect from Alice by showing the key, and he only learns it when Carol collects from him. The earlier deadline on his payment to Carol leaves him time to do that before Alice’s expires.

Onion Routing for Privacy

Lightning payments use onion routing, inspired by Tor. Each routing node only knows its immediate predecessor and successor in the payment path. Bob knows Alice sent him a payment to forward to Carol, but in a longer route, intermediary nodes usually cannot determine the original sender or final recipient. Every hop does see roughly how much is being paid.

This provides meaningful privacy advantages over on-chain Bitcoin transactions, where the entire transaction graph is publicly visible. Lightning routing nodes see individual hops, not complete payment flows.

Lightning vs On-Chain: When to Use Each

Use CaseBest OptionWhy
Buying coffee ($5)LightningInstant settlement, fees of a cent or two at most
Monthly DCA purchaseEitherDepends on exchange and withdrawal method
Large savings transfer ($10,000+)On-chainNo channel capacity limits, permanent settlement
Recurring subscriptionsLightningMicropayments, no minimum thresholds
Cold storage depositsOn-chainDirect UTXO ownership, no channel management
International remittancesLightningNear-zero fees, instant settlement across borders
Point-of-sale paymentsLightningInstant confirmation required for commerce
Inheritance setupOn-chainLong-term storage, no active management needed

The mental model: on-chain Bitcoin is your savings account (final settlement, large amounts, infrequent transactions). Lightning is your checking account (daily spending, fast, cheap). Both are Bitcoin. For a broader view of how Lightning fits into Bitcoin’s scaling trajectory, see our analysis of Lightning Network scaling challenges.

Two accounts, both bitcoin. On-chain is your savings, for large amounts moved rarely; Lightning is your spending money, for small amounts paid in seconds. Opening a channel moves money in and closing it moves money back, each with a mining fee. Below, a scale of payment sizes in sats, each step ten times the one before: a $5 coffee is about 6,600 sats; the median public Lightning channel held about 2 million sats in August 2026; a $10,000 transfer is about 13 million sats. Lightning works best up to about 1 million sats; from there to about 10 million, which takes in the size of a typical channel, it depends; above that, on-chain works best. The reason: each channel's capacity is split between its two sides, so a payment has to find a route where every channel has enough on the sending side, or be split across several routes. Dollar amounts at about $76,000 per bitcoin, November 2026.
On-chain is your savings; Lightning is your spending money. A coffee fits easily through a typical channel; a $10,000 transfer is bigger than most channels, and on-chain the fee depends on the transaction’s size in bytes, not on the amount.

The Network Today: Scale and Adoption

The Lightning Network has run on Bitcoin’s main network since 2018. mempool.space’s snapshot of 30 August 2026, the latest it had published in November 2026, counted about 16,200 public nodes and 32,700 public channels, holding about 3,800 BTC between them; the median public channel held 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.

Major Adoption Milestones

  • El Salvador (2021): The country made bitcoin legal tender and launched a government wallet, Chivo, with Lightning payments. Amendments passed in January 2025, as part of a loan deal with the IMF, made accepting bitcoin voluntary, and the government’s part in Chivo was to be gradually wound down.
  • Cash App Integration: Block (formerly Square) integrated Lightning into Cash App, exposing tens of millions of users to Lightning payments.
  • Nostr Protocol: The decentralized social media protocol adopted Lightning zaps as its native tipping mechanism, driving significant Lightning transaction volume.
  • Point-of-Sale Adoption: Companies like ibex and Swiss Bitcoin Pay provide merchant-facing Lightning payment infrastructure.
  • Exchange Integration: Many exchanges now support Lightning deposits and withdrawals.

Lightning Implementations: The Software Stack

Three major Lightning node implementations exist, each with different design philosophies. A fourth project, LDK (Lightning Dev Kit), is a library that developers use to build Lightning into their own apps rather than a node you run.

LND (Lightning Network Daemon)

Developed by Lightning Labs, LND is the most widely deployed implementation. Written in Go, it powers the majority of routing nodes and serves as the backend for popular wallets and services. LND implements the full BOLT specification and adds features like Keysend (spontaneous payments), AMP (Atomic Multi-Path payments), and a comprehensive gRPC API.

Core Lightning (CLN)

Maintained by Blockstream, CLN (formerly c-lightning) takes a modular, plugin-based approach. Written in C, it emphasizes efficiency and extensibility. CLN’s plugin system allows operators to add custom functionality — from automated fee management to specialized routing algorithms — without modifying the core software.

Eclair

Developed by ACINQ, Eclair is written in Scala and runs on the JVM. It runs ACINQ’s own large node, the node Phoenix users have their channel with, and is aimed at operators of large server nodes rather than home platforms. Phoenix itself runs a separate ACINQ mobile library, lightning-kmp, and uses trampoline routing and splicing (one on-chain transaction resizes a channel instead of closing it and opening a new one).

All three implementations follow the BOLT (Basis of Lightning Technology) specification, ensuring interoperability. A payment sent from an LND node routes through CLN and Eclair nodes without friction.

Self-Custody on Lightning

A common concern among Bitcoiners: does Lightning compromise self-custody? The answer depends on your setup.

Four ways to use Lightning, three of them self-custody. Your own node, LND or Core Lightning on Umbrel or Start9: the keys are yours, you choose your peers and open the channels, and if a peer stops answering you force-close and take your share. A node in your phone, Zeus with embedded LND or LDK Node: the keys are yours, Olympus, Zeus's LSP, opens channels to you, and you can force-close and take your share. An LSP wallet, Phoenix: the keys are yours, ACINQ's node is your only partner and sees whom you pay and how much, and if ACINQ stops answering you force-close from Phoenix, with the funds back on-chain after about 720 blocks, about five days. Custodial: the company holds the keys and your bitcoin and runs the channels, and you depend on it to pay you out. With self-custody, only you can spend.
Self-custody means the keys are yours and you can leave on your own. Your own node, a node in your phone and an LSP wallet all pass that test; what changes is who runs your channels and who sees your payments. A custodial app doesn’t, so keep only small amounts there.

Full Self-Custody Options

  • Running your own node: Operating LND or CLN on your own hardware gives you complete control. Your keys never leave your machine. This is the gold standard for Lightning self-custody, and platforms like Umbrel and Start9 make it accessible to home users. For setup guidance, see our Lightning node infrastructure guide.
  • Embedded node wallets: Zeus can run a Lightning node directly on your phone (embedded LND or LDK Node), with its own LSP, Olympus, opening channels to you. You hold your keys, though channel management is partially automated. We used to list Breez here too; as of November 2026 its original app has left the app stores.

LSP-Assisted Self-Custody

Phoenix wallet represents a middle ground. You hold your keys and your channel state, but ACINQ’s node, your only channel partner, handles liquidity and channel management. If ACINQ ever stopped answering, you can force-close the channel yourself from Phoenix (Settings, then Danger zone), and the funds come back on-chain after about 720 blocks, roughly five days. This is genuine self-custody with managed infrastructure, with one trade-off: ACINQ routes your payments, so it sees whom you pay and how much.

Custodial Solutions

Custodial services hold your keys for you. They offer the simplest Lightning experience but require trusting the service provider. Wallet of Satoshi, long the best-known example, now offers a self-custody mode built on Spark with a 12-word recovery phrase; the company calls it self-custodial, while WalletScrutiny, an independent wallet reviewer, still rates it custodial because Spark’s operators must co-sign every transfer. For Bitcoiners who prioritize self-sovereignty, custodial wallets should be limited to small spending amounts. The regulatory landscape around Lightning custody continues to evolve, making self-custodial options increasingly important.

Security Model: What Protects Your Funds

Lightning’s security rests on several mechanisms:

Revocation Keys

Every time a channel state is updated, the previous state is revoked: each side hands the other a revocation key for its previous commitment transaction. If a counterparty tries to cheat by broadcasting an old commitment transaction (one where they had a higher balance), the other party can use the revocation key to claim all funds in the channel. This penalty mechanism makes cheating economically irrational.

Timelocks

Force-closed channels include a timelock delay (typically 144-2016 blocks, or 1-14 days) before the party that closed the channel can claim its own funds. This window allows the counterparty to detect and respond to fraudulent close attempts.

Watchtowers

Since detecting fraud requires monitoring the blockchain, watchtower services can watch for cheating attempts on behalf of users who cannot stay online continuously. If a watchtower detects a breach, it broadcasts the penalty transaction automatically.

Your channel partner publishes an old, revoked split that gave them more than they own now. You hold their revocation key for that split. On-chain, their share waits out a timelock, typically 144 to 2,016 blocks, about 1 to 14 days. If someone is watching, your node or a watchtower spots it in time and uses their revocation key, and everything in the channel becomes yours. If nobody is watching, the wait ends and the old split stands.
Cheating risks the whole channel, as long as someone is watching. The revocation key lets you take everything; the timelock gives you time to use it; a watchtower keeps watch while your node is offline.

Backup and Recovery

On-chain bitcoin comes back from a seed phrase alone; money in Lightning channels does not. On LND you keep two things: your 24 words, and a fresh copy of channel.backup, the Static Channel Backup, made after every channel you open or close. If your node dies, a new node restored from the words reads that file and asks each peer to force-close, and your settled balances return on-chain as long as that peer is online and answers; close channels with peers that stay offline for long. The live channel database, channel.db, is never a backup: restoring an old copy would publish out-of-date balances, which counts as cheating and can cost you the channel. Core Lightning recommends real-time database replication instead of snapshots. Our lesson on Lightning backups and watchtowers covers both.

If an LND node dies, three things matter. Your 24 words, written on paper or metal away from the node, bring back your on-chain bitcoin but not, on their own, the money in your channels. The channel.backup file, the Static Channel Backup, copied off the node after every channel you open or close, lets a new node restored from your 24 words ask each peer to close its channel. If the peer is online and answers, your settled balance comes back on-chain. An old copy of channel.db, the live channel database, must never be restored: its out-of-date balances count as cheating and you can lose the channel. Phoenix needs only its 12 words; Core Lightning recommends replicating its database in real time.
On LND, the words bring back on-chain bitcoin; the words plus channel.backup bring back channel money. A new node restored from your words reads a fresh channel.backup, asks each peer to close. Your settled balance returns on-chain if the peer is online and answers. Never restore an old channel.db.

Common Misconceptions Bitcoiners Have About Lightning

“Lightning requires trust”

Not when you run your own node. Every Lightning transaction is backed by a real Bitcoin transaction that can be settled on-chain. The trust model is cryptographic enforcement, not social trust. Even with LSP-assisted wallets like Phoenix, you can unilaterally close your channels and recover funds.

“Lightning is too complex for normal users”

Modern wallets like Phoenix abstract away channel management entirely. The user experience is comparable to Venmo or Cash App — scan a QR code, enter an amount, send. The complexity exists but is handled by software.

“You can lose money on Lightning”

Force-close scenarios can cost on-chain fees, and poor channel management can lead to stranded liquidity. But outright fund loss requires a catastrophic software bug, losing your seed or your channel backup, restoring an old copy of your channel database, or your counterparty cheating while you are offline for longer than the waiting period with no watchtower. These risks, while real, are manageable with proper setup and seed phrase security practices.

Getting Started: Your First Steps

  1. Download a self-custodial wallet. Phoenix for simplicity. Zeus if you want more control. (We used to suggest Breez as well; as of November 2026 its original app has left the app stores.)
  2. Fund your wallet. Send bitcoin from your exchange or on-chain wallet. Phoenix moves an on-chain deposit into Lightning by itself after 3 confirmations; Zeus keeps it in your on-chain balance until you open a channel or start a swap.
  3. Make a payment. Buy something from a Lightning-enabled merchant, send a zap on Nostr, or pay a friend. Experience the speed firsthand.
  4. Explore further. Once comfortable, consider running your own node for maximum sovereignty. Umbrel and Start9 make home node operation straightforward.

Lightning is not a replacement for Bitcoin’s base layer. It is a complementary system that extends Bitcoin’s capabilities into the realm of everyday payments without sacrificing the security and decentralization that makes Bitcoin worth using in the first place.

Part of our free Bitcoin course: This topic is covered in depth in Lightning Network Explained from the Lightning Network & Bitcoin Nodes course.

FAQ

Is Lightning Network a separate cryptocurrency from Bitcoin?

No. Lightning is a protocol layer built on top of Bitcoin. Every satoshi on Lightning is backed 1:1 by bitcoin locked in on-chain payment channels. There is no separate token. When you “move bitcoin to Lightning,” you are locking bitcoin into a smart contract that enables fast off-chain transactions. You can always move it back on-chain by closing your channel.

What happens to my Lightning funds if my phone dies?

It depends on the wallet. Phoenix needs only its 12 words: ACINQ’s node keeps an encrypted copy of your channel data and returns it when you restore on a new phone. A wallet or node built on LND needs your seed plus a recent channel.backup; with both, your restored node asks each peer to force-close, and your settled balances come back on-chain as long as that peer is online and answers. A channel missing from your backup depends on the peer closing it on its own, and collecting that money can take a specialist tool, so keep the backup current.

Can Lightning handle large payments like buying a car?

Individual Lightning channels have capacity limits based on their funding amount. While Multi-Path Payments can split large amounts across multiple channels, Lightning is optimized for small to medium transactions. For a $50,000 car purchase, an on-chain transaction provides better reliability and simpler settlement. Lightning works best for payments well below the size of a typical channel: the median public channel held about 2 million sats (about 0.02 BTC) in August 2026.

How does Lightning affect Bitcoin’s security budget?

This is an active debate. Lightning reduces on-chain transaction volume, which reduces miner fee revenue. However, channel opens, closes, and splices still generate on-chain fees. As Bitcoin block rewards decrease through halvings, the balance between Lightning efficiency and miner fee revenue will become an important economic consideration for the network’s long-term security.

Filed under: Lightning Network & Layer 2

Continue Reading

← Back to All Articles