pull down to refresh
As a concrete example: You can configure a policy that will make VLS limit the amount of satoshis that can be sent per unit of time (i.e. the "velocity" of sent payments).
Then if you are integrating the node software in a larger service that has to send out money for any reason, if THAT service is compromised and starts trying to send out as much of your funds as possible, then the VLS policy triggers and stops outgoing transfers beyond the velocity limit you sent. This can at least prevent some losses.
Similarly, if your larger service is compromised and the node happens to have onchain funds, you can set policies that limit what onchain addreses can be sent to, so that the even if the larger service that uses the LN node is compromised, VLS can at least prevent some of the theft attempts.
As for something VLS CANNOT protect you from: you probably want to run some kind of node manager that automatically reopens channels that get closed. If THAT manager is compromised so that it always points your liquidity at specific nodes (and thus distorting the Lightning Network fee market in favor of those nodes) VLS cannot really detect and protect against that. Similarly, if you have policies that would prevent you from interacting with certain nodes, operators, or IP ranges, VLS cannot really prevent your node from connecting out to those, it is ONLY a signer.
I'm not the most knowledgeable with Lightning, so forgive me if this is an ignorant question, but if I'm running a routing node, is there way that my VLS polices get included in gossip? How will other nodes know that they can't send the full amount of liquidity on my node?
I think there is no way to do that in the gossip map, unfortunately.
We probably should implement a velocity setting for arbitrary outgoing payments that is separate from forwarding, however, since it is the arbitrary outgoing payments that is the theft risk: we should generally be willing to forward any amount out as long as we get more in an incoming HTLC.
A useful way to think about it is: if stealing the funds requires the node to obtain a signature it shouldn't get, VLS can potentially stop it. If the loss happens despite the signatures being valid, VLS usually can't.
So VLS is strong against compromised nodes, wallet/API bugs, excessive fees, repeated or unauthorized payments, and Lightning state transitions that violate its policies, because the signer can independently refuse them.
It's less effective against things like DoS, confirmation/mempool attacks, or bugs in how the node constructs and broadcasts an otherwise valid on-chain claim. In those cases there may be no bad signature for VLS to reject, although independent monitoring can sometimes provide an alert.
That's also what we found when we looked at 17 real Lightning incidents and disclosed vulnerabilities: some could have been directly prevented by signer-side policy, some could have had their damage limited, while others were outside the signer's control entirely.