Lightning channel backups also known as static channel backups are backup files that only need to be updated when an LN node opens or closes a new channel. These backup files are a failsafe to record the state of a Lightning channel in case of data loss. They allow the Lightning node user the opportunity to attempt to get the latest channel state from the various remote peer peers they had connections with prior to the shutdown of the Lightning node.
Static channel backups allows a node that has potentially lost some of its state to encourage its peer to initiate a channel close. Since the peer should still have the most recent state, it can close the channel using that state and allow both nodes to receive their most recent balances.
Once balances have been squared successfully, you would broadcast a new transaction and once confirmed you now have your on-chain bitcoin available to rebuild your channels.
Why are Lightning channel backups important?
The Static Channels Backup (SCB) is a feature that allows for the on-chain recovery of lightning channel balances in the case of a bricked node. The name of the feature tends to lead to some confusion as to how the backups work and the limitations. The channel back up does not allow the recovery of your LN channels so having it won’t mean you can boot up your node again and have all those previous peer connections set up and flowing.
All an SCB offers you is an increased chance that you’ll recover all (or most) of your off-chain (local) balances.
The SCB contains all the necessary channel information used for the recovery process called Data Loss Protection (DLP). It is a safe backup mechanism with no risk of provoking penalty transactions that could lead to losing channel balances.
What information does a channel back up hold?
The SCB contains all necessary peer and channel information, allowing the Lightning node to send a request to force-close the channel on their end to all your previous online peers. Without this method, you would need to contact your peers manually or wait for them to force-close on their own eventually.
This SCB-based recovery method has several consequences worth bearing in mind:
- This method relies on the goodwill of the peer: Since a malicious peer could refuse to force close the channel, and the funds would remain locked up.
- Recovery only works with online peers: A node cannot send a request to force close the channel if a peer is offline. Therefore, the funds in that channel will remain locked up until this peer comes back online, or possibly forever if that peer doesn’t come back.
- The backup needs to be up-to-date: Since LND needs to know about your peers and channels, the SCB needs to be updated every time you open a new channel.
You need to set up an automated SCB update mechanism that:
- Creates or updates your SCB file each time you open a channel (or close one, although this is less important)
- Stores the SCB file in a different backup location to ensure it is available in case of a failing SSD.
The goal of static channel back ups
The goal of the static channel backup is to provide a recovery method of last resort. It contains a subset of the data in the DB for each channel that was active at the time the file was generated. This subset is sufficient for a recovering node to reach out to the peer, despite having lost all the DB data, and ask it nicely to close the channel, and then grab the funds from on-chain.
It is not really a backup because:
- Channels have to be closed in case of a recovery, there is no way you can continue using the channels. Real backups in LN-penalty have to be real-time backups, such as the backup.py plugin, which however has a whole slew of issues (backup not reachable? your node can’t proceed)
- You are relying on the peer to be collaborative and close the channel when you ask it to and not to cheat. It could very well just replay an old state in which they had the majority of funds and you wouldn’t be able to retaliate (remember: you lost your DB with the penalty transactions).
What a static channel back up does provide is a last resort claim should you be dealing with honest peers who are not willing to burn their reputation to secure satoshis. Should you have peers willing to agree that the back up state is the final state of the channel, you can recover as many funds as possible.
It is not a catch all, in some cases you can recover your finds even if peer might cheat you out of a part of the funds or attempt to blackmail you, with the help of a watchtower and a justice transaction or the threat of one. Because of this risk, peers using the option_data_loss_protect mechanism have an incentive to close the channel honestly with the latest state when they hear from a stale node.
Risks of channel back ups
Despite the ability to create these channel backups, there is no 100% guarantee of the recovery of funds; in certain situations, funds can still be lost, such as:
Advertising weakness
The peer can guess that something is wrong and attempt to steal funds from the stale node by closing the channel using an old state.
Mutual loss
In the worst case scenario where both peers lose state, or if the remote peer becomes permanently unavailable, static channel backups can’t help recover the current channel state nor request that user to honour the saved state and action the close based on that balance.
Sources:
If you want to learn more about Lightning channel back ups and dive down the rabbit hole, we recommend checking out the following resources.
- https://raspibolt.org/guide/lightning/channel-backup.htm
- https://lightning.readthedocs.io/BACKUP.html
- Enable Channel Backups and Fund Recovery on LND
- Backup/Recovery
- LND Node Recovery Options and Planning
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? How do you handle channel rebalancing? Have you tried all the forms of Lightning payments? Which one do you prefer?
Let us know in the comments down below.
