Onion Routing in Lightning: How Payment Privacy Works

When you send a Lightning payment, no single node along the path knows both who sent it and who received it. This property comes from onion routing: a technique where the sender wraps payment instructions in multiple layers of encryption, one for each hop along the route. Each forwarding node peels away exactly one layer, learning only enough to forward the payment to the next node. The result is a payment system where privacy is built into the protocol at the packet level.

This article walks through how onion routing works in Lightning, from the cryptographic packet structure defined in BOLT 4 to the practical privacy limitations that remain. Understanding how routing privacy works (and where it breaks down) matters for anyone building on or using the Lightning Network.

The Onion Metaphor

The term "onion routing" describes a layered encryption scheme. The sender constructs a single encrypted packet containing instructions for every node along the payment path. Each node can decrypt only its own layer, revealing the identity of the next hop and the forwarding parameters. The remaining layers stay encrypted and opaque.

Consider a payment routed through three forwarding nodes: Alice sends to Bob through nodes X, Y, and Z. Alice encrypts the packet in three layers. Node X decrypts the outermost layer and learns it should forward to Y. Node Y decrypts the next layer and learns it should forward to Z. Node Z decrypts the final layer and learns it should deliver the payment to Bob. No forwarding node sees the complete picture.

This is conceptually identical to how Tor routes internet traffic. The key difference is that Lightning routes payments rather than arbitrary data, introducing constraints around value transfer, timelocks, and fee structures that Tor does not face.

BOLT 4: The Onion Packet Structure

The Lightning BOLT specifications define the onion routing protocol in BOLT 4. The packet format is called a Sphinx packet, adapted from the Sphinx mix-format paper by George Danezis and Ian Goldberg. The Lightning implementation modifies Sphinx for the payment context: fixed-size packets, deterministic path lengths, and integration with HTLCs.

Packet Components

The onion packet consists of four parts:

• Version byte: currently 0x00 for the standard onion format
• Ephemeral public key (33 bytes): used by each hop to derive the shared secret for decryption, then blinded for the next hop
• Encrypted payload (1300 bytes): contains per-hop instructions for up to 20 hops, padded with random filler to maintain a constant packet size
• HMAC (32 bytes): authenticates the entire packet so each node can verify it has not been tampered with

Why fixed size matters: The encrypted payload is always 1300 bytes regardless of how many hops are in the route. Each hop shifts the payload left, adds filler bytes, and re-encrypts. An observer intercepting the packet at any point cannot determine how many hops remain or how many have already been traversed.

Per-Hop Payload

Each layer of the onion contains a per-hop payload encoded in TLV (Type-Length-Value) format. The payload includes:

• Short channel ID: identifies which channel to forward on
• Amount to forward: the value to pass to the next hop (less the forwarding fee)
• Outgoing CLTV expiry: the timelock value for the outgoing HTLC
• Payment secret and metadata (final hop only): data the recipient needs to claim the payment

The per-hop payload is distinct for the final hop. The last node receives the payment hash, payment secret, and total amount, but no forwarding instructions. This is how the recipient knows to claim the payment rather than forward it.

Key Derivation and Blinding

The sender starts with a fresh ephemeral key pair. For each hop, the sender computes a shared secret using ECDH (Elliptic Curve Diffie-Hellman) between the ephemeral private key and the hop's public key. This shared secret derives the encryption key, the HMAC key, and the blinding factor for the ephemeral key.

After computing the shared secret for hop N, the sender blinds the ephemeral public key before computing the shared secret for hop N+1. Each hop sees a different ephemeral key, preventing correlation between hops. When a forwarding node receives the packet, it performs ECDH with its own private key and the ephemeral key in the packet header, derives the same shared secret the sender computed, decrypts its layer, and blinds the ephemeral key for the next hop.

The Decryption Process at Each Hop

1. Receive the onion packet with the current ephemeral public key
2. Compute the shared secret via ECDH with the node's private key
3. Derive the decryption key and HMAC key from the shared secret
4. Verify the HMAC to confirm packet integrity
5. Decrypt the payload and extract the per-hop instructions
6. Shift the payload left, pad with pseudorandom filler bytes
7. Blind the ephemeral key and recompute the HMAC for the next hop
8. Forward the reconstructed packet along with the HTLC

