What Is the Lightning Network?

In brief

Lightning is a Bitcoin layer-2 payment-channel network. The BOLT specifications define cooperative off-chain transfers backed by Bitcoin transactions that can be broadcast for enforcement.

Its core pieces are:

• Funding transaction: locks channel funds in an on-chain output controlled by both peers under the channel’s funding construction.
• Commitment transactions: each peer holds an enforceable transaction representing the latest channel state.
• Revocation: in the deployed penalty design, revealing an old state’s secret lets the counterparty punish publication of that revoked state.
• HTLC: a conditional payment claimable with a hash preimage before a deadline, otherwise refundable after a timeout.
• Route: a sequence of channels through intermediate nodes.
• BOLT 11 invoice: a signed payment request containing a payment hash and other payment parameters.

A Lightning payment does not become a separate confirmed Bitcoin transaction. Instead, the recipient accepts an updated channel claim that can ultimately be enforced on Bitcoin. Closing the channel later settles channel outputs; it does not publish a ledger row for every prior coffee.

Lightning is not a separate coin, a sidechain, or an Ethereum-style rollup. It does not remove Bitcoin fees or consensus risk. It changes how often ordinary payments need to touch the base layer.

Opening a channel

In the baseline BOLT design, two peers negotiate a funding output that requires both parties’ authorization to spend. Before treating the channel as usable, they exchange signatures for refund-like commitment transactions so neither side can strand the funds if the other disappears.

The funding transaction is then broadcast and must reach the negotiated confirmation depth. After that, the channel has a fixed total capacity, minus reserves and on-chain fee considerations. An ordinary single-funded channel initially places most usable balance on the funder’s side; dual-funded constructions can start with both sides contributing.

The funding output is on-chain. Routine balance changes are not.

Commitment transactions: the enforceable current state

Each peer holds its own version of a commitment transaction, signed by the other peer, that can spend the funding output. The transactions encode the current balances and any pending HTLCs. Either peer can force the channel on-chain by broadcasting its latest valid commitment if cooperation stops.

An update is a protocol exchange, not merely editing a shared number:

1. Peers propose balance or HTLC changes.
2. They exchange signatures for new commitment transactions.
3. After the new state is safely held, they reveal revocation information for the prior state.

The order matters. Revealing the old secret before having a valid replacement could leave a peer without a safe close. Accepting a replacement without revoking the old state would let multiple states remain economically usable.

In today’s widely deployed LN-Penalty design, an old commitment remains a valid Bitcoin transaction in isolation; “revoked” means broadcasting it exposes outputs to the counterparty’s revocation key. The honest peer has a delay window in which to publish a penalty or justice transaction. BIP 112’s relative timelock is a key building block: the party broadcasting its commitment must wait before spending its delayed output, giving the other side time to react.

This is why the latest channel backup and chain monitoring matter. Bitcoin does not know which off-chain state the peers privately consider newest until someone uses the scripts and secrets on-chain.

Cooperative and unilateral closes

There are three important outcomes:

• Cooperative close: both peers agree on final outputs and sign a compact closing transaction. There are no unresolved HTLCs.
• Unilateral or force close: one peer broadcasts its latest commitment. Some outputs are delayed or require separate HTLC-resolution transactions, and on-chain fees can be higher.
• Revoked-state breach: a peer broadcasts an old commitment. The counterparty must detect it and use the revocation path before the relevant delay expires.

A force close is not proof of cheating. It is the normal fallback when a peer is offline, unresponsive, or disagrees. The protocol is designed so cooperation is cheaper and disputes remain enforceable.

HTLCs make multi-hop payments atomic

A direct channel only connects two peers. Lightning routes beyond that pair with hashed timelock contracts.

The receiver chooses a secret called the payment preimage and gives the payer its hash in an invoice. Each hop offers a conditional transfer tied to that same hash:

• reveal the preimage in time and the receiver-side claim succeeds;
• reach the timeout without the preimage and the payer-side refund path becomes available.

Absolute expiry heights decrease along the route toward the receiver. Each intermediary’s incoming HTLC expires later than its outgoing HTLC, leaving a safety margin to learn the preimage and enforce its incoming claim if the downstream side goes on-chain.

When the receiver releases the preimage, it travels backward through the route. Each forwarding node can then settle the incoming HTLC and fulfill the outgoing one. If a hop rejects the payment or a condition cannot be met, failure travels backward and the conditional changes unwind. Timeouts are the on-chain last resort, not the normal fast path.

This construction reduces the need to trust intermediaries with principal, but it does not remove all risk. Implementations must handle deadlines, fee-bumping, chain congestion, pinning attempts, and failures safely.

