I am not sure that you fully understand that there is no privacy in lightning zaps. The zap event is killing any sense of privacy or anonymity you think you have. Saying that lightning zaps is a "sane" privacy implementation is worse than having public onchain zaps.

Replies (13)

Correct. But that doesn't mean it's private at all. An attacker still sees everything in and out via zaps, which is how most people use it. Our defaults have never ever been private.
All the zaps that I have received so far, what did I spend them on? Can you tell? Did I even move those sats at all? Where did the sats go after I’ve received them? Less importantly: Is it possible that some of the zap receipts were faked, and thus there’s “zap events” out there that didn’t even move sats at all? Even less importantly: I had many lightning addresses attached to my profile up to now. Is it possible that one of those lightning addresses was controlled by someone else, and not me?
> Saying that lightning zaps is a "sane" privacy implementation That's not what I said. When it comes to zaps, Lightning is the sane choice, because of its properties. Using on-chain for those public payments is NOT the sane option, since on-chain leaves a trail that is forever auditable. “Forward secrecy” (if you want to call it that) does not exist. Plausible deniability does not exist. The option to say “I never touched that money” doesn’t exist. The option to say “I lost access to this wallet” does not exist either, unless you nuke your nsec.
We are not using "lightning", we are wrapping a lightning proof into signed events with the sole purpose to identify the parties involved. Yes: forward secrecy doesn't exist, plausible deinalibity don't exist. But not because of some on chain zaps implementation, but strictly because you are singing with public key cryptography and advertising your pubkey key as yourself to everyone. That is the definition of *verifiably* doxxing yourself. You are arguing against pubkey key reuse while reusing the same nostr key to sign the same thing you want a new key for.. nothing here makes any sense.
I mostly agree Vitor, but it depends on what you mean by "everything". A zap is a public record that one person made a payment to another person The question is whether the public record should also (implicitly or explicitly, it doesn't matter) point to the on-chain transaction That appears to be the real issue you all are discussing, and the issue would still exist even if each payment was to a different address Define "Noisy Payment" as a Silent Payment, but with a public event linking to the txid. Would that be a fix for onchain zaps, because it avoids address reuse; or equally harmful because the public can still see all the transactions?