Replies (18)
This feature is expected in the v0.21 release of LND, which itself is expected around April 2026
Note this advisory for any node runners who want to use the new feature:
What Deletion Doesn't Protect
The revocation log for active channels contains information that can be used to reconstruct transaction flows. Once channels are closed, this data is automatically deleted.
The normal logs of a node also contain information that can be used to correlate transactions. Users can set up automated systems to manually purge logs, or configure the logging directory to a purely in-memory file system.
-----
End of advisory.
Anything Peter Todd wants can fuck right off.
What about what Super wants. If Super and Todd want the same thing, does it fuck right off only partially?
This should be standard.
Is there any article related to this so that normal people like can understand this
why? Bad people can have good ideas too.
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.
On a related note:
Super Testnet
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.
View quoted note →
If you were trying to sell me something, would you mention that Stalin and Mao also own this thing? Maybe it's true, but hey maybe forget to mention Satan during your sales pitch.
Well, maybe mentioning that Stalin, Mao, Trump, Musk, etc. use the same toilet would make you consider the toilet on its merits rather than who's butt sits on it when that's irrelevant for your individual choice.
I think the difference here is that you thought of this as a sales pitch and I saw Super highlighting important implementation addition that I very much want.
Hey regardless, anytime that retard Peter Todd is mentioned is an opportunity to say fuck that retard, so I thank Super for the opportunity.
Thank you for taking effort 🙏 understood the whole topic now i am very clear
One question is Does nostr zaps also face same challenges?
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.
On primal Zaps are used like appreciation but lets say if i want to buy something from nostr marketplace or anything which requires paying bitcoin then there are limitations, there are silent payments but they are slow , we have lightning payments but there is no privacy and if we dont find solution for this , then this will be a biggest threat for web3 user
> 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.
