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.
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.