1. Making it short,1. Making it short,

If you're running a Lightning node and generating invoices without blinded paths, you're basically handing out your home address to every person you do business with. Your node pubkey, your (public) channels, your (public) liquidity. Yes, all of it visible to anyone who catches a sniff of your invoice.

2. Which apps today offer blinded paths option?2. Which apps today offer blinded paths option?

Right now, basically one wallet exposes this from the UI: ZEUS.

Kudos to @evankaloudis for being a pioneer adding BOLT11 blinded path support in v0.9.1. Users can opt into them by hitting the Blinded paths toggle on the Receive view, as long you use it connected to your LND backend running v0.18.3-beta or higher. That toggle is the only place in any major wallet UI where a regular end user can generate a blinded path BOLT11 invoice without touching a terminal. It should be a default on any LN wallet.

Why? Learn more about possible attacks when generating invoices without a blinded path option activated.

3. WTF is a blinded path anyway?3. WTF is a blinded path anyway?

When you create a normal Lightning invoice, your node's public key is sitting right there in the invoice for everyone to see. But don't trust me, try to decode one of your invoices here and verify it yourself. Hand that same invoice to someone, or worse, naively post it publicly, and anyone can go look you up on Amboss or 1ML, see every public channel you have, estimate your balance ranges, and start building a pretty detailed picture of who you are on the network. Not ideal if you care about privacy.

Solution? A blinded path replaces your node ID in the invoice with an encrypted breadcrumb trail. Instead of "pay to MY_NODE_PUBKEY", the invoice says "pay to this introduction node, and here's an encrypted blob that will guide the payment the rest of the way." The sender, and every routing node along the way, only ever sees up to the introduction node. Everything after that is ciphertext. Your node stays out of the picture completely because that "introduction node" will ideally differ for mostly every invoice.

The cryptographic spec for all this lives in BOLT4 (onion routing), and the way blinded paths get stuffed into a BOLT11 invoice is defined in BLIP-39. There's also a good discussion thread on DelvingBitcoin if you want to know how the spec have been written.

Four reasons for you to careFour reasons for you to care

Beyond the obvious "bro, privacy is good" that everyone says and then ignores themselves, there are concrete situations where blinded paths genuinely matter:

You run a routing node and you don't want to be fingerprinted. Your pubkey, your IP, your peer list, your channel capacities — all of that is gossiped publicly. Fine, that's the routing node game. But your INVOICES don't also need to be a map leading straight to your door. Detach yourself from your node!

You have private/unannounced channels. If your channels aren't gossiped to the network (common in mobile wallets, LSP setups, or just for privacy), blinded paths let you receive payments over those channels without revealing they exist to the payer. Previously you had to include route hints that literally named your private channel peers. Not anymore.

You run a merchant setup or any kind of service. Every invoice you hand out is an opportunity for a nosy counterparty to correlate your Lightning activity with your on-chain UTXOs, your business volume, or your node's real-world identity. Blinded paths cut that correlation off.

You care about the whole network's privacy, not just yours. The more nodes support blinded paths as intermediate hops, the better the anonymity set for EVERYONE using them. It's a network effect — you opting in helps the next person. Read the Lightning Privacy research on blinded paths if you want a deep dive into how that plays out.

Five Tradeoffs: because nothing is freeFive Tradeoffs: because nothing is free

Stop right here if you thought this was all upside. There are relative added costs on using blinded paths

• Your invoices get FAT. A BOLT11 invoice with 3 blinded paths of 3 hops each can be 2–3x longer than a normal invoice. But who cares? you are copypasting it anyway and in the best case scenario, the payer will do the same because static QR codes become unusable at that size. Optional support for NFC, LNURL or animated QR codes should be considered by builders of the present and future LN apps.
• The payer pays a tiny bit more in fees. Routing through extra hops, including dummy hops that are added just for padding, means more routing fees. Nothing dramatic, but it's real. Wallets should handle this automatically, so just don't be surprised if the fee estimate looks a touch higher.
• Payments can fail if your intro nodes are offline or dry. LND addresses this by including up to 3 alternative blinded paths per invoice, so the payer has options. But if all your paths go through the same one peer who's having a bad day, you're going to have a bad day too.
• Every node IN the blinded section of the route must support route blinding (feature bit 24/25). This is increasingly standard in 2025 but not universal. If your blinded path passes through a node running ancient software, it won't work. As adoption grows, this matters less and less.
• Small node = weaker privacy. If you only have 1–2 public channels because you wanted to route some traffic and profit 1-2% of yield on your stack, an adversary can still do fee/CLTV correlation analysis around your introduction node to narrow down who you are. The original route blinding proposal gets into the math. TLDR: more channels and more peers = stronger privacy. If you're running a tiny node with one channel, blinded paths help but aren't a miracle.