Routing and onion packets

The sender chooses or obtains a route and wraps per-hop instructions in an onion packet defined by BOLT 4. Each forwarding node learns where to send the payment next and the terms it must enforce; it does not receive the complete route in plain text.

That provides limited path privacy, not perfect anonymity. Adjacent peers know they are connected, timing and amounts can leak information, the sender and receiver know their own endpoints, and colluding or well-positioned nodes may infer more. Public channel announcements also reveal network topology, though not the current balance split inside each channel.

Routing can fail even when every participant is honest because the sender does not have a perfect live map of directional balances. Nodes advertise channel capacity and fee/timeout policy, but the spendable balance on each side changes with payments and is generally not public. Wallets may retry another path or split a payment into multiple parts.

Liquidity is directional

Channel capacity is the total bitcoin locked in it. Outbound liquidity is the amount your side can send, after reserves, fees, and pending HTLCs. Inbound liquidity is the amount the remote side can send to you.

If Alice funds a channel with 1,000,000 satoshis and none starts on Bob’s side, Alice initially has outbound liquidity and almost no inbound liquidity through that channel. After Alice pays Bob 200,000 satoshis, her outbound side falls and her inbound side grows by roughly that amount. The total channel capacity did not change; its direction changed.

The receiver also needs a route whose final channel has enough inbound liquidity. A node can obtain or reshape liquidity by receiving payments, opening channels with a desired balance, using dual funding, rebalancing through other channels, or purchasing liquidity through supported services. Each method has costs and trust or availability assumptions.

“There is enough capacity” therefore does not mean “this payment can route.”

Fees

Lightning is not fee-free. Costs can include:

• Bitcoin transaction fees to open, splice, or close channels;
• a base and proportional forwarding fee charged by routing nodes under advertised policy;
• liquidity-management or service fees;
• higher on-chain costs during a force close or HTLC resolution.

The payer typically sees or limits the route fee before sending. A direct payment through one’s own channel may have no forwarding fee, but the channel still required capital and on-chain transactions. Fee levels are market and implementation choices, not a promise of the protocol.

Staying online and using watchtowers

In the penalty model, a channel user must monitor the Bitcoin chain often enough to detect a revoked commitment and respond during the delay window. It does not need to remain connected every second, but being offline longer than the negotiated safety window without delegated monitoring can be dangerous.

A watchtower monitors for a client’s old commitment being broadcast and, when it detects a match, publishes a pre-signed penalty or recovery transaction. Bitcoin Optech notes that a watchtower need not hold the channel funds; its job is detection and broadcast.

Watchtowers reduce the online burden but do not make it disappear:

• the client must supply usable breach-remedy data;
• the tower must be available and able to get a transaction confirmed;
• tower protocols and privacy models vary by implementation;
• a tower is not a substitute for channel-state backups and recovery planning.

Watchtower support is not one of the finalized numbered BOLTs cited here. Do not imply that every Lightning wallet uses the same tower protocol or offers the same protection.

Invoices and payment completion

A BOLT 11 invoice is a signed, bech32-encoded payment request. It includes a payment hash and timestamp and can include an amount, expiry, description, route hints, and other tagged fields. The amount may be omitted, allowing the payer to supply it.

The payment hash commits to the receiver’s preimage. Revealing that preimage is cryptographic evidence used to fulfill the HTLCs. Invoice expiry says when the receiver should no longer accept a new payment attempt; it is different from the HTLC’s on-chain timeout.

An invoice is not a Bitcoin on-chain address. Reusing or paying one depends on wallet and invoice semantics, and newer Lightning payment protocols such as offers are separate from BOLT 11.

Custodial versus self-custodial Lightning

Lightning itself supports channels whose users control the relevant keys. A consumer app can still be custodial: the provider may operate all channels, hold the keys, and update an internal balance for the user. Fast “Lightning” branding does not answer the custody question.

Ask:

• Who controls the channel keys?
• Can the user force-close without the provider?
• Is the displayed balance a channel claim the user can enforce or an account claim on a company?
• Who performs backups and chain monitoring?
• What happens if the service disappears?

The same Self-custody principles apply, with added channel-state and liveness requirements.

Limits and trade-offs

Lightning can reduce routine on-chain load and support small, fast payments, but it is not unlimited:

• channels consume on-chain space when opened, changed, or closed;
• funds must be locked and placed in the right direction;
• routing can fail and leak information;
• force closes need timely block space;
• users or delegated services must monitor for disputes;
• implementations and wallet custody models differ.

The live Layer 2 article surveys scaling families, especially rollups. This page stays on Lightning’s distinct channel, commitment, HTLC, routing, liquidity, and monitoring model.