pull down to refresh
Like ZmnSCPxj mentioned, there is some additional overhead compared with running a normal Lightning node, but how much depends a lot on the integration.
If VLS is integrated into a wallet or managed Lightning service, most of that complexity can be handled by the wallet/service. If you self-host, you also need to deploy and maintain the signer infrastructure yourself.
Beyond that, the operational overhead depends on how you want to use VLS and how much you automate. For example, you can automate policies, approvals and alerts, and choose between an always-on signer or setups where an always-on signer can receive while a more protected signing device only comes online when you want to send.
So VLS does add another layer to operate, but there’s a pretty wide spectrum between a highly automated integration that users barely notice and a more hands-on, security-focused self-hosted setup.
I should also probably shill my old project CLBOSS, which is really useful to make any CLN deployment a practically-hands-off thing, just load it up with sats onchain and let CLBOSS rip. ksedgwic, who used to be a VLS contributor, is the current CLBOSS maintainer (LOL we basically swapped projects).
I did not know about CLBOSS, very cool!
Largely you probably want to use CLN. We have some instructions on how to deploy with CLN: https://vls.tech/docs/latest/get-started/cln-vls/ . We have the theoretical ability to connect to an LDK-based node, but we cannot connect with the "official server version" ldk-node project yet. We have a separate LDK-based project, lnrod, whose instructions for integration are: https://vls.tech/docs/latest/get-started/ldk-vls/ , and you can also dive deeper into the actual codebase if you are writing your own LDK-based node software for how to integrate it.
I suggest running at least one extra machine: a very secure machine, ideally domiciled by you and not hosted on cloud or remote rack, that will run VLS. I would suggest locking all incoming ports in the firewall for this machine (VLS actually "connects out" to the node, instead of being a server and waiting for the node to connect in) and disabling everything, including SSH on the machine (i.e. use the machine's console directly). The "connect out" gives a tiny security boost, in that you can actually lock out many possible attackers by simply completely disallowing incoming connections and only allowing outgoing to the very specific node software machine.
In addition to VLS itself, you need TXOO server, which you can probably run with the machine that runs bitcoind. CLN needs a bitcoind as well anyway.
As to overhead, additional network roundtrips will occur due to the node software having to call out to the VLS machine. How much impact this has will depend on your setup between the VLS machine and the node software.
Hey guys! Thanks for doing this.
How much extra effort is involved in using VLS with a lightning node as opposed to normal lightning node management?