The short answer
Lightning is a network of two-party payment channels. Two people put coins into a single Bitcoin output that needs both their signatures to spend, and from then on they rewrite the split between them as often as they like without publishing anything. Only opening the channel and closing it touch the chain.
Paying someone you have no channel with works by relaying the payment across channels other people already have, under a condition that either settles the whole path or unwinds it.
Everything below is how that is actually built, and what it costs.
Why the chain is a poor place for a small payment
A Bitcoin fee is the transaction's size multiplied by a fee rate. Nothing in that calculation refers to the amount being sent, so a payment of a few hundred satoshis costs what a payment of several bitcoin costs, given the same shape of transaction. The mempool is not a queue has the accounting, and Bitcoin has no balances, only unspent outputs explains why the number of coins you are spending, rather than their value, is what you pay for.
Then there is the wait, which arrives on the network's schedule rather than the buyer's.
Neither is a defect. It is what a global, ordered, permanent record costs, and every node on the planet stores a copy of your coffee. Lightning's premise is that most payments do not need to be in that record. Only the opening and closing positions do.
A channel is one shared output and a stack of transactions nobody broadcasts
Opening a channel begins with an ordinary on-chain transaction, the funding
transaction. Its channel output is a 2-of-2 multisig. The specification is exact about
the script: "The funding output script is a P2WSH to: 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG", where the two keys are ordered lexicographically
(BOLT 3, Funding Transaction
Output).
Once it confirms, neither party can move the money alone.
What makes that usable rather than merely stuck is the second half. Each side holds a commitment transaction, signed by both of them, which spends the funding output back to the two of them in the current proportion. BOLT 5 states what it is: "a cross-signed commitment transaction, which describes the current state of the channel (basically, the current balance). This commitment transaction is updated every time a new payment is made and is spendable at all times" (BOLT 5).
It is not broadcast. It sits on each side's disk as the standing right to end the channel on today's terms without anyone's cooperation, and that unexercised right is what makes the rest of it safe.
The two copies are not identical. In the copy you hold, your own output is encumbered by
an OP_CHECKSEQUENCEVERIFY relative timelock of to_self_delay blocks, while your
counterparty's output is immediately spendable. The spec is direct about why: "if the
local node publishes its commitment transaction, it will have to wait to claim its own
funds, whereas the remote node will have immediate access to its own funds" (BOLT 5).
Ending the channel unilaterally is deliberately the slower option for whoever does it.
Moving balance is an exchange of signatures
A payment inside a channel is not a transaction. It is three messages: update_add_htlc
proposes the change, commitment_signed signs the new state, and revoke_and_ack hands
over the secret that invalidates the old one
(BOLT 2, Normal
Operation).
The balance has moved, the chain has not heard about it, and the pair can do it again a
thousand times.
The revocation is the security. Once you have revoked a state, publishing it lets your counterparty sweep the entire channel with a penalty transaction (BOLT 5, Revoked Transaction Close Handling). Old states are not merely superseded; they are made expensive.
A channel is like a bar tab that both people initial after every round, except the tab is enforceable by anyone with the paper, and initialling a new one destroys your ability to present the old.
Reaching someone you have no channel with
You do not open a channel to every shop. Instead the payment is relayed, and the thing that makes relaying safe is a hash time-locked contract, or HTLC.
The receiver picks a random number, the preimage, and gives you only its SHA-256 hash.
Your payment travels the path as a chain of conditional promises, one per hop, each saying
the same thing: pay the next hop this amount if they produce a number that hashes to this
value, and otherwise return it to me after a certain block height. Nobody along the path
can steal it, because claiming the money requires the preimage, and revealing the preimage
to claim from one neighbour is exactly what lets that neighbour claim from theirs. The
settlement runs backwards along the path, hop by hop, in update_fulfill_htlc messages
carrying the preimage
(BOLT 2, Removing an
HTLC).
If any hop fails, the promises expire in order and every balance is where it started. The
deadlines are staggered on purpose, each hop's timeout further out than the next, so a
forwarding node always has time to claim its incoming payment after paying out its
outgoing one (BOLT 2, cltv_expiry_delta Selection).
An HTLC is like an escrow with a deadline, except no third party holds anything and the deadline is a block height rather than a date.
The routing instructions are wrapped in layers of encryption, so each node learns only who handed it the packet and who to hand it to. The spec's claim is careful, and worth reading as written: intermediate nodes "cannot learn which other nodes, besides their predecessor or successor, are part of the packet's route; nor can they learn the length of the route or their position within it" (BOLT 4).
Closing, the good way and the bad way
BOLT 5 names three endings, and the names are the spec's own.
Mutual close, "the good way". Both sides agree, sign a closing transaction that pays out the final balances, and publish it. It "allows them to access their funds immediately and can be negotiated with lower fees" (BOLT 2, Channel Close), because there is nothing to protect against.
Unilateral close, "the bad way". One side is gone or unwilling, so the other publishes
its latest commitment transaction. The money is safe and the channel ends, but the party
that forced it waits out to_self_delay blocks before it can spend its own share, and any
payments still in flight have to be resolved on-chain rather than in a message.
Revoked close, "the ugly way". Someone publishes an old state on purpose. The penalty transaction takes the channel. This one only works if the other side, or something acting for them, notices inside the delay window.
What Lightning does not do
It is not anonymous. Onion routing hides the route from the nodes forwarding it, and
that is a real property, but the same specification says it "does not preclude the
possibility of packet association by an attacker via traffic analysis" (BOLT 4). Public
channels are announced to everyone by design, since routing needs a map: channel_announcement
and node_announcement messages exist so that nodes can build "a local view of the
network's topology"
(BOLT 7). Your
first hop knows you sent something. Your recipient's node knows what arrived. A custodial
Lightning wallet knows everything about both.
It needs somebody online. Receiving a payment means being reachable to release the preimage. Staying safe means someone watches the chain for a revoked close inside the delay window. If you run your own node, that someone is you, or a watchtower you have arranged. If you use a custodian, it is them, along with your keys.
Inbound liquidity is a real constraint. You can only receive up to the balance sitting on the other side of your channels. A channel funded entirely by you starts with nothing on the far side, so a brand new channel can send and cannot receive until money has moved across it. The protocol also holds back a channel reserve from each side, suggested at "1% of the channel total", specifically so that each party "always has something to lose" (BOLT 2, Channel Establishment v1). That reserve is not spendable balance.
Channel funds are not on-chain money until the channel closes. A balance in a channel is a claim enforceable by a transaction you have not published. Turning it back into a coin you can spend on-chain takes a close, a confirmation and a fee, which is the same cost Lightning was avoiding.
Where to go next
The thing you meet first in practice is not a channel but a string beginning lnbc.
What a Lightning invoice actually is takes that apart:
what it commits to, why it expires, and why you cannot use one twice.