Lightning 101 For Exchanges: Security Part 2 — Backing Up Your Lightning Wallet

This is the fifth post in our “Lightning 101 for Exchanges” blog series. In this blog post we are going to talk about how the various Lightning implementations handle their revoked commitment transactions and the backup features they offer to protect user’s funds.

Lightning for Exchanges Series

Our last security blog post talked about commitment transactions and their previous states. In summary, it is imperative that you know what the latest state is on a commitment transaction. If you do not know what the latest state is, you can lose the entire balance of the channel.

Eclair

Eclair’s intended purpose as a Lightning implementation is running on mobile devices. Acinq (the team behind Eclair) released a blog post in the fall of 2018 indicating they now support backups with Google Drive. They first encrypt the updated channel information with a key derived from Eclair’s mnemonic seed and then send that encrypted information over to Google’s servers.

Eclair mobile backups all relevant channel information needed to be able to be able to redeem your funds from a malicious peer. We go into detail of what this information is below. This means you can safely restore all of your funds on the eclair mobile wallet, without having to trust your Lightning peers.

The server side implementation of Eclair does not support channel backups.

C-lightning

C-lightning is intended to be a conservative server side implementation of Lightning. There is infrastructure level work being done currently to support backups in c-lightning. Recently merged is a pull request that allows for a plugin to hook into the processing flow for writing to the c-lightning database.

Rusty Russell believes this is the most effective way to do backups:

“The Right Way is to have a plugin with hooks at the db level, so you back up before c-lightning continues. That plugin could back up anywhere”

Now users of c-lightning can integrate whatever backup mechanism they would like with c-lightning, such as using Google Drive similar to Eclair. This does cause the potential of incompatibilities between different plugins written for c-lightning, but does give developers freedom in implementing different backup schemes.

It is important to note that these database hooks were recently merged into c-lightning and no one has actually built a backup plugin that uses this functionality. In theory this works great, but as of the writing of this blog post, a solution has not been built yet.

There are a couple of “gotchas” with plugin implementations. The first thing to consider is bad plugin implementations that are malicious or buggy. This can cause loss of funds due to the sensitive nature of the data being relayed to the backups. Plugin developers are likely to vary in quality and it is important that robust testing is done to make sure this backup functionality is correct.

Another downside of the plugin scheme is latency added when committing to the backup. The backup plugin must be synchronous to ensure the safety of user’s funds. As we illustrate below, that means there will be multiple backups that happen during a payment to another user. If this backup involves network calls, this can severely slow down routing on the network. This is a problem for any implementation that incorporates a synchronous backup scheme, not just c-lightning.

Lnd

Lnd recently merged a new feature called “Static Channel Backups”. The goal of static channel backups is to be a practical solution to the problem of backing up your Lightning funds. It should be noted that it is note a comprehensive solution. Here is an important quote from Roasbeef (Olaoluwa Osuntokun, CTO of Lightning Labs)

“Once this PR is merged, given their seed and the latest backup file, the user will be able to recover both their on-chain funds, and also funds that are fully settled within their channels. By “fully settled” we mean funds that are in the base commitment outputs, and not HTLCs. We can only restore these funds as right after the channel is created, we have all the data required to make a backup. In contrast, in order to resolve HTLCs, we would also need to update the backup state with each new channel update, which is tricky to do without additional infrastructure. This infrastructure will be built out in the near future, but until then we have this scheme which will also be a fall back in the scenario that any higher level mechanisms fail.”

There is an inherent tradeoff to the SCB scheme. While amounts being transacted are relatively small as of the writing of this blog post, SCB does notprotect funds you have received from a malicious peer. SCB does protect funds if your peer is honest.

Static Channel Backups requires that your peer supports a feature called “option_data_loss_protect” and they are not malicious.

As the name indicates “option_data_loss_protect” is optional, which means if your peer does not support this, you are not able to safely restore your channel. All lightning implementations do support this message in their latest releases.
There is nothing that keeps a malicious peer from lying to you when re-establishing the channel, if you do not have the latest commitment transaction stored correctly, and you broadcast that incorrect commitment transaction you can have your money stolen

It is worth noting that the vast majority of users are losing funds due to corrupted databases, not malicious peers. We believe it is important to distinguish between what can theoretically happen with SCB and what is happening now in practice. In the attack vectors above, existing software needs to be modified to exploit the attack vectors we talk about and you need to have all of your data lost.

Exchanges with millions of dollars at stake should be hesitant to use SCB unless they are peering with people they know on Lightning. When there are more funds at stake on Lightning, we expect more malicious peers to be drawn to Lightning. When bitcoin started increasing significantly in value, we saw more hacking attempts on exchange’s hot wallets. We believe we will see more breach attempts on Lightning from malicious peers as more funds are put on Lightning and liquidity limits are increased. This is why it is important to realize that SCB does not protect you against malicious peers, but only honest peers.

When backups must happen

Lightning is a very interactive protocol, so we are going to take you through step by step of “normal channel operations” when backups need to occur. Our scenario here is Alice paying Bob via Lightning. For more information on the actual peer to peer messages, please refer to BOLT2 normal operations.

In the case of Alice sending money to Bob, Alice needs to backup 4 times, and Bob needs to back up 3 times. Here are the individual steps:

Conclusion

The primary goal of any channel backup scheme should be to protect your funds. In order to fully protect all funds, a backup is required for every time the state of the channel transitions (“revoke_and_ack”). A secondary goal of channel backups can be to enable smooth channel reestablishment. This requires a backup every time updates are committed to (“commitment_signed”). All of the Lightning teams are incrementally making progress on channel backup solutions to accomplish these goals. Only the Eclair mobile wallet supports a trustless channel backup mechanism at the time of this blog post’s writing. We believe we can expect to see a future where every user’s funds, both on-chain and off, are safely within their control at all times.

If you’re interested in chatting more about Lightning Network technology or crypto tech in general, you can find us on Twitter @Suredbits or join ourSuredbits Slack community.

If you are an exchange or interested in what Lightning can do for you and your business, contact us at [email protected].

You can also reach us on the Lightning Network:

038bdb5538a4e415c42f8fb09750729752c1a1800d321f4bb056a9f582569fbf8e@ln.suredbits.com.