From the forwarding node's perspective, the packet it receives looks structurally identical to the packet it sends: same size, same format, fresh ephemeral key. There is no positional information embedded in the packet.

What Each Hop Learns

The privacy guarantees of onion routing come from strict information boundaries. Each forwarding node learns only a narrow slice of the overall payment.

*The receiver does not inherently learn the sender's identity from the onion packet. However, application-layer data (invoices, messages, metadata) may reveal it.

One critical observation: the payment hash is identical across all hops. This is a significant privacy limitation. Any node that sees the same hash on its incoming and outgoing HTLCs can confirm it is part of the same payment. Two colluding nodes along the route can correlate their observations to narrow down the sender and receiver. PTLCs (Point Time-Locked Contracts) address this by using different payment points at each hop.

Route Selection and Pathfinding

The sender is responsible for selecting the entire route before constructing the onion packet. This is called source routing: the sender determines the full path rather than relying on intermediate nodes to make forwarding decisions. Source routing is essential for privacy because it means forwarding nodes do not need to know the destination to make routing decisions.

How Pathfinding Works

Lightning nodes maintain a local view of the network graph, built from channel announcements and updates gossiped across the network. When sending a payment, the sender runs a pathfinding algorithm (typically a modified Dijkstra's algorithm) to find a route that satisfies:

• Sufficient capacity in each channel along the path
• Acceptable total routing fees
• Acceptable total timelock duration
• Preference for reliable nodes (based on past success rates)

If a single route cannot carry the full payment amount, multi-path payments (MPP) split the value across multiple routes. Each partial payment uses its own onion packet and route. The receiver reassembles the parts using the shared payment hash and payment secret.

Trampoline routing: Trampoline payments offer an alternative for mobile and lightweight nodes that cannot store the full network graph. The sender specifies a few trampoline nodes, and each trampoline node handles pathfinding for its segment of the route. This trades some privacy (trampoline nodes learn more about the payment) for reduced resource requirements on the sender's device.

Route Hints

When the receiver's node has only private (unannounced) channels, the sender cannot find it in the public network graph. The receiver includes route hints in the invoice: short channel IDs and fee parameters for the last hop(s). The sender uses these hints to complete the route from the public graph to the private node. Route hints inherently reveal some of the receiver's channel topology to the sender.

Blinded Paths

Blinded paths (introduced in BOLT 4's route blinding specification) improve receiver privacy beyond what route hints provide. With blinded paths, the receiver constructs a partial route from an introduction point to itself, encrypting each hop's instructions so that the sender cannot identify the nodes involved.

The sender builds a route to the introduction point, then appends the blinded path. Forwarding nodes within the blinded segment use the encrypted data to determine the next hop without the sender ever learning the receiver's exact position in the network. Blinded paths are a key component of BOLT 12 offers, which replace the single-use BOLT 11 invoice format with reusable payment endpoints.

Lightning Onion Routing vs Tor

Lightning's onion routing draws directly from Tor's design principles, but the payment context introduces meaningful differences.

The most significant difference is the correlation vector. Tor circuits are vulnerable to traffic analysis (timing, volume patterns), but the data itself carries no inherent identifier linking entry and exit. In Lightning, the payment hash serves as a persistent identifier across all hops, creating a direct correlation mechanism for any node observing two legs of the same payment.

Privacy Limitations

Onion routing provides meaningful privacy guarantees, but it is not perfect. Several attack vectors reduce the effective anonymity set.

Payment Hash Correlation

As discussed above, the payment hash is identical at every hop. Two nodes controlled by the same entity at different positions in the route can trivially confirm they are forwarding the same payment. Combined with knowledge of the previous and next hops, the colluding nodes can narrow the sender and receiver to a small set.

PTLCs solve this by replacing the hash with a point (elliptic curve element) that gets blinded at each hop. With PTLCs, the cryptographic identifier changes at every hop, breaking the correlation. PTLC deployment requires Taproot and Schnorr signatures, which are available on Bitcoin L1 but not yet widely adopted in Lightning implementations.

Timing Analysis

Lightning payments resolve quickly: typically within seconds. A node that sees an incoming HTLC and an outgoing HTLC in rapid succession can infer they are part of the same payment even without hash correlation. This is especially effective for large or unusual amounts that create distinctive timing signatures.

Amount Correlation

Each hop decrements the forwarded amount by its routing fee. The differences between incoming and outgoing amounts are small and predictable (fees are published in channel updates). An observer seeing an incoming HTLC for 100,000 sats and an outgoing HTLC for 99,990 sats can confidently link them. Multi-path payments partially mitigate this by splitting the amount, making individual fragments harder to correlate with the total payment.

Probing Attacks

Probing involves sending payments designed to fail in order to learn information about the network. An attacker can probe channels to determine their current balance by sending increasingly large payments through targeted paths and observing where they fail. Over time, probing reveals the liquidity distribution of the network, which can be combined with other data to deanonymize payments.

Payment probes are also used legitimately for pathfinding: wallets probe routes before sending payments to improve success rates. The same mechanism that helps honest users also helps attackers map channel capacity.

Network Position and Graph Analysis

Large routing nodes that forward a disproportionate share of payments see more traffic and can correlate more data. If a small number of nodes handle most of the network's liquidity, the effective anonymity set shrinks. The topology of the Lightning network, where well-connected hubs forward many payments, creates a natural tension with privacy: the nodes best positioned to forward efficiently are also best positioned to observe traffic.

Improving Lightning Privacy

Several developments aim to strengthen the privacy properties of Lightning's onion routing:

• PTLCs: replace hash-based correlation with blinded payment points, removing the strongest correlation vector
• Blinded paths: hide receiver topology from the sender
• Trampoline routing: delegates pathfinding to intermediate nodes, which can improve privacy if the sender uses multiple trampoline layers
• Route randomization: adding random extra hops (shadow routing) to obscure the true path length
• Keysend payments: enable sending without an invoice, removing the invoice as a metadata trail between sender and receiver

Each improvement addresses a specific attack surface. No single change makes Lightning fully private, but the combination significantly raises the cost of traffic analysis.

Spark: A Different Privacy Model

Spark takes a fundamentally different approach. Instead of routing payments through a network of nodes, Spark transfers are point-to-point: the sender transfers ownership of Bitcoin directly to the receiver via the Spark operators. There is no multi-hop path, no forwarding nodes, and no onion packet.

This eliminates the entire class of routing privacy concerns. There are no intermediate nodes to observe payment hashes, amounts, or timing. There is no network graph to probe for liquidity information. The routing attack surface does not exist because routing does not exist.

Spark's privacy considerations are different. The Spark operators participate in every transfer and can observe transfer metadata: amounts, sender, and receiver. The trust model is 1-of-n: as long as one operator behaves honestly, funds remain secure. But unlike Lightning, where privacy depends on network topology and path selection, Spark's privacy properties are defined by the operator set and the protocol's cryptographic design rather than by routing behavior.

Different tradeoffs, not better or worse: Lightning provides routing privacy through onion encryption but exposes correlation vectors along the path. Spark eliminates routing entirely but requires trust in the operator set for transfer execution. The right choice depends on the specific privacy requirements and trust assumptions acceptable for a given use case.

Practical Implications for Developers

For developers building on Lightning, onion routing's privacy guarantees shape several design decisions:

• Invoice management: reusing invoices leaks payment patterns. Use single-use invoices or BOLT 12 offers with blinded paths when possible
• Channel topology: private channels reduce exposure but require route hints that reveal partial topology. Blinded paths offer better receiver privacy
• MPP and splitting: multi-path payments improve both reliability and privacy by making amount correlation harder
• Node operation: running a routing node means observing forwarded payments. Consider the regulatory and ethical implications of handling payment metadata
• PTLC readiness: as Lightning implementations adopt PTLCs, applications should prepare for the transition from hash-based to point-based payment correlation

Conclusion

Lightning's onion routing is one of the strongest privacy mechanisms in production use on any payment network. The Sphinx packet format ensures that forwarding nodes learn only their immediate neighbors, not the endpoints. Fixed packet sizes prevent positional analysis. Ephemeral key blinding prevents cross-hop correlation at the key level.

The main weaknesses are structural: payment hash reuse across hops, predictable fee decrements, and timing correlation. These create opportunities for well-positioned adversaries, particularly those controlling multiple nodes. PTLCs, blinded paths, and multi-path payments address these gaps, though full deployment across the network will take time.

For payment systems where routing is not required, such as Spark's point-to-point transfer model, the routing privacy problem simply does not arise. Different architectures create different privacy surfaces, and understanding the specific guarantees of each protocol is essential for making informed design decisions.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.