The Lightning Network has given the ordinary Bitcoiner the ability to send and receive satoshis outside of the base chain, allowing for cheap, near-instant transactions, which makes it ideal for day-to-day payments, but there is a trade-off.
When you anchor funds into a Lightning channel using an on-chain UTXO, you have to commit those funds with a special type of transaction, and you are required to remain online for as long as you require that channel.
The Lightning Network uses a 2-of-2 multi-signature setup to establish a channel with a peer. This means that both parties connecting via a channel need to sign off on a channel’s creation, closure or dispute.
When you create a channel, you use your Lightning node’s wallet to prove that you have the funds and can commit it to the channel. The private keys for Lightning channels remain on the device acting as your node, be that a laptop or a stand-alone node, since the device needs access to the keys to perform these signatures. Keys that are stored on an internet-connected device are known as hotkeys, which means they are accessible to the node’s operating system.
Why the Lightning Network requires hotkeys?
Think of your Lightning node as a special Bitcoin wallet that allows you to pair up with other users and create two-way paths between one another to route payments. Since the Lightning Network requires you to connect with different users to route payments, it is far more interactive than the base chain, and you may need to make changes occasionally.
When a transaction takes place on the Lightning Network, the nodes involved don’t need to broadcast the transaction to the Bitcoin network; however, when you create a channel or channels, you need to prove you have the funds and create that channel option transaction which requires a private key signature.
Second, having hotkeys allow for more flexibility. When you can quickly sign transactions on the fly, nodes can open and close channels more easily and react when there are disputes or if another party goes down, rendering a channel zombified.
A Lightning node is not very different from having a hot wallet on your laptop or mobile device, it is still a Bitcoin wallet with a set of keys that command funds, and it is connected to the internet. And like a hot wallet, there are also some security risks.
If a node’s operator were to have faulty software or a compromised network connection, their keys could be exposed to the world or those trying to attack Lightning nodes, and it could result in that node runner losing access to the funds in the channels that they thought they controlled.
To mitigate these risks, node operators should take steps to secure their computers and their hotkeys by using a dedicated device and taking care of the software they use to run a node. Node runners should use strong passwords and two-factor authentication.
Another option would be to limit the amount of funds their node holds, but this also has drawbacks on deploying liquidity to Lightning and your potential to earn fees.
So if we’re stuck with hotkeys for our Lightning nodes, do we always have to run the risk of getting pwned, or can we add additional layers of security? Well, the Validating Lightning Signer (VLS) project is offering up some interesting ideas to tackle this issue.
What Is The Validating Lightning Signer?
The Validating Lightning Signer separates your Lightning private keys and security rule validation from your Lightning node into a discrete signing device and creates a bridge between your node and where your key is stored, this improves Lightning security for users by reducing the attack surface. The VLS is an open-source Rust library and reference implementation and aims to close the gap in securing the Lightning ecosystem for the average node runner.
VLS provides a new approach to Lightning Network security by sequestering private keys and secrets in hardened policy signing devices along with a set of validation rules. By incorporating UTXO Set Oracles to provide proofs of unspent UTXOs, VLS offers additional protection even in the case of a complete compromise of the node software.
This enhances security compared to existing blind signing nodes by validating that requests from the node are following the Lightning security model. You can sleep soundly, knowing a compromised LN node does not mean loss of funds.
As the Lightning network implementations of Taproot, Musig2 and FROST mature in the coming months, VLS will be a necessity in creating seamless multi-sig Lightning network channels. VLS also allows multi-signature Lightning network setups, similar to Bitcoin layer one multi-signature wallets we have today.
How does the Validating Lightning Signer work?
When run with VLS, the Lightning node uses an alternate signing module, replacing internal signing with proxy calls to the signing device.
The signing device applies a complete set of validation rules to ensure that the proposed transaction is safe to sign. Having a complete set of validation rules protects the funds even in the case of a complete compromise of the node software.
This requires some overlap in logic between the node software and the signer.
The Remote Signer consists of two processing entities:
- The Front End has reasonable resources and is connected to the network.
- The Secure Area may have limited resources and is hardened against physical attacks.
Validation of a signing operation may require proof that UTXOs are currently unspent. Requests are made to a (set) of UTXO Set Oracles, which provide proofs of inclusion and non-spend.
Node and channel state can be stored in the cloud using LSS or VSS).
A design requirement is that an exploit which compromises any part of the Node (e.g. the Front End) but not the signing device cannot violate validation rules.
Possible signing configurations
Here are some of the potential configurations of a Lightning node:
- Monolithic node.
- Node with a separate Blind Signer.
- Node with a separate Validating Signer – the signer ensures that the Lightning state machine runs correctly and funds are not at risk.
Adding validation rules to your node
Some of the validation rules that a validated Signer can implement include:
- Don’t sign a revoked commitment transaction.
- Don’t revoke a signed commitment transaction.
- Don’t close a channel to an unapproved destination.
- Routed payments must have at least as much input as output value.
- Payments must claim at least as much from the input as was claimed from us on the output.
- And many more, as there are more than 50 validation rules a node runner can set up.
What is available in the beta release?
The VLS beta offers a set of features designed to secure against a malicious node:
- Encrypted cloud state backup
- Works with CLN and LDK nodes
- Disaster recovery from signer and node failure
- Complete set of layer-2 validation rules
- Optional validation rules (e.g. velocity, approval)
- A complete set of layer-1 validation rules (on-chain channel state tracking)
- Heartbeat generation
- Allowlist for approved destinations
- UTXO set oracle guarantees safe on-chain state
Do your own research.
If you want to learn more about VLS on Bitcoin, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research, check out their official resources below or review other articles and videos tackling the topic.
Are you a Bitcoin and Lightning fan?
Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Do you run a Lightning node? Have you tried all the forms of Lightning payments? Which one do you prefer?
Let us know in the comments down below.
