How Lightning works

After this lesson you can: describe a payment channel in plain words.

A channel

Alice and Bob create a channel by funding a 2-of-2 multisig output on-chain. Say each puts in 0.5 BTC. They then hold a signed transaction that would pay out the current balances if broadcast. To pay Bob 0.1, Alice signs a new version: 0.4 to her, 0.6 to him. They can do this thousands of times, instantly, with no blockchain involvement. The chain only sees the open and, eventually, the close.

Keeping it honest

What stops Alice broadcasting an old state where she had more? Each new state comes with a secret that lets the other party claim all the funds if an old state is ever broadcast. Cheating costs everything, so nobody cheats. A watchtower can watch the chain on your behalf while you are offline.

Routing

Alice has no channel with Carol, but Bob has one with each. Alice pays Carol through Bob. A hashed timelock contract (HTLC) makes this safe: Carol creates a secret and gives Alice its hash; each hop forwards a conditional payment that can only be claimed by revealing the secret, within a time limit. When Carol reveals it to claim from Bob, Bob can claim from Alice. Either every hop completes or none does. Bob earns a tiny routing fee.

Invoices and addresses

To get paid you issue an invoice (lnbc...), a one-time request containing the amount and the payment hash. Lightning addresses (you@domain) and BOLT 12 offers let you publish something reusable.

The limits

A channel can only move what is in it; large payments may need several routes (multipath). To receive, you need inbound liquidity on your side. The receiver's node must be online. These are the practical frictions the next lessons address.