• The analogy everyone makes and nobody finishes
• A rough stack
• Channels are connections, not circuits
• HTLCs are forwarded packets (sort of)
• Onion routing is actually onion routing
• Invoices are DNS lookups in reverse
• Gossip is BGP without the hierarchy
• Where the analogy falls apart
• The liquidity problem TCP never had
• A useful lie

§The analogy everyone makes and nobody finishes

People love comparing the #lightning Network to TCP/IP. “Bitcoin is the settlement layer, Lightning is the transport layer.” It gets a nod from the networking crowd and sounds smart in a conference talk. Then the explanation stops. Nobody actually maps the concepts.

I want to do that here. Take the protocols and abstractions you already know from networking, line them up against Lightning’s design, and see what fits. More importantly, see where it doesn’t. Because the places where the analogy breaks tell you more about Lightning than the places where it holds.

§A rough stack

Before mapping individual pieces, here’s the coarse orientation.

#bitcoin L1 is something like the link layer. It handles the underlying settlement — getting transactions confirmed in blocks. It’s slow, expensive per transaction, and provides the finality guarantee that everything above depends on. You don’t stream video over Ethernet frames and you don’t buy coffee on-chain.

Lightning sits above that, roughly where TCP lives. It provides reliable payment delivery between endpoints, with multiplexing (multiple payments per channel), flow control (channel capacity limits), and connection management (channel open/close). The routing layer on top handles pathfinding across the network.

It’s not a clean OSI mapping. Don’t try to force it into seven layers. But the general shape — slow reliable base layer, fast stateful transport layer, application protocols on top — holds well enough to be useful.

§Channels are connections, not circuits

A #lightning channel starts with a funding transaction. Two parties lock #bitcoin into a 2-of-2 multisig output on-chain. This is the handshake. If TCP has SYN, SYN-ACK, ACK, Lightning has “propose channel,” “accept channel,” and “broadcast funding tx.” Both establish shared state between two endpoints.

Once the channel is open, both sides maintain commitment transactions — pre-signed spending transactions that encode the current balance split. Every payment updates these commitments. This is connection state, directly analogous to TCP’s sequence numbers and window sizes. Both sides track what’s been sent and received.

Closing a channel cooperatively looks like a TCP FIN exchange. Both parties agree on the final state, sign a closing transaction, broadcast it, done. Force-closing a channel is a RST. One side broadcasts their latest commitment unilaterally. It works, but it’s messy — there’s a timelock delay and potential disputes.

Here’s where it gets interesting. TCP doesn’t need a punishment mechanism because packets don’t carry monetary value. If one side of a TCP connection lies about the state, the worst case is a broken connection. In Lightning, lying about the state means trying to steal money. So Lightning adds revocation keys. When you update to a new commitment, you give the other party a secret that lets them take all the funds if you ever broadcast the old one. It’s an economic penalty for cheating that has no TCP analog because TCP has nothing worth stealing.

§HTLCs are forwarded packets (sort of)

When a payment crosses multiple channels, Lightning uses Hash Time-Locked Contracts. An HTLC says: “I’ll pay you X sats if you can show me the preimage of this hash, and if you can’t produce it within Y blocks, I get my money back.”

The networking analog is a packet with a TTL field. Each hop decrements the timelock (like TTL decrement at each router). If the packet reaches the destination, the recipient reveals the hash preimage, and that preimage propagates back through the chain — each hop uses it to claim payment from the previous hop. The whole chain resolves or the whole chain fails. No partial delivery.

This is where it starts diverging from TCP. A TCP packet is fire-and-forget at each hop. The router forwards it and moves on. An HTLC locks capital at every intermediate node until the payment resolves. If the path is Alice → Bob → Carol → Dave, then Bob has sats locked toward Carol that he can’t use for anything else until Dave either reveals the preimage or the timelock expires. The HTLC is more like a packet that forces every router to hold a deposit until the delivery is confirmed.

There’s no equivalent of packet loss. TCP expects some packets to drop and handles it with retransmission. Lightning payments are atomic — they either complete end-to-end or they fully refund. You never lose sats in transit. This is a feature, but it also means Lightning can’t just “retransmit.” A failed payment requires building an entirely new route.

§Onion routing is actually onion routing

BOLT #4 specifies the Sphinx packet format for payment routing. This is the one place where the networking analogy isn’t an analogy at all. Lightning uses genuine onion routing, derived from the same cryptographic family as Tor.

The sender constructs the entire route and wraps the routing instructions in layers of encryption, one per hop. Each intermediate node decrypts its layer using its private key, reads the next-hop instructions (amount, timelock, destination), and forwards the remaining onion to the next node. No intermediate node can see the full path or determine how many hops remain.

If you know Tor, you know this. The difference: Lightning uses source routing, meaning the sender picks the complete path upfront. Tor uses a form of relay-selected circuit building. Lightning paths are deterministic and optimized for fees and success probability. Tor paths are randomized for anonymity. Lightning trades some anonymity for payment efficiency, which makes sense because you’re moving money, not browsing the web.

The other difference is there’s no circuit-based multiplexing. In Tor, a circuit carries multiple streams. In Lightning, each payment constructs its own onion. Payments are independent. There’s no persistent tunnel between sender and receiver.

§Invoices are DNS lookups in reverse

In TCP/IP, you resolve a hostname to an IP address, then connect. In #lightning, the flow is inverted. The recipient creates a BOLT #11 invoice containing their node public key, the payment hash, the amount, an expiry, and optional routing hints — channels to use for reaching them. Then they hand this to the sender out of band.

