Lightning, channels, and routing

The Bitcoin base layer is good at one thing: settling final transfers of value with extreme finality. It is bad at the things you'd want a global payment network to be good at — speed, cost, throughput. Lightning is the answer that emerged from a decade of engineering: take the actual payment off-chain, but anchor it cryptographically to the chain so neither party can cheat.

The core idea: payment channels

Two parties — call them Alice and Bob — open a channel by writing one Bitcoin transaction that locks some BTC into a 2-of-2 multisig address that they both control. From that moment until the channel closes, they can pass the balance back and forth between themselves an unlimited number of times, as fast as a network round-trip, without writing anything to the blockchain. When they're done, they close the channel by writing a final transaction that pays each party their final balance.

All the activity in between exists only as signed-but-unbroadcast transactions held by both parties. Each new payment produces a new pair of signed transactions that supersede the previous ones. Either party can post the latest version on-chain at any time and walk away with their share.

The cheating problem

Here's the obvious problem: what if Bob, after taking 50 payments and ending up with 0.1 BTC, tries to broadcast an old version of the channel state where he had 0.5 BTC? He could steal from Alice if there were no protection.

Revocable transactions and the penalty mechanism

Lightning solves this with a brutal asymmetric punishment. Every time Alice and Bob update their channel balance, they exchange a piece of secret data tied to the previous state — essentially a 'revocation key.' If Bob ever broadcasts an old state, Alice's node sees it on-chain and has a window of time (the dispute period) to publish the revocation key, which lets her sweep Bob's entire balance. Cheating once costs you everything.

The leap: routed payments

Two-party channels are useful but not a network. The breakthrough is that you can route a payment across multiple channels. If Alice has a channel with Carol, and Carol has a channel with Bob, Alice can pay Bob through Carol — without Carol ever being able to take the money or fail to forward it.

Hash time-locked contracts (HTLCs)

The trick is a clever cryptographic primitive called an HTLC. Bob picks a random secret R and gives Alice its hash H = SHA256(R). Alice constructs a payment that says 'Carol can claim 1000 sats from me if she reveals R within 2 hours, otherwise the money returns to me.' Carol then does the same to Bob: 'Bob can claim 999 sats if he reveals R within 1 hour, otherwise the money returns to me.'

Bob has R, so he can claim from Carol. The act of claiming reveals R to Carol. Carol now has R and can claim from Alice. Alice has paid Bob, Carol has earned 1 sat in routing fees, and at no point could Carol steal — she could only fail to forward, in which case all the money returns and nothing happens.

The decreasing time-locks (2 hours, 1 hour) are crucial. They guarantee that intermediate hops cannot get stuck holding the bag — the further from the destination, the more time you have to recover.

Source routing and the gossip layer

Lightning uses source routing — the sender computes the entire path through the network and onion-encrypts it so each hop only knows the previous and next node. To do this, every node maintains a partial map of the network: who has channels with whom, with what capacity, and what fees they charge. This map is built and refreshed via a gossip protocol that floods channel announcements between connected peers.

Why finding a path is hard

You can see channel capacity, but not how the balance is split inside the channel. A 1 BTC channel might be 0.99 on one side and 0.01 on the other — useless for payments going in the lopsided direction. Pathfinding algorithms have to guess and retry. This is why Lightning payments occasionally fail: not because the network is broken, but because the algorithm tried a path with insufficient liquidity in the right direction.

Liquidity is the actual constraint

Anyone can send up to the inbound capacity of their channel — the bitcoin held by the other side that they can pull toward themselves. A new node with no inbound liquidity cannot receive anything. Building inbound liquidity is the practical hard problem for most operators. Solutions: paying for it (services like Lightning Pool, LNBig), running a routing node that earns liquidity through traffic, or accepting on-chain payments first to bootstrap.

Submarine swaps and Lightning loops

Need to convert Lightning sats to on-chain BTC, or vice versa? Submarine swaps do this trustlessly: you send a Lightning payment, and the counterparty sends you an on-chain transaction, with HTLCs ensuring neither side can renege. Tools like Boltz and Lightning Loop automate this. It's how channels get rebalanced and how funds flow between layers without going through an exchange.

What Lightning is good at, and what it isn't

• Good at: instant low-fee payments under ~$10,000, recurring streaming payments, micropayments below the on-chain dust limit, zero-confirmation point of sale.
• Bad at: large transfers (channel capacity limits + routing failure rates climb sharply), cold storage (channels require an online node), recipient privacy (the sender knows exactly which node received).
• Different at: privacy from intermediate hops is much better than on-chain (onion routing), but the sender always knows who they paid.

Custodial vs. non-custodial Lightning

Running your own node is real engineering. Most users use custodial Lightning wallets (Wallet of Satoshi, Strike, Cash App) where the provider runs the node and you have an account. This is fast and easy but gives the provider full control of the funds. Non-custodial mobile wallets like Phoenix and Breez run a real Lightning node on your phone — slightly less convenient, dramatically more sovereign.

Where Lightning is going

Active research areas: trampoline routing (let well-connected nodes do hard pathfinding for thin clients), splicing (resize channels without closing), Taproot channels (better privacy + complex contract support), async payments (receive while offline). Plus protocols built on top — LNURL for static payment requests, BOLT12 offers, Nostr Wallet Connect for browser-side payments.

The pattern across all of this is the same as the original Lightning insight: take the cryptography seriously, do everything you can off-chain, anchor to Bitcoin only when something needs to be final.