With blinded paths, privacy is superior, but not without it, since you're exposing your node's pubkey (assuming you're using your own) and thus your entire balance.
Discussion
the pubkey exposed in a bolt11 lightning invoice never receives any money (it is only used for communication, specifically for signing your invoice and some messages on the p2p communication network) and does not expose your balance
also, anyone who scans your lightning invoice and sends money to you does not learn what address received the money (or rather, they don't learn what address *would* receive the money if the transaction went to chain). They only learn your node's *communication* pubkey, they don't learn where the money actually went per the blockchain's consensus rules.
by contrast, in monero, anyone who scans your monero public address and sends money to you learns exactly what address received the money and they can provably map that "stealth" address to your public address. This is part of how many monero users get caught, e.g. it is how chainalysis learned what transactions to investigate in the following video where they show how they caught a Columbian drug lord:
Lightning receiver privacy is widely known to be notoriously bad without blinded paths
No one is arguing that amounts aren't hidden. We're talking receiver privacy which is the pubkey being exposed.
If that was true, blinded paths wouldn't be needed, and good practice wouldn't be to coinjoin after closing a channel.
> Lightning receiver privacy is widely known to be notoriously bad without blinded paths
People who say that are notoriously wrong
> No one is arguing that amounts aren't hidden. We're talking receiver privacy which is the pubkey being exposed.
The receiver pubkey doesn't receive any money. The pubkey that *does* receive money is *not* exposed to the sender. Well, not in lightning. In monero, it is.
> If that was true, blinded paths wouldn't be needed
They aren't
> and good practice wouldn't be to coinjoin after closing a channel
That is good practice because it's an on-chain transaction, and good privacy on-chain involves coinjoining. It has nothing to do with supposedly exposing yourself via your invoice, which is not a thing. You invented it. Or heard it from someone misinformed.
>"They aren't"
Then why are you always talking about blinded paths as a privacy improvement?
>"That is good practice because it's an on-chain transaction, and good privacy on-chain involves coinjoining. It has nothing to do with supposedly exposing yourself via your invoice, which is not a thing. You invented it. Or heard it from someone misinformed."
You're putting words in my mouth. Show me where I said "exposing yourself via your invoice". As for the rest 👇
"On-Chain Footprint: Opening and closing LN channels necessitate on-chain transactions that are publicly visible and analysable. This creates a "digital fingerprint" that may be used to link on-chain and LN activity....
Public Channel Announcements: Most LN nodes publicly announce their channels to facilitate routing, including the channel's funding transaction. This can link a user's LN node with their on-chain activity....
Invoice Data & Receiver Privacy: LN invoices contain the receiver's public key, and invoices using unannounced channels also include routing hints exposing channel details. This significantly compromises receiver privacy."
"In the Channel Coinjoins chapter we look into the on-chain connection to Lightning, where channel opens and channel closes can harm the privacy of a Lightning node."
"Funding and channel close transactions can be used to link UTXOs to lighting nodes. Not even private channels are protected from this leakage, as sometimes they can publish information on-chain that reveals that the transaction was related to lightning network activity."
https://massmux.org/p/lightning-network-privacy-pros-and
https://lightningprivacy.com/en/introduction
https://www.voltage.cloud/blog/lightning-network-privacy-explainer
> why are you always talking about blinded paths as a privacy improvement?
They help prevent the sender from knowing what routing nodes you're connected to
> You're putting words in my mouth. Show me where I said "exposing yourself via your invoice".
Sorry, I retract that part