It’s as if a web server sent you its IP address, port number, and preferred route through the internet before you could connect. The “DNS lookup” happens at the recipient’s end and the result is pushed to the sender, not pulled.

BOLT #12 offers change this slightly. An offer is reusable — more like a DNS record that stays valid. When a sender wants to pay, they use the offer to request a fresh invoice each time. Offers also support blinded paths, where the recipient hides their node identity behind intermediate hops. This is closer to a .onion address — the recipient is reachable without revealing their location in the network graph.

§Gossip is BGP without the hierarchy

BOLT #7 defines how nodes learn about the network topology. Three message types propagate through peer-to-peer gossip: channel announcements (proving a channel exists with an on-chain reference), node announcements (advertising a node’s public key and address), and channel updates (per-direction fee rates, timelocks, and enabled/disabled status).

Every node builds a local copy of the channel graph from these messages, then runs its own pathfinding algorithm. This is source routing with a topology database, somewhat like OSPF’s link-state approach. Each node has a view of the full graph and computes shortest paths locally.

Where it differs from BGP: there are no autonomous systems. The Lightning network is flat. No hierarchy, no tier-1 providers, no peering agreements. Every node is a peer of every other node. Path selection is based on fees and timelock requirements, not AS path length or policy routing.

Trampoline routing adds a faint echo of hierarchy. A mobile wallet with limited memory can’t store the full channel graph. Instead, it constructs a route to a well-connected “trampoline” node and delegates the remaining pathfinding to it. This is functionally similar to using a default gateway — you hand off the routing decision to someone with a better view of the network. But it’s opt-in, not structural. The protocol doesn’t define tiers.

The gossip protocol also doesn’t scale the way BGP does. The full Lightning channel graph is small enough that every node can hold it today — roughly 40,000 channels. If Lightning grew to millions of channels, gossip-based full-graph distribution would break. This is an active area of research, and it’s one of the real scalability constraints that the TCP/IP comparison obscures.

§Where the analogy falls apart

Three structural differences make the Lightning-as-TCP/IP framing misleading if taken too seriously.

Capital lockup. Internet routers don’t need money to forward packets. A router’s capacity is its bandwidth, which is a physical property of its links. A Lightning node’s capacity is its locked #bitcoin, which is a financial commitment. To forward a 100,000 sat payment, an intermediate node needs at least 100,000 sats of outbound capacity on the next-hop channel AND those sats are frozen until the HTLC resolves. This has no TCP equivalent. Imagine if every IP router had to escrow money proportional to the packets it forwarded, and couldn’t forward anything else while those packets were in flight.

No packet loss. TCP assumes an unreliable network and handles it with retransmission, checksums, and congestion control. Lightning assumes an unreliable network too, but the solution is atomicity, not retransmission. A payment either completes on the first try or it fully refunds. You can retry with a different route, but the original payment state is cleanly resolved. There’s no concept of duplicate delivery, out-of-order arrival, or partial success.

Economic routing. IP routing is best-effort. Routers forward packets because that’s what routers do. There’s no per-packet revenue, no marginal cost decision at each hop. Lightning routing is a market. Every intermediate node sets its own fee rate and makes a per-payment decision about whether the fee justifies the capital lockup. This means Lightning routing is subject to economic forces — liquidity pools toward profitable routes, drains away from unprofitable ones. TCP/IP has nothing comparable.

§The liquidity problem TCP never had

This is the most important divergence. In networking, if a link has 1 Gbps of bandwidth, it can carry 1 Gbps in each direction (full-duplex) or 1 Gbps total (half-duplex). The capacity is symmetric or at least well-defined.

Lightning channels are different. A channel with 1,000,000 sats has that capacity split between two sides. If Alice has 800,000 sats and Bob has 200,000, Alice can send up to 800,000 toward Bob, but Bob can only send 200,000 toward Alice. Capacity is directional and shifts with every payment. There’s no networking analog for a link whose bandwidth depends on which direction you recently sent traffic.

This creates problems that network engineers never face. A node that receives lots of payments runs out of inbound capacity. A node that sends lots of payments runs out of outbound capacity. “Rebalancing” channels — shuffling sats between channels to restore capacity — is an ongoing operational task that has no equivalent in IP networking.

Submarine swaps let you exchange on-chain bitcoin for off-chain channel capacity. If you squint, it’s like NAT traversal — a workaround for a structural limitation that shouldn’t exist in a perfect design but does. Splicing lets you add or remove funds from a channel without closing it, like hot-swapping a network interface card without taking the link down.

Channel management on Lightning is closer to capacity planning for a telephone network than for an IP network. You’re managing circuits with committed resources, not packets on shared links. The circuit-switching comparison, ironically, maps better than the packet-switching one.

§A useful lie

The TCP/IP analogy is useful for getting oriented. Channels are connections. HTLCs are forwarded packets. Onion routing is onion routing. Gossip distributes topology. If you’re coming from networking, these correspondences give you a head start on understanding Lightning’s architecture.

But don’t mistake the analogy for equivalence. #lightning is a payment network with networking properties, not a network with payment properties. The economic layer — capital lockup, fee markets, directional capacity — changes the engineering constraints so fundamentally that solutions from IP networking rarely transfer directly. You can’t fix Lightning’s scaling problems the way you’d scale a packet network, because the bottleneck isn’t bandwidth. It’s money.

If that distinction doesn’t feel important yet, try running a routing node for a month. You’ll stop thinking about Lightning as TCP/IP before your first channel runs dry.

#bitcoin #lightning #programming