The lnd lightning client is set to introduce long-awaited static channel backups
The lnd lightning client looks set to roll out a new static channel backup scheme in the next release version, with the required code changes now successfully merged on Github and version 0.6 now in pre-release testing. Lightning users have been patiently waiting for more options for keeping channels safe in the event of a hardware failure over the last year or so, as activity on the lightning network has continued to surge. This latest update from the lnd developers will be a welcome addition to those already running nodes using the Go-based implementation on the network, and should also encourage further users to launch a node and add some channels, now that their funds can be secured both on-chain and whilst contained in off-chain payment channels.
As it currently stands, there are difficulties in recovering funds from open channels in the event of a catastrophic hardware failure, even if the user has their recovery cipher seed. Unlike with on-chain bitcoin HD wallets, where the seed words are all that is required to replicate a wallet, the recovery seed that users are prompted to store for backup with lnd is only able to recover on-chain funds. Any funds that are contained within lightning payment channels require access to the channel database in order to close the channels and return the funds to an on-chain address controlled by the cipher seed keys.
There has been lots of discussion in the Lightning community on different solutions for ensuring a safe backup of the channel data, but many of these require the technical knowledge to set up ongoing backups of the channeldb, using RAID1 disk mirroring for example. These setups ensure that two copies of the channeldb are maintained, with one serving as a redundancy in the event of issues with the primary hard-drive. Whilst this is currently possible for users with the know-how, this still leaves issues to contend with relating to ensuring backups are accurately updated with any changes to channels, to avoid the penalties associated with broadcasting outdated channel state data.
A solution has been in the pipeline since as far back as mid-2017, and has began to take shape since the end of 2018. The lnd developers have built out a solution in the form of static channel backups, and a specific protocol for their usage to ensure they are secure and function correctly. The idea is to allow a user to take a copy of channel data, which can be stored elsewhere, either on separate hardware, or even using cloud storage. Under the new backup scheme, in the event of an issue with the current node a user can simply set up a fresh instance of lnd and safely use the copy of the existing channel data, along with their cipher seed, to recreate their node.
The first quarter of 2019 has seen staggering growth of the Lightning network, with over 1000BTC now committed to payment channels on the novel second layer network. It is incredible to note that these funds have been active on Lightning without concrete backup schemes in place across the three major implementations. The current prevailing wisdom dictates that in the case of an issue with a node, it has to be taken offline, and users wait for channel partners to force close the channels, such that funds are returned to an on-chain address. The problem with this is that some channel partners will take a significant period of time to force-close a channel, and this could leave funds in limbo indefinitely. With static channel backups now just around the corner, users will likely feel a great deal more secure when committing funds to payment channels, and this could perhaps unlock another wave of Lightning experimentation and adoption.