Lightning Network

Overview

Why Lightning Network matters

Small transactions can be inefficient when each payment must compete for block space. Lightning lets connected participants update balances across channels and settle the net result on Bitcoin when channels are closed or otherwise resolved. This can support low-value purchases with different trade-offs than waiting for new Bitcoin blocks each time.

How it works

Two parties open a payment channel using an on-chain funding transaction. Within the channel, they exchange updated commitments reflecting their new relative balances; properly implemented mechanisms limit the ability to reuse outdated commitments. A payment can pass across several channels using hashed time-locked contract techniques and a route with sufficient available liquidity. The recipient normally creates an invoice, and the sender attempts payment over an available route. On success the payment is completed within Lightning's rules; it does not require each hop to create an immediate new base-chain block. Channel management, monitoring, inbound liquidity and routing fees affect whether payments can be received reliably.

Liquidity is directional, not merely total

A Lightning channel has a balance distribution between its two participants. A node may have plenty of total channel capacity yet too little incoming liquidity to receive a large payment through a particular route. Similarly, senders can fail to find a route even when all participants have sufficient aggregate funds because no suitable path has the necessary directional capacity. Payment failures may therefore require retrying with another route, adjusting channel liquidity or selecting an on-chain alternative. Merchants should support expired invoices, repeated attempts and clear customer feedback. A successful Lightning payment can offer rapid settlement inside the channel system, but the operator still needs good watchtower, backup and channel-management practices to preserve its security and availability.

A real-world payment example

A café requests the bitcoin equivalent of a $4 coffee via a Lightning invoice. A customer's wallet finds a route and pays while both sides are online or otherwise supported by their service. The café can treat a successful verified Lightning settlement differently from an unconfirmed on-chain BTC payment, because the evidence and failure modes are not the same.

Limits and common misunderstandings

Lightning is not just "Bitcoin with zero fees". Channel opening and closing can require on-chain fees; routing fees and liquidity constraints apply. Custodial Lightning wallets add counterparty risk. Invoice expiry, failed routes and channel availability need to be handled by checkout software.

How it differs from related concepts

Bitcoin base layer records on-chain settlement history. Lightning updates channel balances and enforces claims through Bitcoin when necessary. These are complementary rails with different receipts.

Explore further

Official background: technical documentation.

Related glossary terms: Bitcoin Network, Off-Chain Transaction, Payment Rail.