6. Current implementation status6. Current implementation status

Bitcoin Optech keeps the completest tracker of every blinded path PR across all implementations at their route blinding / rendez-vous routing topic page — bookmark it if you want to follow the state of play over time. Here summarized in a table:

⚗️ = exists but test on signet or testnet before putting real sats on the line.

7. LND — the easiest one7. LND — the easiest one

if your run LND 0.18.3 or older versions (check with lncli version), update your node before reading any further).

LND's implementation landed across PRs #8095, #8142, #8735 and #8764 and shipped stable in the https://github.com/lightningnetwork/lnd/releases/tag/v0.18.3-beta. It's the most production-ready blinded path implementation in any node software right now.

There's NO config flag to flip, no daemon restart needed. Blinded paths are a per-invoice opt-in. You just add --blind when you generate an invoice via cli. That's literally it.

# The simplest possible blinded invoice
lncli addinvoice 1000 --blind

# Fine-tune the path construction
lncli addinvoice 1000 --blind 
  --num_blinded_hops 3 
  --min_real_blinded_hops 1 
  --max_blinded_paths 3

# Keep a specific peer out of your blinded paths
lncli addinvoice 1000 --blind 
  --blinded_path_omit_node <their_pubkey>

Your real pubkey is nowhere in there. Beautiful, isn't it?

Without going to much technical, if you like check Lightning Labs's reference with a real decoded blinded invoice example at their blinded paths builder guide.

8. Core Lightning (CLN) — flip one config switch8. Core Lightning (CLN) — flip one config switch

CLN's approach is different from LND's. There's no per-invoice --blind flag. Instead, you enable experimental features at the node level, and CLN starts doing the right thing automatically — especially for nodes with private/unannounced channels, where it includes blinded paths without you even asking.

Just add this to your ~/.lightning/bitcoin/config:

enable-experimental-features

Or pass it at startup:

lightningd --enable-experimental-features

Restart your node. After that, generating an privacy-enabled invoice is the normal flow:

# CLN includes blinded paths automatically for private nodes
lightning-cli invoice 100000msat "my-label" "some description"

# Check what CLN actually put in the invoice
lightning-cli decode <invoice_string>

For public nodes with announced channels, CLN's automatic blinded path inclusion is more situational, as it depends on your graph position. Inspect your node's feature lst with lightning-cli getinfo and look for option_route_blinding to confirm is active. Full config reference is in man lightningd-config or on the CLN GitHub repo.

CLN also exposes a getroutes RPC if you want to manually construct blinded path candidates for more advanced setups. The CLN v24.08 release notes cover blinded path improvements for unannounced nodes specifically.

Eclair — protocol support, but BOLT11 receive isn't there yetEclair — protocol support, but BOLT11 receive isn't there yet

Eclair (ACINQ's implementation, the same engine powering Phoenix server-side) has solid blinded path support at the PROTOCOL level. It can forward payments through blinded routes, participate as an intermediate node, and it can PAY invoices with blinded paths generated by LND or CLN without a blink.

What it doesn't have yet is a clean way to GENERATE a BOLT11 invoice with blinded paths on the receive side. That's still in progress. The Eclair v0.11.0 release is where ACINQ documented their protocol-level blinded path support. Watch the release notes and the Eclair API docs for when blinded BOLT11 receive lands.

If you're running raw Eclair and need blinded receive privacy TODAY, you're waiting on ACINQ for now. Phoenix wallet users get some protection at the LSP layer automatically, which helps increase privacy.

What's still in progressWhat's still in progress

Eclair BOLT11 blinded receive is the main gap. ACINQ is working on it. Track the Eclair releases page.

Wallet UI exposure. Most GUI wallets built on LND haven't surfaced the --blind flag yet. Zeus, ThunderHub, Ride the Lightning, Alby — as LND stable ships this, expect them to add a toggle. Bug your favorite wallet team if they haven't.

Network-wide forwarding adoption (feature bit 24/25). The privacy guarantee scales with what percentage of the network can actually FORWARD blinded payments. Track node feature adoption through Amboss or 1ML graph stats. The more nodes opt in, the better it gets for everyone.

BLIP-39 finalization. The spec for the b tagged field in BOLT11 is still a draft. Follow it at the BLIPs repository. If you're building production systems against it, watch for changes.

Now go update your node and start generating blinded invoices. Your privacy is worth the extra 30 seconds it takes.