Blinded Paths

What Are Blinded Paths?

Blinded paths (also called route blinding) are a Lightning Network privacy feature defined in BOLT 4 that allow a payment receiver to hide their node identity and channel structure from the sender. Instead of revealing their public node ID in an invoice, the receiver constructs an encrypted route segment starting from an "introduction node" and provides this opaque blob to the sender. The sender can route a payment to the introduction node, which then forwards it along the blinded path to the receiver, but the sender never learns who the receiver actually is.

In the standard Lightning payment flow, the sender discovers a route to the receiver by looking up the receiver's node in the public channel graph or by using route hints embedded in the invoice. Both approaches reveal the receiver's node identity. Blinded paths solve this by letting the receiver pre-compute the final portion of the route and encrypt it so that only each successive hop can decrypt its own forwarding instructions.

This mechanism builds directly on onion routing, which already prevents intermediate nodes from learning the full path. Blinded paths extend that guarantee to the sender as well: even the party initiating the payment cannot see where it ends up after the introduction node.

How It Works

A blinded path consists of an introduction node, a series of encrypted hop payloads, and blinded node IDs that replace the real public keys of nodes along the path. The receiver constructs this path before sharing it with the sender.

Path Construction

The receiver builds a blinded path through the following steps:

1. The receiver selects a route from an introduction node to themselves, typically 2 to 5 hops through nodes they have channels with
2. For each hop in the path, the receiver generates a blinded node ID by multiplying the node's real public key with a blinding factor derived from a shared secret
3. The receiver encrypts the forwarding instructions (next hop, fees, CLTV delta) for each node using that node's shared secret
4. The result is a sequence of blinded node IDs and encrypted payloads that only the correct node at each hop can decrypt

The sender receives this blinded path and appends it to the end of their own route. They route the payment normally to the introduction node, then the introduction node begins unwinding the blinded segment.

Cryptographic Mechanism

The blinding relies on elliptic curve Diffie-Hellman key exchange at each hop. The receiver picks a session key and derives shared secrets with each node along the blinded path:

// Simplified blinding construction
session_key = random_scalar()
blinding_point = session_key * G

// For each hop i in the blinded path:
shared_secret[i] = SHA256(session_key * node_pubkey[i])
blinded_id[i]    = node_pubkey[i] * HMAC("blinded_node_id", shared_secret[i])
encrypted_data[i] = encrypt(shared_secret[i], forwarding_info[i])

// Advance blinding factor for next hop:
session_key = session_key * HMAC("blinding_factor", shared_secret[i])

When a node along the blinded path receives a payment, it uses the blinding point from the onion packet to derive the same shared secret, decrypt its forwarding instructions, and compute the blinding point for the next hop. Each node only learns its own next hop: it cannot determine how many hops remain or who the final recipient is.

Payment Flow

The complete payment flow with a blinded path works as follows:

1. The receiver constructs one or more blinded paths and includes them in a BOLT 12 offer or invoice
2. The sender finds a route from themselves to the introduction node using the public channel graph
3. The sender builds the onion packet: cleartext hops to the introduction node, then blinded hops from there to the receiver
4. The introduction node decrypts its blinded payload, learns the next hop, and forwards the payment with the updated blinding point
5. Each subsequent blinded hop repeats the process until the payment reaches the receiver
6. The receiver decrypts the final payload, verifies the payment details, and settles the HTLC

Integration with BOLT 12

Blinded paths are a foundational component of BOLT 12 offers, the next generation of Lightning invoices. While BOLT 11 invoices rely on route hints that expose channel IDs and node public keys, BOLT 12 replaces them entirely with blinded paths.

In a BOLT 12 offer, the receiver publishes one or more blinded paths as part of the offer payload. When a sender wants to pay, they fetch an invoice via the offer's blinded path (using an onion message), receive an invoice containing additional blinded paths for payment delivery, and complete the payment without ever learning the receiver's node ID.

This two-step process (offer retrieval and payment) both use blinded paths, providing end-to-end receiver privacy. The receiver can rotate blinded paths periodically, making it difficult to correlate payments over time.

