Blinded Paths in Lightning: How Receivers Hide Their Node Identity

Every BOLT 11 Lightning invoice contains the receiver's node public key in plaintext. Anyone who obtains an invoice can look up the receiver's node on a gossip-based network explorer, see its channels, estimate its balance, and in some cases correlate it with an IP address. For merchants processing thousands of invoices per day, this is a serious privacy leak: every customer, competitor, and chain-analysis firm learns the exact node behind each payment.

Blinded paths solve this by letting receivers construct an encrypted route suffix that senders can use to deliver payments without ever learning where those payments end up. The technique was specified in BOLT 4 route blinding (merged March 2023) and is foundational to BOLT 12 offers, the protocol's next-generation invoice format.

Why Receiver Privacy Matters

Lightning's original design prioritized sender privacy through onion routing: each forwarding node only knows the previous and next hop, never the full path. But the receiver's identity was never hidden. The invoice itself is the leak.

A BOLT 11 invoice encodes the destination node's 33-byte compressed public key directly. If the receiver uses private channels, the invoice must include route hints exposing those channels' short channel IDs and the peer's node ID. So-called “private” channels are not truly private: they can be discovered through payment probing, and route hints explicitly reveal them to every sender.

The consequences are concrete. A chain-analysis firm collecting invoices from a merchant's website can map the merchant's entire channel graph. A competitor can estimate daily volume by watching channel balance changes. A surveillance actor can build a profile linking node identity to real-world business operations. This is the problem blinded paths were designed to eliminate.

How Route Blinding Works

The core idea: the receiver pre-computes an encrypted route from an “introduction node” (a well-connected public node) to itself. The sender can find a route to the introduction node using normal pathfinding, then hands off the payment to the blinded portion. The sender never learns anything beyond the introduction point.

The Receiver's Construction

The receiver performs the following steps to build a blinded path:

1. Choose a sequence of nodes from a public introduction node to itself (the “blinded route”).
2. Generate an ephemeral key pair. The public key becomes the initial “blinding point” E(0).
3. For each hop i, compute a shared secret via ECDH between the ephemeral key and the hop's public key. Use this shared secret to derive a blinded node ID (a scalar multiplication of the real public key by an HMAC-derived factor) and an encryption key.
4. Encrypt per-hop routing data (channel ID, fees, CLTV delta) using ChaCha20-Poly1305 with the derived key.
5. Chain the blinding points forward: each hop's blinding point derives deterministically from the previous one plus the shared secret, so each node can compute the next blinding point to pass along.

The receiver publishes: the introduction node's real node ID, the initial blinding point E(0), and the sequence of blinded node IDs with their encrypted data blobs.

What the Sender Sees

The sender receives a blinded path and can observe only the introduction node's identity and a list of opaque blinded node IDs. The sender cannot determine the real identity of any node after the introduction point, cannot see channel IDs used in the blinded segment, and cannot even reliably determine how many hops exist (receivers can pad with dummy hops). The sender routes normally to the introduction node, then the blinded segment takes over.

How Each Hop Processes the Payment

When the introduction node receives a payment with a blinding point, it computes the same ECDH shared secret the receiver computed during construction (using its own private key and the blinding point). It decrypts its routing data, learns the next hop's channel, derives the next blinding point, and forwards. Each subsequent hop repeats this process. No hop learns anything about the nodes beyond its immediate neighbor.

ECDH is the foundation: The entire scheme relies on the fact that the receiver computing e(i) * N(i) produces the same shared secret as the hop computing k(i) * E(i). This is standard Elliptic Curve Diffie-Hellman, the same primitive underlying Lightning's existing Sphinx onion routing.

Blinded Paths and BOLT 12 Offers

BOLT 12 was merged into the Lightning specification in October 2024 via BOLTs PR #798. It introduces “offers”: reusable payment codes (prefixed lno1...) that replace the single-use BOLT 11 invoice for many use cases. Blinded paths are integral to how offers work.

The Offer-Invoice Exchange

The flow uses onion messages (BOLT 4, message type 513): lightweight, encrypted messages routed through the Lightning network without requiring HTLCs or channel liquidity.

