Route Blinding

What Is Route Blinding?

Route blinding is a cryptographic technique in the Lightning Network that allows a payment receiver to hide the final portion of a payment route. Instead of giving the sender explicit directions to their node (as traditional route hints do), the receiver constructs a series of encrypted payloads that only the nodes along the blinded segment can decrypt, one hop at a time.

The sender sees only the introduction node: the first node in the blinded segment. From there, each forwarding node unwraps its own encrypted instructions, learns the next hop, and passes the payment along. No single node in the blinded segment knows the full path, and the sender never learns the receiver's node identity or the channels used after the introduction point.

Route blinding was proposed by Bastien Teinturier and merged into the Lightning specification (BOLT 4) in 2023 after several years of development. It is the privacy mechanism that makes BOLT 12 offers possible: every BOLT 12 invoice uses blinded paths by default, replacing the privacy-leaking route hints of BOLT 11 invoices.

How It Works

Route blinding builds on Lightning's existing onion routing but adds a layer where the receiver pre-computes encrypted routing data for each hop in the blinded segment. The process has two phases: construction by the receiver, and forwarding by the network.

Blinded Route Construction

The receiver builds the blinded route before sharing an invoice or offer. The steps are:

1. The receiver selects a path from an introduction node to themselves (this may traverse one or more intermediate hops)
2. The receiver generates an ephemeral key pair and performs an ECDH key exchange with each node's public key along the path, deriving a unique shared secret per hop
3. Each node's real public key is tweaked using the shared secret to produce a blinded node ID: a random-looking public key that the node can still derive the private key for, but that reveals nothing about its real identity
4. Per-hop routing data (the next node's short channel ID, relay fees, and CLTV delta) is encrypted with ChaCha20-Poly1305 using a key derived from that hop's shared secret
5. All encrypted payloads are padded to a uniform length so an observer cannot infer a hop's position by payload size

The receiver then packages the introduction node's real public key, the ephemeral blinding point, and the list of blinded node IDs with their encrypted data into the invoice or offer. The sender receives this bundle but cannot decrypt any of it.

Payment Forwarding

When the sender pays the invoice, the forwarding works as follows:

1. The sender constructs a normal onion route to the introduction node and appends the blinded segment data from the invoice
2. The introduction node receives the payment along with the ephemeral blinding point. It performs an ECDH operation with its own private key and the blinding point to derive its shared secret
3. Using that shared secret, the introduction node decrypts its encrypted_recipient_data TLV to learn which channel to forward through and what fees to apply
4. The introduction node derives the next blinding point (by tweaking the current one) and forwards the payment along with this new point
5. Each subsequent blinded hop repeats the process: ECDH with the blinding point, decrypt its own payload, derive the next blinding point, and forward
6. The final hop (the receiver) decrypts a path_id field that confirms the payment arrived through a path they created

What the Sender Sees

The sender's view is deliberately limited. They know the introduction node's public key (since they must route to it), but after that point, they see only a list of blinded node IDs: random-looking public keys with no relation to real node identities. They can see how many hops the blinded segment has but cannot determine which nodes are involved, what channels are used, or where the receiver is in the network topology.

The receiver can further obscure the path length by adding dummy hops (extra encrypted layers that a node peels off without forwarding), making analysis of the blinded segment even harder.

Cryptographic Sketch

The core key-derivation and encryption at each hop follows this pattern:

// Receiver constructs blinded route for node N_i
ephemeral_key = random_scalar()
E_0 = ephemeral_key * G              // starting blinding point

// For each hop i in the blinded path:
ss_i = ECDH(ephemeral_key, N_i)      // shared secret with node i
rho_i = HMAC("rho", ss_i)            // encryption key
B_i = N_i + HMAC("blinded_node_id", ss_i) * G  // blinded node ID

encrypted_data_i = ChaCha20Poly1305(
  key = rho_i,
  nonce = 0,
  plaintext = { short_channel_id, fee, cltv_delta, ... }
)

// Derive next blinding point
E_{i+1} = HMAC("blinding_factor", E_i || ss_i) * E_i

Each forwarding node recovers its shared secret using its own private key and the blinding point it receives. It can then decrypt its payload and derive the next blinding point, but it cannot derive secrets for any other hop.

Route Blinding vs. Rendezvous Routing

Before route blinding was adopted, the Lightning community also considered rendezvous routing as a way to hide receiver identity. Both techniques share the same goal: prevent the sender from learning who they are paying. However, they differ in important ways:

Route blinding was ultimately chosen for the specification because of its lower implementation complexity, reusability for BOLT 12 offers, and the fact that it required fewer protocol changes. The trade-off is that rendezvous routing hides the blinded path length, while route blinding exposes it (though dummy hops can partially mitigate this).

Use Cases

BOLT 12 Offers and Invoices

Route blinding is a foundational component of BOLT 12 offers. When a merchant publishes a reusable offer (for example, in a QR code or on a website), the offer includes one or more blinded paths. When a customer wants to pay, they fetch an invoice through the blinded path using onion messages, and the returned invoice also contains blinded paths for the actual payment. At no point does the customer learn the merchant's node ID.

For a deeper technical walkthrough, see Blinded Paths in Lightning: How Receivers Hide Their Node Identity.

Receiver Privacy for Routing Nodes

Large routing nodes are identifiable by their public channels and well-known node IDs. Route blinding allows these operators to receive payments without revealing which of their many channels is the final destination. This is particularly valuable for Lightning service providers who want to separate their public routing role from their private receiving activity.

Onion Messages

Route blinding is not limited to payments. It also protects the recipient of onion messages: a general-purpose messaging layer defined alongside BOLT 12. Any onion message can be sent to a blinded path, hiding the destination from the sender. This enables private communication channels, invoice request flows, and application-layer protocols built on Lightning without revealing endpoint identities.

Private Merchant Nodes

Merchants accepting Lightning payments can use route blinding to hide their node from competitors, chain analysis firms, or attackers. Instead of publishing route hints that reveal their node ID and channel peers, they publish blinded paths that provide no usable network topology information. Combined with private channels, this makes the merchant's Lightning infrastructure effectively invisible.

Implementation Status

Route blinding support varies across Lightning implementations:

• Core Lightning (CLN): full support for blinded paths in both payments and onion messages, integrated with its native BOLT 12 implementation
• LDK (Lightning Dev Kit): supports blinded paths for offers, payments, and onion messages, making it available to any wallet or application built on the LDK framework
• Eclair: full BOLT 12 support including blinded path creation and forwarding
• LND: added blinded path forwarding and receiving support in recent releases. LND v0.18 introduced the --blind flag for creating invoices with blinded paths, and subsequent releases have expanded onion message support as a stepping stone toward full BOLT 12 integration

For a comparison of implementation features, see the Lightning implementation comparison.

Risks and Considerations

Introduction Node as a Privacy Bottleneck

The introduction node is the only part of the blinded path visible to the sender. If a receiver consistently uses the same introduction node, an observer can correlate payments and infer the receiver's general network neighborhood. Mitigations include rotating introduction nodes across different blinded paths and selecting introduction nodes that are multiple hops away from the receiver.

Fee and CLTV Correlation

Although blinded node IDs hide real identities, the aggregate fees and CLTV deltas of the blinded segment are visible to the sender. If the blinded path is short and the fee structure is distinctive, an attacker with knowledge of the network graph could narrow down which nodes are involved. Longer blinded paths and dummy hops reduce this risk but increase payment costs.

Path Length Leakage

Unlike rendezvous routing, route blinding reveals the number of hops in the blinded segment. This metadata can assist network analysis, especially when combined with timing data. Receivers can add dummy hops to obscure the true length, but this adds latency and fee overhead.

Payability Trade-offs

Blinded paths must be payable: the channels in the blinded segment need sufficient capacity and inbound liquidity. Because the sender cannot see these channels, they cannot route around failures in the blinded segment. If a channel in the blinded path lacks liquidity, the entire payment fails. Receivers can mitigate this by including multiple blinded paths in their invoices, giving the sender alternative routes to try.

QR Code and Invoice Size

Blinded paths add data to invoices: each hop contributes a blinded node ID and an encrypted payload. For invoices shared as QR codes, longer blinded paths increase the QR code density, which can cause scanning problems on lower-end devices. This is a practical trade-off between privacy (more hops) and usability (smaller invoices).

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.