Why Receiver Privacy Matters

Standard Lightning payments provide sender privacy through onion routing: intermediate nodes cannot determine who initiated a payment. However, the receiver is always known because the sender needs to route to them directly. This asymmetry creates real problems.

Merchant Privacy

A merchant accepting Lightning payments reveals their node identity to every customer. Competitors can analyze their payment volume, channel partners, and liquidity. With channel probing, an adversary can estimate a merchant's balance and revenue patterns by repeatedly querying their channels.

Blinded paths let merchants accept payments without exposing their node. Customers route to an introduction node and the payment arrives at the merchant through an opaque path. Even a sophisticated attacker who controls the introduction node learns only that some payment passed through, not the merchant's identity or channel structure.

Individual Privacy

For individuals receiving Lightning payments, node exposure ties their financial activity to a persistent identity. Blinded paths break this link, enabling users to receive payments without revealing their node in the public graph or in invoices shared with untrusted parties.

Use Cases

• Private merchant payments: businesses accept Lightning without exposing node identity, channel partners, or liquidity to customers or competitors
• Donation and tip addresses: content creators publish BOLT 12 offers with blinded paths so anyone can pay them without learning their node infrastructure
• Cross-platform privacy: wallets and payment processors use blinded paths to shield their backend node topology from end users and third parties
• Censorship resistance: receivers in adversarial environments can accept payments without advertising their network position, making targeted channel closures or denial of service more difficult
• Multi-path blinding: receivers can provide multiple blinded paths to support multi-path payments, improving payment reliability while maintaining privacy

Comparison to Rendezvous Routing

Blinded paths evolved from an earlier proposal called rendezvous routing. Both aim to hide the receiver, but they differ in important ways.

Blinded paths won adoption because they fit within the existing onion packet size and do not require protocol changes beyond the blinding mechanism itself. Rendezvous routing offers slightly stronger privacy (the sender cannot even see blinded IDs) but introduces complexity around nested onion packets that proved difficult to standardize.

Risks and Considerations

Privacy vs. Routability

Longer blinded paths provide stronger anonymity but reduce payment success rates. Each additional hop in the blinded segment adds fee requirements and latency, and the sender cannot optimize routing for those hops because they are opaque. A blinded path through poorly connected or low-liquidity nodes will fail without the sender being able to diagnose or route around the problem.

Receivers must balance path length against reliability. In practice, 2 to 3 blinded hops provide reasonable privacy while keeping failure rates manageable.

Fee Overhead

The sender pays fees for every hop, including the blinded segment. Since the sender cannot see the actual nodes in the blinded path, they cannot compare fee rates or choose cheaper alternatives. The receiver sets the fee and CLTV requirements for blinded hops when constructing the path.

This can lead to higher total fees compared to direct routing, especially when blinded paths traverse expensive channels. Receivers should select blinded paths through nodes with competitive fee policies.

Introduction Node as a Correlation Point

The introduction node sees both the sender's routing path and the start of the blinded path. While it cannot decrypt the blinded hops, it knows that a payment arrived from a particular direction and entered a specific blinded path. If the same introduction node is reused across many payments, it becomes a correlation point.

Receivers can mitigate this by rotating introduction nodes and providing multiple blinded paths through different entry points. Using several introduction nodes in a single offer also improves reliability if one path fails.

Implementation Complexity

Blinded paths add complexity to both the sender and receiver implementations. Senders must handle the transition from cleartext to blinded hops when constructing onion packets. Receivers must manage path construction, key derivation, and path rotation. Error handling is also more complex: if a payment fails in the blinded segment, the sender receives a generic failure and cannot pinpoint which hop caused it.

Node implementations including CLN, LND, and Eclair have been adding blinded path support, but full ecosystem-wide interoperability is still maturing.

Path Staleness

Blinded paths are constructed at a specific point in time based on the receiver's current channel state. If channels close, nodes go offline, or liquidity shifts after the blinded path is created, payments through that path will fail. Long-lived offers (such as static payment codes) need a mechanism to refresh blinded paths periodically, adding operational complexity for the receiver.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.