Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to Backup LN Wallet & Channels? #1156

Open
realcryptominer opened this issue Mar 3, 2018 · 7 comments

Comments

@realcryptominer
Copy link

commented Mar 3, 2018

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.

cli/lightning-cli newaddr

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... : )

@realcryptominer

This comment has been minimized.

Copy link
Author

commented Mar 3, 2018

And yes, what about the channels and funds inside those channels?

Say, I have created 5 channels and funded them with 20000 satoshis each.

So how to take backup of these channels as well?

@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Mar 3, 2018

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.

Saving the hsm_secret is enough to recover onchain funds. You can try waiting for your peers to close the channels unilaterally by simply taking down your node; at some point they will just close channels and your money becomes onchain funds you can recover with the hsm_secret.

@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Mar 5, 2018

Would also like to add: if your system has automatic backups of any kind, make an exception for lightning.sqlite3 file, which contains channel state. Backing up hsm_secret is OK but now anyone who gets your backups could potentially steal any funds you transfer onchain.

To recover from a crash, get your hsm_secret and put it on some VM or new spare computer. Run lightningd with --port=0. DO NOT MAKE CHANNELS WITH ANYONE OR CONNECT WITH ANYONE. Run newaddr a few hundred times, then cleanly shut down lightningd. Then run: sqlite3 $HOME/.lightning/lightningd.sqlite3 "UPDATE vars SET val= 500000 WHERE name='last_processed_block';". Rerun lightningd with --port=0 again. DO NOT MAKE CHANNELS WITH ANYONE OR CONNECT WITH ANYONE. Recover onchain funds to some other onchain wallet you control (with withdraw command all argument). Wait a few hours/days/weeks/months until everyone else closes channels to you, which should make the channel funds into onchain funds you can recover onchain (with withdraw all).

@ZmnSCPxj ZmnSCPxj added the docs label Mar 6, 2018

@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Mar 6, 2018

Added docs label -- the information here should be in some of our documentation somewhere.

@cdecker

This comment has been minimized.

Copy link
Member

commented Mar 6, 2018

Probably a good addition to sphinx-docs?

@renepickhardt

This comment has been minimized.

Copy link
Collaborator

commented Mar 7, 2018

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.

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 hsm_secret I think on the long term the software should provide a more frictionless way to do so (basically and API call that allows to say restore from hsm_secret. The API call would then start the process that you have described).

2.) I looked at the code of wallet.c where many dabase calls about the channel state are being made.
https://github.com/ElementsProject/lightning/blob/aba3d5f34d589805818c9b8dca9a1e40951ece82/wallet/wallet.c As I am still new and don't oversee the complete code yet I might have overlooked something but I also checked db.c I couldn't find any hint that the state of the channels are stored to the database in an encrypted way. As you know modern bitcoin wallets encrypt the wallet files (at least they give the possibility to do so). Wouldn't it make sense to encrypt the entries of the database? Or even exchange the database use something like mmap but encrypt the memory before mapping to the file?

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 hsm_secret. if they can then please ignore my point. on a side node: hsm.c does not have a doc at the beginning explaining what it is. rather there is a comment that nobody will find the struct there.

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

@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Mar 7, 2018

I couldn't find any hint that the state of the channels are stored to the database in an encrypted way. As you know modern bitcoin wallets encrypt the wallet files (at least they give the possibility to do so). Wouldn't it make sense to encrypt the entries of the database?

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 hsm_secret. There is the revocation key, part of which is given by the counterparty to us on revocation (there is some computation I do not know the details of --- @rustyrussell probably knows the computation better --- and thus revocation keys are derived from the revocation provided by the counterparty in addition to our hsm_secret).

At least I need to back up my revocation keys since they are my lifeline against fraudulent behavior on the channels.

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 hsm_secret and the revocation keys, we probably cannot safely continue operating, and can only let the counterparty close unilaterally on their side. We would indeed be able to detect cheating if a revoked tx is used.

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.