Lightning: payments off the chain

The core idea: keep the transaction, don't broadcast it

Two parties lock funds into a shared output with a bitcoin transaction. From then on they exchange signed transactions that split that output differently, without publishing them. Each new balance invalidates the previous one.

Either side can close the channel at any moment by broadcasting the latest state. Because the on-chain rules will enforce whatever is broadcast, neither side needs to trust the other, only to keep their data and be able to react in time.

This is why Lightning is fast and cheap: the expensive, globally verified part happens twice, at open and close, no matter how many payments flowed in between.[26][25]

Routing without knowing the whole path

You do not need a channel with every shop. Payments hop across other people's channels using hash time-locked contracts: each hop can only claim its money once it can prove the payment succeeded further along, and everything unwinds automatically if it fails.

The route is wrapped in onion encryption, so each hop learns only its neighbours. That is better for privacy than a bank transfer, and worse than a cash payment in the same room.[25]

What you give up

Liveness. To notice a cheating counterparty and respond in time, your node, or a watchtower acting for you, has to be reachable. A channel that is never watched is a channel with an extra assumption.

Liquidity friction. You can only receive as much as the other side of your channels can send. That is a routine annoyance for new users and a real operational job for merchants.

Different trust model. Custodial Lightning wallets hide all of this by holding your funds, convenient, but back to trusting a company. Non-custodial wallets keep the guarantees and hand you the channel management.

Not consensus. Lightning changes nothing about the 21 million cap or the chain rules. It is software built on top; the base layer neither knows nor cares about your channel.[25][2]