Lightning Network

In 2017 a single Bitcoin transfer could cost $50 and take hours. Buying a coffee with BTC was more expensive than the coffee itself. It seemed Bitcoin would forever remain 'digital gold' - valuable but useless for everyday payments. Then Lightning Network appeared, and it became possible to send 10 satoshis (less than a cent) in a fraction of a second with a fee of thousandths of a cent. How exactly was this achieved?

• **El Salvador** (2021) adopted Bitcoin as legal tender - mass everyday purchases run through Lightning (coffee, taxis, groceries). The Chivo Wallet app processed millions of micro-transactions
• **Nostr** (a decentralized social network) uses Lightning for 'zaps' - instant micropayments to content creators. Instead of likes - real satoshis sent in milliseconds
• **Bitstamp, Kraken, Coinbase** - major exchanges integrated Lightning for instant Bitcoin deposits and withdrawals, reducing time from 30-60 minutes to seconds

Предварительные знания

• Bitcoin: the UTXO model
• Bitcoin Script: programmable money

Payment Channels

Bitcoin handles ~7 transactions per second. Visa - ~24,000. Recording every coffee purchase in a blockchain is like sending a notarized letter instead of a text message. A **payment channel** solves this problem: two parties open a channel with one on-chain transaction and then exchange payments **instantly and for free**, without touching the blockchain.

To open a channel Alice and Bob create a **funding transaction** - a 2-of-2 multisig transaction that locks funds at a joint address. Say Alice contributes 0.5 BTC. These funds are now controlled by both signatures.

Each payment inside the channel is a new **commitment transaction**. It redistributes the balance between participants but is not published to the blockchain. Both sides sign the new state and **revoke the previous one** using revocation keys.

If Alice tries to publish an **old** commitment TX (where she has more money), Bob has the revocation key for that state. Bob can use it within the timelock period and **take all channel funds** as a penalty. This makes fraud economically irrational.

**Key insight:** a payment channel uses the blockchain as an **arbitration court**. As long as both parties are honest - the court is not needed. But if someone cheats - the blockchain enforces fairness. This is called **optimistic execution**: assume honesty, punish fraud.

Hash Time-Locked Contracts (HTLC)

A payment channel connects only two participants. But what if Alice wants to pay Carol, with whom she has no direct channel? If Alice has a channel with Bob and Bob has one with Carol, the payment can be **routed through Bob**. The problem: how to guarantee Bob won't steal the money?

**HTLC (Hash Time-Locked Contract)** solves this problem with two mechanisms: 1. **Hash Lock** - funds can only be claimed by presenting a secret (preimage) whose hash matches the one specified 2. **Time Lock** - if the secret is not presented within a certain time, funds return to the sender

**Atomicity:** the payment either completes **in full** (all HTLCs resolve) or **doesn't happen at all** (all HTLCs expire by timelock). It's impossible for Bob to receive money from Alice without paying Carol - because Bob learns the secret S **only after** Carol is paid.

In a real Lightning Network the chain can contain **up to 20 intermediate nodes**. Each HTLC on the path decreases the timelock (by default by 40 blocks ≈ 6.7 hours), so the maximum chain length is bounded by the total timelock.

Payment routing

HTLC explains how to securely pass a payment through a chain of nodes. But how do you **find** that chain? The Lightning Network has thousands of nodes and tens of thousands of channels. A mechanism is needed to build a route from sender to recipient.

Lightning uses **source routing** - the route is chosen by the **sender**, not by intermediate nodes (unlike IP networks). For this the sender must know the network topology. Nodes share channel information through a **gossip protocol**: each node tells its neighbors about its channels, fees, and capacity.

For large payments that don't fit through a single channel, Lightning supports **MPP (Multi-Part Payments)** - splitting a payment into parts and sending them over different routes. For example, a 1 BTC payment might go as 0.3 + 0.3 + 0.4 along three different paths.

But if the sender chooses the route - do intermediate nodes see who is paying whom? No. Lightning uses **onion routing (Sphinx)**, inspired by Tor. Each intermediate node knows only the **previous and next hop**. The payment is wrapped in layers of encryption - like an onion.

