It's early and I'm a but tired still, not to mention way out of my depth on the technicals.

The use case I'm referring to is a sender following what goes on with a receiver. That framing, perspective, or whatever you wanna call it, is not that contrived is my point.

Just stating what I'm interpreting from exchanges. There's prob some nuance I'm missing, but I follow well enough and am learning some things :)

> How is that a use case, let alone a non-niche one?

It is a use case because many people get in trouble due to the sender disclosing info about the recipient to the police. E.g. read this case about tracing a monero user from Finland: https://www.reddit.com/r/Monero/comments/19emsfe/finlands_national_bureau_of_investigation_claims/

The Finnish police "made an information request to the [monero user's] exchange." It was an anonymous exchange, so they did not have his identity, but they did have his monero public address and his on-chain pubkeys, because he withdrew from the exchange to his self-custodial wallet. The exchange gave that info to the police, who watched the blockchain to see where the money went next, and traced it to Binance, a KYC'd exchange, where they got his identity info and arrested him.

The first step in this case was asking the sender (a no-KYC exchange) for whatever info they had about the recipient. Since they knew what pubkey they sent the money to, they were able to give this info to the police, and it was very useful to them. So it's not "niche" -- it's a verhy common thing for the sender to log info about the recipient, and among exchanges, it's very common to share that info with law enforcement officers.

Not letting exchanges have that info in the first place is very good for your privacy, and lightning makes this easy: you can give the exchange an invoice with a decoy pubkey in it, so that it doesn't even belong to you, but even if you *do* give them a pubkey that belongs to you, your future transactions don't show up on a blockchain, so there's far less info for them to track.

> is [there] some time where you need to not know where you're sending money?

Yes, the above example is precisely that kind of scenario: the non-KYC exchange in the Finnish case did not need to know what pubkey received their money. Lightning gives us a way to get the money to the right guy without revealing his pubkey to the sender. So why not do that? Why not adopt this superior privacy technology when the alternative is to keep using monero and keep going to jail?

Thanks, that makes sense.

> the sender doesn't know what happens afterwards, therefore trackign isnt possible

Chainalysis managed to do it multiple times in the attached video, starting at 26:55.

They start with the easy "first step" where Morphtoken told them they sent the money to the perp. From there, they trace it forward four times. At 30:43 they identify a payment from the perp to either ChangeNow or Liquid Exchange; at 32:49 they identify a payment from the perp to Exodus Wallet, though they say even their advanced tracing software was not able to generate high confidence for this particular trace, and they aren't sure where he sent it, nor which output was his change output.

The trail runs cold for that particular txo, so at 34:55 they go back to the drawing board and identify a different "first step" where Morphtoken told them they sent money to the perp. At 35:08 they conclude that he sent this txo to one of two places: Exodus Wallet or a mining pool.

From there, they successfully identify his change output (at 36:36) so they continue tracing the perp's money, where they learn -- at 36:51 -- that sent his money to a centralized exchange or a merchant's point-of-sale website. One of those confirmed that he sent his money to them and that they had his identity info, which is how they nabbed him.

So yeah, saying it "isn't possible" is completely false -- Chainalysis sometimes manages to do it and there is a video explainer of how they do it with plenty of screenshots so you can follow what's going on.

https://v.nostr.build/D4Nzp22vRF35IRnz.mp4