lnd
lnd copied to clipboard
lightningnetwork
[Question] Watchtower database cleanup?
I have a watchtower on a separate server that stores the commitments from the main node. The database size grows steadily as traffic is pretty good on the node. I'm wondering if it's possible for the watchtower to remove the commitments for the channels that were already closed. I suppose it doesn't know what channel these commitments are related to so it can't clean them up by itself. Is it possible to do from the node? Or is the database going to grow indefinitely there?
We have a watch tower message that the client can send to the server to delete the old session state: https://github.com/lightningnetwork/lnd/blob/a329c8061266418bccd797aa5d7d277c736ee930/watchtower/wtwire/delete_session.go#L5
A tower doesn't know which channel it's watching on chain until a breach actually happens. If no breach happens, then it doesn't know that it can forget that old channel state.
The missing link here is an exposed client side command to delete old sessions, but ideally taking care to avoid a casual link between the deletion and the channel closing (so naively wait for N blocks or w/e until sending that message).
That's only possible if all channels that were backed up to the old watchtower were closed. Currently lnd only uses the first WT in the list even if multiple were added. I can, of course, simply recreate the WT from scratch and hope no other node would try to cheat but that defeats the purpose. Also, if it's only possible to only delete entire sessions I think it'd be problematic to clean them up. One session can store up to 1024 commitments (I guess?) so naturally most of the channels would have a commitment backed up among them. Untangling it isn't really worth it.
yeah I mean remove the first one, I don't think the cheating time window would be huge between going from A to B
But if I remove the first WT that means all channel states from it become vulnerable. So if any peer that still has a channel with me that was opened before the switch can try to cheat and close that channel using a commitment that was backed up on A that I've already deleted. In case my node dies and I need to recover using SCB, that WT is all that protects me from my peer's cheating. So unless all channels that ever backed up to A are closed I can't retire it safely.
Hopefully, we'll have WTs standardized and the protocol would be well thought-out. Of course, this cleanup routine can only be done voluntarily by the client but for my own WTs it's what I want and for the 3rd party paid WTs (that don't exist just yet) there could be incentives to clean up like refunds if the client pays for storage.
they aren't vulnerable if the existing node is still watching it since the wt is just redundancy, but yeah if you did that I wouldn't delay in between the switch. your peers also don't necessarily know this timing as well so they'd have to guess that this timing is the right timing, and if they guess wrong they forfeit funds
Of course, except if the node crashes and all you have is partial backups of your old channels on the WT B. Tbh it's already like that since I started my WT only recently so I already don't have the early commitments backed up. And yes, the probability of cheating is very low because it's a risk and it has to be set up in advance by the attacker. Still, not zero and something to consider, especially when LN becomes really huge.
Following this. To chime in, my watchtower.db is over 13GB, compaction adds 16min to my startup/restart time. Seems I need to make a new WT and tell my peers to use that one, not ideal. Following hoping for a better way ;)
I started my WT only recently so I already don't have the early commitments backed up.
this seems like something we can fix too. Should be possible to register a session for an older channel and then give the tower everything it needs so that it can protect all past states of the channel right?
