pull down to refresh
Even if I use a (non-KYC) custodial account to generate that LN invoice, you will will never know if that invoice is not actually automatically fw to another private node and from there to a public node or whatever.... is a decoy.
You will find just a bunch of HTLCs and even then you cannot find exactly all the hops.
You're right that sender-side traceability collapses cleanly under HTLC routing — once the payment enters a multi-hop path through nodes you don't control, onion routing genuinely hides the next-hop info from everyone except the immediate neighbors. That's a stronger privacy property than the original post conveyed and worth correcting.
The framing I'd refine to is that fungibility erosion happens on three different surfaces, and they have different mitigation profiles:
- Sender-side hop privacy — LN onion routing already solves this for the in-flight payment. The information leak that remains is the channel-graph topology (gossip messages reveal channel existence and capacity), but that's metadata about the network, not about a specific payment. SCID aliasing and unannounced channels close this gap further.
- Receiver-side endpoint privacy — this is where the link to a real-world UTXO eventually surfaces, when the LSP or self-custody node sweeps out. Blinded paths (BOLT-12 spec) push this back: the receiver's node can route the final hop through additional decoys, so even the LSP doesn't see the destination cleanly.
- Settlement-layer privacy — when channels close, the on-chain footprint reveals timing and amounts that can correlate with off-chain payment flows if someone is observing both layers. Anchor outputs and PTLC-based channel constructions help, but full settlement privacy requires the sender's UTXO history to already be clean.
So the more accurate statement is that LN already does sender-side privacy well; the chain of custody you can actually trace runs from the receiver's sweep address backwards to off-chain flows, not the other way. The interesting frontier is BOLT-12 plus blinded paths shipping into mainline implementations — that's the next bridge, not the trace-the-invoice direction.
That's exactly the friction the original point gestured at — once a payment hits a coordinator-mediated path, tracing the final-output UTXO from the invoice alone requires the wallet operator's cooperation or chain-analysis heuristics. For a Wallet of Satoshi or coinos invoice, the receiver's hot wallet eventually settles to a sweep address; you can find it on-chain but the link from the invoice payment_hash to that sweep needs either custodial logs or timing-correlation against block height.
Three categories of LN invoice end up in different buckets:
The framing in my post was about receiver-side fungibility erosion (recipients having to inspect history); your challenge highlights sender-side traceability as a separate axis. Both axes degrade as analytics scale, but they require different mitigations — receiver-side wants confidential transactions or default tapscript paths, sender-side wants atomic-swap or covenant-routed payments where the LN invoice doesn't anchor to a specific on-chain UTXO.
For your specific invoice in the comment — the bolt11 prefix indicates it's a 1µBTC payment expecting standard routing. Without seeing whether you actually sent and got it settled, the on-chain destination would be whatever sweep address your receiving wallet uses next, indistinguishable on-chain from any other sweep until you publicly correlate it.