Blinded path

The receiver builds the path and hands it out, so the payer routes to a public introduction point and no further. A BOLT 12 invoice is rejected if it carries no blinded path, and the blinded hops share the onion's fixed 1300 byte payload with the rest of the route. If you publish a Lightning destination, blinding keeps your node id off it.

How it works

A blinded path is built backwards, by the node that wants to be reached rather than by the node doing the paying.

The receiver starts with a real route to itself and a random ephemeral key, from which it derives a chain of path keys arranged so each hop can compute the next without being told. Every hop ends up sharing an ECDH secret with the receiver, and two things come out of that secret. The first is a blinding factor, the HMAC of the string blinded_node_id under the shared secret, which the receiver multiplies into that hop's public key. The hop can still sign for the result, because it derives the same factor and applies it to its own private key, but nobody else can match that key against the published graph. The second is an encryption key, used to seal a small instruction blob for that hop with ChaCha20-Poly1305 under an all-zero nonce.

What gets published is short: the introduction point in the clear, one starting path key, then a list of tweaked keys each paired with its sealed blob. Inside a blob are the fields that hop reads: short_channel_id or next_node_id for where the payment goes on, payment_relay for the fee and CLTV delta it must apply, payment_constraints for a maximum expiry and minimum HTLC size, padding, and on the last hop a path_id.

Three of those choices are defensive rather than functional. The receiver, not the payer, fixes the fee and timelock for every blinded hop, so an intermediate node cannot raise its price mid-route and watch which payments fail. It pads every blob to one length and may append dummy hops it discards, so the real length is not readable from the shape. And the path_id holds private data, the preimage for example, so the receiver can confirm a path it built rather than accept one an attacker fired at every node it suspects.

BOLT 12 adds a last piece of camouflage. Instead of a fee per blinded hop, an invoice carries exactly one blinded_payinfo per path: a base fee in millisatoshis, a proportional rate in millionths, one aggregated CLTV delta, a minimum and maximum HTLC size, and a feature vector. The stated reason is that per-hop detail would trivially reveal a non-uniformity distinguishing the path.

Why this matters when you buy bitcoin

Blinded paths change what the middle of the Lightning network learns about you, and change nothing about what your own first hop learns.

Route blinding conceals hops after the introduction point, and says nothing about the node your wallet connects through, which is the one that sees your amounts and destinations. Phoenix, which we rate 4.0 among our 41 wallet reviews, is unusually honest about this: ACINQ's own FAQ says the wallet offers no privacy advantage over a hosted custodial wallet, and that ACINQ knows the final destination and amount of payments. A blinded path in an offer you pay does not touch that.

Custody removes the question entirely. Wallet of Satoshi, which we rate 2.7 and flag with a caution, holds the keys in its custodial mode, so both ends of a payment are its records; it stopped serving US customers on November 23, 2023 and has since dropped the custodial service across the European Union. Nothing of yours gets blinded when the payment never leaves the provider's books.

Where blinding would buy you something is the withdrawal itself. Strike, our highest rated Lightning-first platform at 4.6, adds no fee of its own on transfers and pays out to a Lightning destination you supply. Hand it a BOLT 11 invoice and you hand over your node: the signature carries a recovery id, so the payee key can be recovered from it. An offer puts an introduction point there instead, wherever the payer supports one.

The cost is diagnostic. Hops inside a blinded path return failures carrying no attribution data, and the introduction point is told to add a random delay before passing an error along, so probing cannot measure how far away the recipient is. A withdrawal that fails to a blinded destination therefore tells you almost nothing, so test it from a wallet you control before blaming the platform.

Dave hands Alice a path through Bob and Carol

The Lightning specification works the blinded path idea through with four names, which is faster to follow than the algebra.

Dave wants to be paid without Alice knowing it is him. He picks a route into himself through two public nodes, Bob then Carol, and builds the chain of path keys so all three derive their own. Then he seals three blobs: one telling Bob to forward to Carol, one telling Carol to forward to him, and one for himself carrying metadata and the path_id. Finally he derives the factors that turn Bob into Bob prime, Carol into Carol prime, and Dave into Dave prime.

Alice receives three lines: the first node is Bob, here is the first path key, and here is the sequence Bob prime, Carol prime, Dave prime with a sealed blob against each. She reaches Bob over the ordinary public graph, which is deliberate: the specification recommends an unblinded leg to the introduction point, because it needs no support from the nodes in between and it returns errors you can read. Bob unseals his instruction, learns only that Carol is next, and passes the derived path key along with the onion. Carol uses that key twice, once to tweak the onion, which Alice encrypted to Carol prime rather than Carol, and once to unseal her own instruction. Dave receives it last and checks the path_id before accepting.

Count what each of them ends up knowing. Alice knows Bob. Bob knows he is an introduction point and that Carol is next. Carol knows a blinded payment passed through her and cannot tell whether Dave is the recipient or another relay. Dave knows everything, because he is the only one who built it.

Blinded path vs route hint

A blinded path and a route hint answer the same question, how to reach a node the public graph cannot see, and give away opposite amounts doing it.

A route hint is the r field of a BOLT 11 invoice, and it is plain text. Each entry carries a 264 bit public key, a 64 bit short channel id, a base fee, a proportional rate and a CLTV delta, all in the clear, so anyone holding the invoice knows which well connected node you hang off. A blinded path names the introduction point and then goes dark: every later hop is a tweaked key matching nothing in the graph, and the fees arrive aggregated rather than itemised. Blinded paths also take over a job route hints never had, standing in for the payment_secret and payment_metadata fields of a BOLT 11 invoice.

Blinded path vs onion routing

Onion routing hides the payer from the hops; a blinded path hides the payee from the payer.

In plain onion routing the sender picks every hop out of the public graph and wraps one encryption layer per hop, so no forwarding node learns who is paying or where in the route it sits. The sender still knows the whole route including the destination's real node id, which is fine for paying a shop and useless for publishing a reusable destination. Route blinding supplies the missing half without replacing anything: a payment through a blinded path is still an onion, and the blinding is a key tweak layered on top. They are separable enough that a receiver who does not want the privacy can build a one hop path containing only itself and give away its node id anyway.