How Lightning Channels Work: Bitcoin Payments Off-Chain

Every Lightning payment you have ever sent skipped the blockchain entirely, and yet nobody had to trust anybody. That sounds like a contradiction. It is actually a small piece of game theory built on top of a 2-of-2 multisig, and once you see it, Lightning stops looking like magic and starts looking like plumbing.

This piece walks through the life of a channel: how one opens, how sats move through it, how payments hop across strangers, and how it closes. If you have read our guides on multisig and the mempool, you already have the background.

The problem Lightning solves

Bitcoin's base layer produces a block roughly every ten minutes, and every node in the world verifies every transaction. That is the point of the system, and also its limit. Buying a coffee with an on-chain transaction means paying a fee sized for global consensus and waiting for confirmation.

In 2015, Joseph Poon and Thaddeus Dryja published the Lightning paper with a different idea: let two parties transact with each other privately as many times as they like, and only tell the blockchain the final result. The base layer becomes a court of last resort rather than a cash register.

Opening a channel: the funding transaction

A channel begins with an ordinary on-chain transaction. Alice sends, say, 1,000,000 sats into a 2-of-2 multisig output controlled by both her and Bob. Before she broadcasts that transaction, the two of them sign a refund transaction that returns her coins if things go wrong. That ordering matters: nobody locks funds until an exit is already signed.

Once the funding transaction confirms, the channel is live. It has a fixed capacity, 1,000,000 sats in this example, and that capacity is split into two balances. At the start, Alice holds all of it. Bob holds nothing.

Moving sats: commitment transactions

When Alice pays Bob 100,000 sats, they do not touch the chain. Instead they sign a new pair of commitment transactions reflecting the new split: 900,000 for Alice, 100,000 for Bob. Each commitment is a valid Bitcoin transaction that either party could broadcast to close the channel at that balance.

The catch is obvious: Alice still holds a signed older commitment where she has 1,000,000. What stops her from broadcasting the old one? Revocation. Each time the state updates, both sides hand over a secret that lets the other party claim the entire channel balance if the old state ever appears on-chain. Cheating means forfeiting everything. That penalty mechanism is what replaces trust.

Balances are tracked in millisatoshis, where 1,000 msat equals one sat, which is why Lightning can price payments finer than the base layer can.

Routing: paying people you have no channel with

You do not need a channel with every merchant. If Alice has a channel with Bob, and Bob has one with Carol, Alice can pay Carol through Bob. The trick is the hash time-locked contract, or HTLC.

  1. Carol generates a random secret and gives Alice its hash inside an invoice.
  2. Alice offers Bob a payment that only he can claim by revealing the secret behind that hash, within a time limit.
  3. Bob offers Carol the same deal on slightly shorter terms.
  4. Carol reveals the secret to claim her money. Bob uses it to claim from Alice.

Either the whole chain of payments completes or none of it does. Intermediate nodes cannot skim or steal, and they earn a small routing fee for lending liquidity. Payments are onion-routed, so Bob knows only the hop before and the hop after, not the sender or the final recipient.

Why payments sometimes fail

Lightning's rough edge is liquidity. A channel's capacity is public, but how it is split between the two sides is not. If Alice routes through a channel where Bob has only 20,000 sats on his side toward Carol, a 50,000 sat payment fails, and her wallet quietly tries another path. Good wallets retry in the background so you rarely notice.

Bigger payments are harder than small ones for this reason. A channel also carries a practical cap on how many HTLCs can be in flight at once, 483 in the protocol specification, and very small outputs below the dust limit cannot be enforced on-chain at all. Lightning is designed for everyday amounts, not for moving a treasury.

Closing a channel

There are two ways out. A cooperative close is the clean one: both parties sign a final transaction paying out the current balances, it confirms on-chain, and you are done. A force close happens when a peer disappears. You broadcast your latest commitment, wait out a timelock so the other side has a chance to contest a cheating attempt, and then sweep your funds. It works, but it is slower and usually costs more in fees.

Every channel costs two on-chain transactions, one to open and one to close, so the economics favor keeping channels open for a long time and putting many payments through them.

What you can actually do with this

  • Start with a self-custody Lightning wallet that manages channels for you. Our custodial versus self-custody comparison is a good place to begin.
  • Open your first channel with a meaningful amount, not dust. Very small channels can be uneconomical to close when on-chain fees rise.
  • Treat Lightning as a spending account and keep your savings in cold storage. Hot wallets are for pocket money.
  • Do not run old channel backups. Restoring an outdated state can look like an attempted cheat. Use the static channel backup or seed-based recovery your wallet provides.
  • If you want to go deeper, run your own node and open channels to well-connected peers.

The culture around it

Lightning is the part of Bitcoin where the cypherpunk instinct meets everyday use: no permission, no signup, no account, just two keys and a contract. If you have read this far, you are already in the culture. BitCloset makes heavyweight apparel for people who chose Bitcoin, and you can see the current drops at bitcloset.shop.

Further reading

Back to blog

Leave a comment