Mitigating the Risk of Running Lightning Network Hubs

In a previous article, Lightning Network: Don’t Buy Into the FUD, I’ve mentioned the concept of a hub (or a routing node) that facilitates the connectivity of a large number of individuals in Lightning Network.

During an interesting discussion I had the other day, a smart gentleman raised an argument against the hub concept saying “since a hub has to be always online and requires a private key in order to perform LN transactions, there’s a huge risk in operating it.”. This is an interesting argument, and one that has to be addressed if we want Lightning Network to succeed.

First, let me say that an online wallet that holds private key, or a “hot” wallet, is mandatory to perform bitcoin transactions. If the role of Lightning Network is to dramatically increase the number of bitcoins transactions, that inherently infers a larger use of “hot” wallets, and therefore, a larger risk. So, in LN, the money in its channels is indeed “hot”, but by its very nature (performing bitcoin transactions) it has to be.

Now, let’s explain the use of a “hot” wallet in LN and drill down to the need of using a private key to perform LN transactions. Consider the following routing node:

As you can see in the illustration above, there are two types of private keys:

1. LN wallet private key: used for performing a channel funding transaction when a new channel is created.
2. Channel private key: a different private key for each channel connected to a user node. This key is used when sending money to a user.

The use of a channel private key is limited to Lightning Network and to the context of a specific channel. Meaning, it can’t be used to perform on-chain transactions. Even if someone steals this private key, the only possible exploit is to send money to the user at the end of the channel. There’s no much value there, is it? Moreover, considering the relatively low limits of an LN channel (0.16777215 BTC) and a single LN transaction (0.04294967 BTC), it not very lucrative for people to perform attacks on LN channels. With the private key of the channel, it is also possible to close the channel and perform an on-chain transaction to a specific bitcoin address. However, this action requires the channel’s time-lock to expire first, which makes is very difficult to exploit. A simple watchtower solution that monitors relevant on-chain transactions would easily detect such transactions that were not initiated by the hub.

In fact, the real risk resides in the LN wallet used to fund new channels. There are few ways to mitigate this risk:

• Using a “cold” wallet: there’s no technical requirement that mandates the use of a “hot” wallet in a hub… Naturally, if you need to automated channel creation, you’d need to use a “hot” wallet. However, the funds in this “hot” wallet can be limited, and you can put a manual refill process in place. In addition, the business workflow of a high-capacity channel creation often doesn’t require an automated process (typically, there’s a manual vetting process that takes place before opening such channel). Take a look at this recent PR in lnd regarding the use of hardware wallets.
• Using multiple routing nodes/wallets: similar to any type of an online attack, it is always advisable to mitigate the risk by using multiple servers. In the context of LN, a single hub can be comprised of multiple nodes connected to one another. Within a node, you can use multiple wallets to split the money required to automatically fund new channels.

To summarize, if you share my opinion that Lightning Network is the future of Bitcoin, please roll up your sleeves and help the community turn LN to an infrastructure used by all.

If you find this article helpful, please don’t forget to add claps (long press to add multiple claps) and share it.