hsmd: Implement hsmd_forget_channel for Channel Deletion in HSMD

[ksedgwic]

Changelog-Added: hsmd: Added hsmd_forget_channel to enable explicit channel deletion. ([#6987])

Motivation: Previously, a signer prematurely forgetting a channel led to failures in unresolved channel requests. This update introduces hsmd_forget_channel, allowing nodes to explicitly notify signers when a channel is irrevocably resolved and can be safely forgotten. This ensures synchronized channel cleanup between nodes and signers.

This change maintains backward and forward compatibility. Nodes explicitly check whether a signer has WIRE_HSMD_FORGET_CHANNEL capability before sending the message. Nodes without WIRE_HSMD_FORGET_CHANNEL capability won't send this message. Signers capable of handling this message but not receiving it will continue to use conservative pruning methods.

Fixes #6987

[vincenzopalazzo]

ACK eb9f729

IMHO, this is a nice feature to have. Otherwise, we must assume that both the signer and the client are on the same blockchain. Of course, it's highly unlikely for a reorganization of the blockchain to happen that's significant enough to reactivate a channel (requiring at least 100 blocks). However, I do appreciate that the cln notifies the signer before deleting the channel itself

[cdecker]

Thanks @ksedgwic for this patch, communicating explicitly is often better than doing so implicitly. I'm wondering if a malicious client causing the signer to forget about channels that are still active is part of the attacker profile, or if we assume that such purely malicious attacks (griefing because the funds become unspendable until close) are out of scope.

[ksedgwic]

@cdecker Yes, this is a concern, but it is not as simple as that ...

The VLS signer does not immediately remove the channel when it receives hsmd_forget_channel; instead it marks it as saw_forget_channel and then removes it after our chain watching and depth sensibilities (100 blocks) have passed.

If we haven't seen the hint we wait for an extra conservative depth (currently 2016).

So this is a bit of an exploit window if the attacker can "stagger" CLN and VLS with VLS ahead and then issue the bogus forget to VLS when in fact CLN hasn't quite forgotten yet.

VLS doesn't delete the channel until it is confident it can be forgotten. If CLN is tricked into asking about the channel after that we crash, but no money should be lost since the channel should actually be "safely landed" onchain so this is sort of a different kind of bug ...

The VLS security model certainly intends to protect against purely malicious (griefing) attacks.

[cdecker]

Gotcha, thanks for the clarification, of course the soft-delete in VLS is a great idea 👍