Part of the allure of the lightning network is the low barrier to entry. Do you have a raspberry pi and some bitcoin? You can run a lightning node. Can you code? You can run a lightning startup.

Most of the lightning companies you’ve heard of today, ours included, started with a few technical people running our own nodes. It was considered ‘reckless’ to use real bitcoin on a node, so we put minimal sats in channels and only founders had access to the nodes. Currently, the largest nodes have over $6M in channel capacity. Businesses need their lightning nodes to be online 24/7, so multiple people usually have access to the nodes in case something goes wrong.

Lightning servers operate in a unique situation where the computer system administrator controls the money. In a standard e-commerce company, Stripe or Square would handle the transactions, finance controls the bank account, and the sys admin would run the servers. Lightning nodes currently require all 3 of these duties to fall on the sys admin. We’ll refer to this as the “triple-hat” problem.

Lightning could technically achieve the goal of running global commerce, but this merging of roles needs to be solved before “real” amounts of money can be run through the network.

When a company moves significant amounts of bitcoin over lightning, the triple-hat model becomes too risky for the business and too stressful for the sys admin. If funds are lost on the node, the sys admins will be under the magnifying glass.

To solve this overlap of duties, it’s helpful to think of a “node” as having three distinct layers.

1. Liquidity: channels to other nodes. “Can I pay?”

2. Logic: routing logic and payment handling. “How do I pay?”

3. Signing: Policies & approval. “Should I pay?”

In a single hat world, the signing layer is separated from the logic and liquidity. The sys admin manages the node logic and liquidity, while the approvals move to a separate device managed by finance. This allows the sys admin to choose any generic hosting provider since the node in the cloud never sees the private keys to sign transactions.

For finance, the device that handles the signing process would ideally require minimal technical support, lacking an operating system and minimal functionality.

Fortunately, Devrandom and Ken Sedgwick recognized this problem early and started the Validated Lightning Signer project (gitlab link). Critically, they recognized that ‘blind signing’ wasn’t good enough and have built support for enforcing policies on the signing device. Their work has been supported by a grant from the team behind LDK, and they’re working with other lightning nodes to implement the VLS.

Lightning Labs has a remote signing mode, but it requires running a pair of nodes, with one node signing for the other. This gets part way to the goal, but running a full node to sign means multiple hats still need to be worn. We’d love to support a bounty to add support for the VLS to LND.

At Sphinx, Evan and Jules have added a broker to the VLS to allow for remote signing over the MQTT protocol. We’re also building prototype boards to fill the need for a dedicated signing device that any finance suit can plug and play. We’ve added a broker that allows a hosted node to send signing requests to multiple redundant remote signing devices. Multi-sig lightning next?

With the remote signing, we’re excited to finally have a pathway where onboarding to lightning can be done with reliable hosted nodes that never have custody of the user’s keys and funds. This could impact any lightning service provider that wants to host the logic, but not ever see the private keys of the end user.

If you’re running a lightning commerce company, email support@stakwork.com and we’ll ship you a prototype signing device. As always, you can order the parts and build your own hardware and run from source (specs).