Your last $3 coffee purchase on Bitcoin's base layer would have cost more than the coffee, taken ten minutes to confirm, and clogged a block that someone in Lagos needed for a life-changing remittance. Bitcoin was never going to scale to global retail payments one transaction at a time on-chain — and the designers knew it. The Lightning Network is the answer that emerged: a second layer that lets two parties exchange many tiny payments off-chain while keeping Bitcoin's settlement guarantees as a backstop.
This is Part 4 of our Bitcoin Deep Dive. In Part 3 we unpacked fees and blockspace, which is exactly the scarcity Lightning is designed to relieve. If the UTXO model from Part 2 still feels fuzzy, keep it open in a tab — Lightning is UTXOs all the way down.
What Lightning Actually Is
The short version of lightning network explained: two people lock some bitcoin into a shared on-chain address and then pass IOUs back and forth, signed but unbroadcast, until one of them decides to close out. Only the opening and the final settlement touch the blockchain. Every payment in between is instant, cheap, and private between the two parties.
The network part is what makes it interesting. If Alice has a channel with Bob, and Bob has one with Carol, and Carol has one with Dave, then Alice can pay Dave without ever opening a direct channel with him — as long as the intermediate hops have enough liquidity. Bitcoin itself becomes the settlement layer; Lightning becomes the payment rail.
The Funding Transaction and the 2-of-2 Multisig
A channel starts with a single on-chain transaction called the funding transaction. Alice and Bob each contribute some bitcoin (or just one of them does — that is a single-funded channel) into a 2-of-2 multisig output. Neither party can spend that UTXO alone. Both signatures are required.
That output is the channel. Its size — say, 0.1 BTC — is the channel capacity, the maximum amount that can flow in either direction before the channel needs to be rebalanced or closed. If Alice funded the whole thing, she starts with 0.1 BTC of outbound liquidity and Bob has 0.1 BTC of inbound liquidity. This asymmetry matters, and we will come back to it.
Once the funding transaction confirms, the channel is open. From here on, Alice and Bob exchange commitment transactions — pre-signed spends of the funding output that encode the current balance.
Commitment Transactions and the Justice Mechanism
Each time Alice and Bob update their balances, they build a new commitment transaction and invalidate the old one. But "invalidate" is doing a lot of work in that sentence, because Bitcoin has no way to stop someone from broadcasting a transaction they hold a valid signature for. The old commitment is still technically spendable.
The trick is the revocation secret. When Bob hands Alice a new commitment, he also hands her a secret that, combined with the old commitment's script, lets her sweep all of Bob's funds from the channel if he ever broadcasts that stale state. This is the justice transaction (sometimes called the breach remedy). Cheating is not just unprofitable — it is ruinous. Broadcast an old state, lose everything.
In practice this means Lightning nodes need to be online often enough to catch cheating attempts, or they need to delegate that watching to a watchtower. There is a real liveness assumption here, and it is one of Lightning's honest trade-offs.
HTLCs: Routing Without Trusting the Middlemen
Direct channels are easy. Routing a payment from Alice through Bob and Carol to Dave is where it gets clever. The primitive is the Hash Time-Locked Contract (HTLC).
Here is the atomic story. Dave wants to be paid, so he generates a random secret R and sends its hash H = SHA256(R) to Alice as part of an invoice. Alice then builds a chain of conditional payments:
- Alice promises Bob: "I will pay you 10,001 sats if you reveal R within 3 blocks."
- Bob, now holding that promise, turns around to Carol: "I will pay you 10,000 sats if you reveal R within 2 blocks."
- Carol goes to Dave: "I will pay you 9,999 sats if you reveal R within 1 block."
Dave reveals R to Carol and claims his 9,999 sats. Carol now knows R, so she claims 10,000 from Bob. Bob claims 10,001 from Alice. The payment routes backwards, each hop earning a tiny fee. If anyone stalls, the time-locks unwind the whole chain — either everyone gets paid or no one does. It is cryptographically atomic, even though no one trusts anyone in the middle.
The decreasing time-locks are critical: they give each upstream hop enough window to claim their payment even if a downstream hop goes offline or misbehaves. The declining amounts are the routing fees.
Liquidity Is the Real Constraint
Beginners think Lightning's hard part is the cryptography. Operators know the hard part is liquidity. A channel has a fixed capacity, split between outbound (what you can send) and inbound (what you can receive). If all your channels are full on your side, you can send but cannot receive. If they are empty on your side, you can receive but cannot send.
This is why running a Lightning node well is closer to being a small treasury manager than a sysadmin. You rebalance channels, open new ones with well-connected peers, and pay attention to who on the network has the liquidity pointed in the direction you care about.
For most users this is too much work, which is why Lightning Service Providers (LSPs) have become the default on-ramp. An LSP opens a channel to you with inbound liquidity already provisioned, often as part of your wallet's first-run flow, and charges a small fee for the service. Phoenix, Breez, Zeus with an attached node, and similar wallets lean on this pattern in different ways.
What the Network Looks Like in 2025–2026
Public observers disagree on the exact numbers because a growing share of Lightning traffic runs over private channels, but the rough snapshot looks something like: 15,000 to 17,000 public nodes, 40,000 to 49,000 public channels, and somewhere between 2,700 and 5,600 BTC of public capacity depending on whose crawler you trust. The private-channel footprint is almost certainly larger than the public one now, which is a healthy sign — it means real commerce is happening off the radar of tourist dashboards.
Two upgrades reshaped the network over the last year:
Simple Taproot Channels use the Schnorr-signature and MuSig2 features that activated in 2021 but took the ecosystem a while to actually ship. The payoff is that Taproot channels look identical on-chain to any other Taproot spend — no more distinctive 2-of-2 script revealing that a UTXO was a Lightning channel. ACINQ measured roughly a 20% reduction in on-chain fees for Taproot channel opens and closes compared to legacy channels.
Splicing lets you add or remove funds from a channel without closing and reopening it. Before splicing, if your channel filled up or you needed to top up, you paid the on-chain fee to close and another to reopen. Splicing collapses that into a single on-chain transaction that resizes the channel in place. Core Lightning, Eclair, and LDK all shipped interoperable splicing during 2025. For users on fee-sensitive days and for LSPs managing large channel inventories, this is a quiet efficiency win.
How to Hold It in Zelcore
Zelcore is deliberately an on-chain, non-custodial wallet. It does not run a Lightning node for you, and it does not custody Lightning balances. The honest framing: if you want to transact on Lightning, you will use a dedicated Lightning wallet, and you should think carefully about whether you want a non-custodial setup (Phoenix, Breez, Zeus, your own node) or a custodial one. Custodial Lightning is easier and fine for small balances; non-custodial Lightning gives you the self-sovereignty that matches how you would use Zelcore on the base layer.
What Zelcore is good at is the settlement side: receiving on-chain, managing your seed phrase and main Bitcoin stack, and funding a Lightning wallet from cold storage when you are ready to spend. Treat Lightning as your checking account and your Zelcore-held on-chain BTC as your savings — they solve different problems.
Honest Trade-Offs
Lightning is not free money. You need to be online (or pay a watchtower) to enforce your channel state. Routing can fail in ways that feel unfamiliar if you are used to on-chain. Liquidity management is real work or real fees. Privacy is better than on-chain in some ways and worse in others — payment hashes leak information to sophisticated observers, and LSPs can see a lot of your traffic.
None of that makes it a bad idea. It makes it a different kind of tool from base-layer Bitcoin, with its own operator's manual.
Key Takeaways
- A Lightning channel is a funded 2-of-2 multisig UTXO plus a long sequence of signed-but-unbroadcast commitment transactions.
- The revocation secret and justice transaction make cheating economically suicidal, at the cost of a liveness assumption.
- HTLCs route payments through untrusted intermediaries atomically using a shared hash preimage and cascading time-locks.
- Capacity, outbound liquidity, and inbound liquidity are the three numbers every Lightning operator lives by.
- The 2025 network runs at roughly 15–17k public nodes and 40–49k public channels, with Taproot channels and splicing as the headline upgrades.
- Zelcore stays on-chain; pair it with a dedicated Lightning wallet — custodial or non-custodial, your call — for day-to-day payments.
- Next in this series: Part 5 — 51% attack economics, and why Bitcoin's security budget is the long-run question no one can dodge.
