> we have lightning payments but there is no privacy

I can't agree with a statement like "lightning payments have no privacy." Lightning provides a pretty strong baseline for privacy. It's not perfect (it's not even good, absolutely speaking), but it's not nothing, and if used carefully (e.g. if you run your own lightning node on tor and learn how to manage channels) I think it's better than alternative solutions such as monero. Still, lots of work to do, and I'm glad it's being done.

Running whatever version you want is exactly what the loud noises are all about

Zaps face a different privacy challenge: the protocol requires the sender and the recipient to identify themselves and the amount sent, and publish that info for all to see in a "zap receipt." It is possible to use zap infrastructure to send someone money without publishing a zap receipt, and this would help privacy conscious people, but I don't think anyone has built an app for that.

he has been near bitcoin since 2010 so what does that make bitcoin?

if you're running Zeus and not running a full node then you're trusting whoever *is* running a full node. In Zeus's case, this means you're trusting the nodes your Zeus wallet reaches out to for bip157 filters.

I guess bitcoin can't be good then

> Will the big nodes execute it? How do we know they're executing it? Are we turning privacy into a matter of faith?

I think this gets really interesting if/when routing nodes start publishing privacy policies, e.g. "we do not log payments." Then you can start to build routes that *do* have some cryptographic guarantees. E.g. "if I route my payment through N nodes with zero-log policies, then even if only 1 is honest, an attacker gets subpoenas records from every node on my route *still* won't find full records of my payment."

Many cryptographic protocol rely on assumptions like that one. Tor works like this and Dandelion++ works like this, for example. Lightning has always had privacy assumptions that work best when routing nodes don't collude together, but these assumptions are undermined if attackers can easily access node logs and thus effectively *force* them to collude after-the-fact. If every node has the ability to easily delete logs, that makes lightning's privacy assumptions stronger, because it makes it more likely that an attacker who tries to acquire those logs won't be able to get them.

Goofus and Gallant

On a related note: @nevent1qvz...

Yes, there is still work to do. The docs mention the possibility of adding "Automatic Scheduled Deletion" as an enhancement. I hope they do, and I hope they turn it on automatically.

There's another enhancement that I hope to bring up after the DeleteFwdHistory command goes live (one thing at a time): besides forwarding logs, LND has two other log files, "normal" logs and "revocation" logs, and whenever a payment gets logged in the forwarding logs, those *other* logs *also* get an entry containing similar information.

But the new command does not delete records from those other log files, it only deletes records from the forwarding logs. So even after DeleteFwdHistory goes live, an attacker who gains access to your node could still reconstruct past payment flows even if you ran DeleteFwdHistory on a regular basis.

The docs mention two mitigations for this: you can set up automated systems to manually purge your normal logs, or tell LND not to keep normal logs at all. That can be used in conjunction with DeleteFwdHistory to delete 2/3s of the sensitive records about forwarding history.

But that doesn't fix the problem with revocation logs. LND doesn't let you easily delete those log files because they contain information that it "needs" in order to safely perform force closures if needed. The docs only mention one solution for deleting sensitive information from those logs, and it's a pretty nasty one: if you close any channel, that channel's revocation logs automatically get deleted.

A node operator with a 90 day retention policy (for example) could schedule their computer to run DeleteFwdHistory every 90 days (which would solve 1/3 of the problem) and tell their node not to keep normal logs (which would solve an additional 1/3 of the problem). To delete the last 1/3 of the logs (the revocation logs), the node operator could schedule their computer to close each channel in their node 90 days after it is created. But that would make such nodes less competitive, as channel closures cost money, and they'd have to pass on those costs to their users.

So after the DeleteFwdHistory command goes live I plan to ask them to "enhance it" so that it *also* deletes sensitive info from the revocation logs. The revocation logs do not need to retain "all" info about past payments; they need to keep something called a "revocation key" and they need to watch for a certain transaction id to appear on the blockchain (or in the mempool). The DeleteFwdHistory command could safely delete all other data in old revocation logs, and then node operators would no longer need to close any channels in order to automatically delete all of the sensitive information from their old records.

But one thing at a time! I'm glad the new feature is almost ready and I'll wait til it goes live before I request this enhancement.

I ran those first 6 paragraphs through Grok and asked it to rewrite them in simpler terms. I think it did a good job, so I copied the result here:

https://telegra.ph/Grok-Explains-Forwarding-History-01-29