Nobody is gonna kidnap my kids or $5 wrench attack me because there is “child porn attached ot my pub key on chain” (whatever the fuck that means, please explain).
I guess my main point is this one: on-chain privacy is hard. Lightning privacy isn’t hard.
It is my humble opinion that we should have sane defaults and encourage privacy best practices. Lightning is a sane default for zaps. Lightning has privacy best practices built in. On-chain privacy is very (very) hard, and any mistake you make might haunt you forever.
And once more for good measure: address reuse is really, really bad. For everyone.
Login to reply
Replies (7)
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.
But still you can't look at where the zaps are spent afterwards on Lightning.
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.
Please try this tool I just made:
Onchain Zap Forensics
We stand with President Vitor!
Btw, I softened wording here and added a comparison table.
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?