**The routing problem** is one of the most difficult in Lightning. The sender knows channel capacities but doesn't know **current balance distributions** (private information). So a route may fail, and alternative paths must be tried. Modern implementations use probabilistic models to estimate route success.

Liquidity and channel management

The route is found, HTLC works, onion routing provides privacy. But there is a fundamental problem: **liquidity**. A channel with a capacity of 1 BTC doesn't mean you can send 1 BTC through it in either direction. Capacity is split between participants and this distribution constantly changes.

Key distinction: **inbound capacity** (how much you can receive) and **outbound capacity** (how much you can send). If Alice opened a 1 BTC channel with Bob, Alice has 1 BTC outbound but 0 inbound - **she cannot receive** through this channel until she spends some funds.

When channels become unbalanced (all capacity on one side), routing stops working. Several strategies are used: - **Circular rebalancing** - send a payment to yourself through a circular route to redistribute balances - **Submarine swaps** - exchange on-chain BTC for Lightning BTC (and vice versa) without closing channels. Allows 'topping up' channel liquidity

For regular users and merchants, channel management is a complex task. That's why **LSP (Lightning Service Providers)** emerged - professional operators who open channels to users, provide inbound capacity, and handle routing. Examples: Breez, Phoenix (ACINQ), Voltage.

The **Liquidity Ads** protocol (defined in the BOLTs specification) lets nodes **advertise** their willingness to provide liquidity for a fee. For example: 'I'm willing to put 0.5 BTC into a shared channel for a fee of 500 sat'. This creates a **liquidity market** where operators compete to provide inbound capacity.

**Lightning scale (2025):** ~15,000 public nodes, ~50,000 channels, ~5,000 BTC total capacity. Millions of transactions pass through Lightning daily with fees of less than 1 satoshi. Largest integrations: Binance, Coinbase, Cash App, Nostr (zaps).

Summary

• **Payment channels** - two participants lock funds in a multisig transaction and exchange payments off-chain. The blockchain is only used for opening and closing the channel - like an arbitration court needed only in a dispute
• **HTLC** (Hash Time-Locked Contracts) - enable **atomic** payments through a chain of intermediate nodes. Preimage + decreasing timelocks guarantee: either everyone gets paid, or no one does
• **Source routing + onion routing** - the sender builds the route from the channel graph (gossip protocol), while Sphinx encryption hides the full path from intermediate nodes. **MPP** lets large payments be split into parts
• **Liquidity** - inbound vs outbound capacity determines who can send and receive. LSPs, submarine swaps, and Liquidity Ads solve liquidity management for regular users
• Remember the opening question: how to send fractions of a cent in milliseconds when Bitcoin handles 7 transactions per second? The answer - **move payments off the blockchain**, preserving its security through payment channels and HTLC

Related topics

Lightning Network is built on Bitcoin's basic primitives and opens the way to new capabilities:

• Bitcoin: the UTXO model — The funding transaction creates a UTXO at the multisig address - this is the channel's foundation. Understanding UTXOs is essential for understanding commitment transactions
• Bitcoin Script — HTLC, timelocks (CLTV, CSV), and revocation keys are implemented in Bitcoin Script. Script's constraints define what Lightning can do
• Taproot — Taproot makes cooperative channel closes indistinguishable from regular transactions (privacy), reduces on-chain data size, and opens the path to PTLCs - an improved replacement for HTLC

Вопросы для размышления

• A payment channel requires both parties to be online to monitor for fraud (old commitment TXs). How does this constraint affect Lightning usage by regular users on mobile devices, and what solutions exist (watchtowers)?
• Source routing means the sender must know the network topology but doesn't know current channel balances. Why do you think channel balances are not published via the gossip protocol, and what problems would that cause?
• Submarine swaps allow exchanging on-chain BTC for Lightning BTC. But they require an on-chain transaction, which is expensive. Do you see a circular dependency here, and how do LSPs and Liquidity Ads try to break it?

Связанные уроки

• dist-07-transactions