pull down to refresh
So, if I understand it right, VLS is like a notary that reads the contract before signing it. Where do those rules come from?
That's a pretty good analogy. The important part is that the notary has its own copy of the rules and its own record of what has happened, rather than trusting the person handing it the contract.
The rules come from two places. First are Lightning protocol safety rules encoded in VLS: things like not signing revoked channel states or invalid HTLC/commitment transitions. VLS independently tracks enough channel state to enforce those rather than asking the node whether something is safe.
Second are policies chosen by the user or the wallet/service integrating VLS: things like approved destinations, fee limits, spending controls, or requiring additional approval.
So the node basically says, “please sign this,” and VLS asks both: is this valid Lightning, and is it allowed under this user's policy? Only then does it sign.
Thanks for the explanation. If the policy is what decides, I imagine it lives in the signer. How do you make sure the node can't touch it?
the policy setup is on the VLS machine itself as part of the VLS configuration, and there is also a VLS command interface that lets you tweak some policies (like e.g. adding addresses to the allowed-to-be-sent-to list). Assuming your VLS machine is not compromised (it can be hardened, e.g. by firewalls that disallow all incoming connections since VLS itself makes an OUTgoing connection to the node) then the node cannot change the VLS policy.
Now, in theory, the VLS software can be compromised by some protocol shenanigans with the node software itself (e.g. some parsing error in the node<->VLS protocol might lead to a buffer overrun?), but now you are compromising both the node software and VLS, which is something of a failure mode we really cannot protect against; our security argument is that compromising the node software (which generally needs to be allowed to accept incoming BOLT8 connections, and has to handle stuff like gossip maps and routing) is a lot easier than compromising the VLS machine (which as noted can be hardened by disallowing all incoming connections)
Knowing there's a design where the node can be fully compromised and still only get to ask "will you sign this?" is a good reason to sleep better as a bitcoiner.
Thanks for the AMA, for the answers, and above all, for building ⚡🔨
You're welcome. You can always choose how you deploy the software. For instance, even if you are constrained and can only use a single device for both the node software and VLS, you can also use any Unixlike OS and have separate users for the node software and VLS. Then even if the attacker can shellcode your node software, it still cannot access the VLS userspace, as it is a different user. Of course, if the node software is rootkitted, it can now access everything, which is why we still recommend separate devices, but it is still a (smaller) security improvement to have VLS on the same machine but under a separate user.
Exactly. The policy lives on the signer side, and the whole point is to make the signer a separate trust boundary from the node.
The node should only be able to send signing requests over a narrow interface. It shouldn’t have access to the signer’s filesystem, memory, keys, or policy configuration.
How strong that separation is depends on the deployment. If the signer runs on the same machine, isolation is weaker. If it runs on a separate device, HSM, secure enclave, Nitro Enclave, etc., the node can be fully compromised and still only get to ask, “will you sign this?” We recommend the signer running on a separate device.
Policy changes can also be made to require direct or separately authenticated access to the signer, rather than letting the node rewrite its own rules.
Big thanks
So, if I understand it right, VLS is like a notary that reads the contract before signing it. Where do those rules come from?
In addition to what @jackronaldi said, for the policy side, VLS ships with defaults, and the signer enforces whatever limits you set, so tightening them for your use case.
deleted by author
Agreed! I would go further and suggest that the signer machine should be domiciled in your home/office/citadel/bunker/spacestation. In general, securing your own devices physically is something ordinary human beings can reason about more easily, than securing things in a remote server (even if you already trust the remote rack operator).
Regardless, even separating it out into an AWS Nitro enclave while running the node software in the hosting ECS instance would still improve your security in practice, as it at least makes it somewhat harder to exfiltrate your keys for anyone not named "Amazon".
The thing you have to balance here is that obviously if you are running the signer in your home Internet connection then the latency from your home Internet connection to the node machine is added on to every signing event. That is why we also have alternate deployments like running on an STM32 that is connected to the USB port of the node machine, which reduces that latency, and the new proof-of-concept work done by Vatsal to run it in AWS Nitro.
The key distinction is that hardware protects the key, while VLS also protects what the key is allowed to sign.
VLS also moves that security-critical logic off the Lightning node. A node has a large attack surface: it connects to peers, processes gossip and payments, manages channels, talks to Bitcoin, exposes APIs, may run plugins, and has many dependencies. A VLS signer does much less: track the state it needs, validate requests against Lightning rules and your policies, and sign.
That smaller component can run on a separate, hardened device or environment such as an HSM, secure enclave, microcontroller, or Nitro Enclave, with a much narrower connection to the node, including USB/serial or vsock.
VLS can also use tag-team signing: an always-on signer with restrictive policies can keep the node receiving/routing, while a more protected signer is only connected when you want to send.
So if a hardware signer already independently tracks Lightning state and validates every request, it’s moving toward the same model. But with a signer on the same device as the node, that device is still a single point of failure: compromise it deeply enough to extract or misuse the signing key, and the funds are at risk or already gone.
Longer term, VLS is designed to support multisig/threshold Lightning signing, so no single signer holds enough authority to move funds on its own. Compromising one device would therefore not be enough to steal them.