Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
How to Backup LN Wallet & Channels? #1156
I have successfully installed Bitcoin & LN testnodes on Linux Ubuntu 16.04 VPS and purchased Starblocks coffee with it.
Now my concern is - We can take backup of wallet.dat file of bitcoin node and successfully take backup of all our bitcoins (test or real).
However, I am not sure about how to take a backup of LN Wallet.
I mean right now I am running it in testmode and LN wallet is generating addresses for me with following command.
I have also funded these addresses with test bitcoins.
Now if my Linux VPS crashes and if I format it and re-install bitcoind -testnet and LN testnet then I can successfully get back my test bitcoins with wallet.dat file backup.
But what about LN Wallet?
Is there any guide or resource for that?
If yes, kindly share it with me.
Cheers... : )
Do not take backups of channel state. Old state is exactly the attack vector for channel theft and you will be punished for using old state by losing all funds on the channel. Backups are actively dangerous in LN. This holds whatever implementation you use.
If you want protection against hardware failure, use a reliable cloud service and layer an encryption filesystem on top. Or use some kind of RAID-1 solution.
Would also like to add: if your system has automatic backups of any kind, make an exception for
To recover from a crash, get your
Obviously old channel state is an attack vector in the way you mentioned it. However the rest of your answer raises 3 concerns in my mind:
1.) Though I am happy you provide some guide on how to recover from an
2.) I looked at the code of wallet.c where many dabase calls about the channel state are being made.
3.) I need to have some form of backup against hardware failure that goes beyond RAID-1. At least I need to back up my revocation keys since they are my lifeline against fraudulent behavior on the channels. As I said I am still pretty new here maybe the third point is useless. But afaik the revocation keys cannot be extracted from
on a bigger scope I would like to emphasize my 2nd point: I guess by now - even though accidents happen - most useres are used and trained to make regular backups. If I (as a user of the lightning network) don't understand the lightning network technology it will be most intuitive for me to actively make backups. I am not sure if we can train the useres to not do backups (e.g. of the sqlite db) So I would strongly suggest to rather encrypt all data that is being written to the disk. In this way people will have more awareness
Not all of them. Most of the state is bookkeeping of how much each side owns, what HTLCs are on offer and so on. For most onchain channel operations, keys are controlled by
That would be nice as a separate issue. Part of the revocation key can be compressed with the "shachain" trick Rusty made, although I do not know the complete math offhand.
In any case when we recovered only the
I doubt it will have that effect. Users are likely to assume that the encrypted data can still be backed up and recovered. Unfortunately backup and recovery will use old channel state and will be dangerous to the user.