1. A merchant publishes an offer containing one or more blinded paths to itself.
2. The customer's node sends an invoice_request as an onion message, routed through the offer's blinded path to the merchant. The customer includes a reply_path (itself a blinded path back to the customer) so the merchant can respond.
3. The merchant sends back a BOLT 12 invoice via another onion message using the customer's reply path.
4. The customer pays the invoice, routing through the blinded paths specified in the invoice.

Neither party learns the other's node identity. The merchant doesn't know which node requested the invoice (thanks to the customer's reply path), and the customer doesn't know which node received the payment (thanks to the merchant's blinded path). This is a significant upgrade from BOLT 11, where both sides of the transaction could identify each other.

Reusable Payment Codes

Unlike BOLT 11 invoices (which are single-use because each one contains a unique payment hash), BOLT 12 offers are reusable. A merchant can publish one offer string and receive unlimited payments from it. Each payment triggers a fresh invoice_request/invoice exchange with a new payment hash, but the offer itself never changes. Blinded paths make this safe: even though the same offer is reused, each invoice can contain freshly generated blinded paths, so no long-term route information accumulates for attackers to correlate.

Why this matters for merchants: A BOLT 11 invoice is like handing out your home address on every receipt. A BOLT 12 offer with blinded paths is like a P.O. box that the postal service delivers to without knowing your home location. Merchants can print offers on signs, embed them in websites, and share them publicly without revealing their node's position in the network.

Comparison with Other Privacy Techniques

Blinded paths are not the only tool for Lightning privacy. Several complementary approaches address different layers of the problem.

Tor: Different Layer, Complementary

Tor hides a node's IP address at the network layer. Blinded paths hide the node's public key at the protocol layer. A node running over Tor still exposes its public key in every BOLT 11 invoice. A privacy-conscious receiver should use both: Tor for network-layer anonymity and blinded paths for protocol-layer anonymity.

Trampoline Routing: Stronger Together

Trampoline routing lets lightweight nodes (like mobile wallets) delegate pathfinding to well-connected “trampoline nodes” that have a full view of the network graph. The sender specifies a sequence of trampoline hops, and each trampoline finds the detailed route to the next one. This is useful for resource-constrained devices but does not hide the receiver's identity: the final trampoline must know the destination to route to it.

Combined with blinded paths, trampoline routing becomes significantly more private. The final trampoline routes to the introduction node of a blinded path, never learning the actual receiver. Eclair and the Phoenix wallet have been the primary implementations exploring this combination.

Private Channels: A False Sense of Security

Unannounced (private) channels are not broadcast via gossip, but they offer weaker privacy than many users assume. They can be discovered through systematic probing, and BOLT 11 invoices using private channels must include route hints that directly expose the channel's short channel ID and the peer's node ID. Blinded paths are strictly superior: payments route through private channels without revealing any channel details, since the information is encrypted inside the blinded path's data.

Implementation Status

Blinded path support has rolled out unevenly across Lightning implementations. As of mid-2026, production readiness varies significantly.

Core Lightning: Leading the Way

CLN shipped experimental blinded path support as early as April 2020 and has iterated steadily since. The v24.08 release brought production-grade BOLT 12 offers with automatic blinded path creation. When a CLN node has no public channels, it automatically generates blinded paths from its peers. Offers were enabled by default in November 2024.

LND: Catching Up

LND took a different path. It added blinded path route creation in October 2023, sending support through early 2024, and multipath blinded payments in August 2024. LND v0.18.3 introduced blinded path support for BOLT 11 invoices via BLIP39, an interesting approach that brings receiver privacy to the existing invoice format without requiring full BOLT 12.

The v0.21 release (June 2026) added onion message forwarding as a first step toward native BOLT 12 support. However, LND still does not natively support BOLT 12 offers. Users who need offers today can run LNDK, a community-developed sidecar daemon. Strike used LNDK to become one of the first major wallets to support BOLT 12 payments.

Eclair and LDK

Eclair shipped blinded path relay support in August 2022 and receiving support shortly after. Its BOLT 12 implementation is notable for its focus on combining blinded paths with trampoline routing, offering the strongest privacy combination currently available. The Eclair team has noted that generating optimal blinded paths for arbitrary topologies remains an open challenge: they allow node operators to configure paths dynamically via plugins.

LDK (Lightning Development Kit) provides a library-level API for applications building their own Lightning implementations. It shipped blinded path send/receive in September 2023, added compact blinded paths in June 2024, and supports static BOLT 12 offers. LDK's compact blinded path option reduces the encoded size of paths, which matters for QR code encoding of offers.

Known Limitations and Attacks

Blinded paths significantly improve receiver privacy, but they are not a complete solution. Several known attack vectors remain, as documented in the specification's security considerations.

Introduction Node Information Leak

The introduction node's real identity is always visible to the sender. If a receiver uses a low-connectivity or unusual node as the introduction point, the anonymity set shrinks. Receivers should choose well-connected, high-uptime nodes as introduction points to maximize the set of possible destinations behind them.

Payment Probing

An attacker can construct payments with varying amounts and CLTV values, observing which parameter combinations cause failures. By analyzing failure patterns, the attacker can narrow down the characteristics of channels in the blinded segment and potentially identify the receiver. The specification mitigates this by recommending that receivers choose fee and CLTV parameters matching a large subset of possible channels, and by using max_cltv_expiry to limit the probing window.

Invoice Request Correlation

With BOLT 12 offers, an attacker can repeatedly request invoices over time and observe when blinded path parameters change. These changes can be correlated with public channel fee updates visible in the gossip protocol, potentially deanonymizing the receiver. Receivers can mitigate this by refreshing blinded paths less frequently or by using parameters that don't directly reflect their actual channel state.

Uptime Correlation

If nodes in the blinded path go offline, the blinded route fails. An attacker monitoring node uptime across the network can correlate route failures with specific node outages. The specification recommends choosing nodes with high uptime and periodically refreshing routes.

Weaker Than the Original Proposal

Route blinding replaced an earlier proposal called rendezvous routing, which offered stronger privacy guarantees. In rendezvous routing, the receiver constructs a full onion from the rendezvous point to itself, so intermediate hops never see any blinded identifiers at all. Route blinding was chosen as a more practical alternative: simpler to implement, with lower computational overhead. The tradeoff is that blinded node IDs are visible (even if opaque) and the scheme requires more careful defenses against probing.

How Spark Approaches Receiver Privacy

Spark takes a fundamentally different approach to receiver privacy. Because Spark operates on a statechain-based architecture rather than a payment channel network, there is no public network graph for receivers to hide from. Transfers happen through FROST threshold signature key rotations between the Spark operators and the user: the receiver does not need to advertise channels, maintain routing state, or appear in any gossip protocol.

This means Spark inherently avoids the class of problems that blinded paths solve. There are no invoices containing node IDs, no route hints exposing channel structure, and no introduction nodes that narrow the anonymity set. However, Spark's operator set can observe transfer metadata (amounts and participants), which is a different privacy tradeoff from Lightning's trustless-but-observable model.

For the broader Lightning ecosystem, blinded paths represent a critical upgrade. They bring receiver privacy closer to parity with sender privacy, and combined with BOLT 12 offers, they enable a new class of reusable, privacy-preserving payment interactions that were not possible with BOLT 11.

What Comes Next

Several developments will shape how blinded paths evolve in practice:

• LND's native BOLT 12 support (tracked in GitHub issue #10220) will be a tipping point for network-wide adoption, given LND's large share of Lightning nodes.
• PTLCs (Point Time-Locked Contracts) will replace HTLCs and eliminate payment hash correlation across hops, closing another privacy gap that blinded paths alone cannot address.
• The combination of trampoline routing with blinded paths, pioneered by Eclair and Phoenix, may become the default for mobile wallets that need both lightweight pathfinding and strong receiver privacy.
• Compact blinded paths (as implemented by LDK) will be important for QR-code-based offers, where every byte of encoded data matters for scannability.

For a deeper analysis of Lightning's privacy landscape, including sender-side techniques like onion routing and multi-path payments, see Lightning Network Privacy Analysis. For the mechanics of BOLT 12 offers beyond blinded paths, see BOLT 12 Offers Explained. Developers building on Spark can explore the Spark SDK documentation for an alternative approach to receiver privacy that works without channel management or network graph exposure.

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.