LND Backup: How to Create and Restore Your Node

I figured I’d share some info on how to back up your whole Lightning Network state with LND. Seems like LND is the go-to option right now; haven’t really seen much action with c-lightning outside of Blockstream, but correct me if I'm wrong. So, when it comes to backing up LND, there are two main parts you need to focus on the mnemonic phrase and the channel state. The mnemonic phrase part should ring a bell for many of you. It's just the usual 24-word BIP39 phrase. LND calls it an "aezeed" and it helps you restore all your on-chain funds, just keep in mind you’ll need to do a re-scan. Typically, there’s only one phrase generated per LND setup, and it’s created when you first run lncli create. The second thing you should be aware of is the static channel backup. This is a file that holds the state of any channel you have open with another node. According to the LND docs, the channel point is just a UTXO, shown in txid:index format, which represents one of your open channels. So, if you back up both your static channel backup files and your mnemonic phrase, you’ll always be able to access your funds even if your LND node gets wiped out. You just have to set it up again and use the static channel backups to cooperative-close your channels. Just a heads-up that your channel backups need to be current. Don’t forget to back up your channel after you send or receive some sats, or else if you try to close a channel with an outdated state, it could lead to issues.

There are some automated or semi automated tools that will do the channel backups for you. Some are better then others, but I will say look at and play with a bunch of them and make sure you are comfortable with the one you choose. Keep in mind that even things that are just routed through your node even without you making a transaction will make you want to create another channel backup. -Dave

Electrum's implementation prevents this scenario by only allowing "Remote Force Close" if the channel is restored from a static backup. Because it's weird to tell users to backup their channels in every lightning transaction, right? Is there an option in LND to request the remote node to force close in case the backup is not the channel's latest state? If so, it should be safer to do that if the user isn't sure on the backup's state.

I'm actually not sure. And such an option would have to be implemented in its RPC console, so with lncli. The closest you have are these (in lncli): Also, there appears to be no way of viewing the mnemonic phrase (the "aezeed") after the LND wallet is created with lncli create. That is quite weird. Because normally you should be able to type your password and it shows the seed.

Aezeed is not BIP39 compatible. It might use the same wordlist, but that's to my knowledge the only shared part (see https://github.com/lightningnetwork/lnd/tree/master/aezeed, based on AEZ, https://web.cs.ucdavis.edu/~rogaway/aez/). You can try it out (in a safe environment, of course): your 24 Aezeed recovery words won't give you a valid BIP39 checksum. (I was puzzled at first when I checked my carefully documented LND recovery words quite some time ago as I somehow assumed, it's BIP39 compatible, too. I questioned my sanity until I read a bit more about Aezeed and what it means.)

If I recall correctly the aezeed stores some things that BIP39 doesn't have, like for example things required to create things like channel state and stuff.

I don't recall, and there's no hint to it in the README.md on Github, that any details concerning "channel state and stuff" is stored in the Aezeed LND uses. Aezeed has versioning and stores a birthdate with day granularity counted from Genesis block's date. Versioning allows tracking of changes with respect to used cipher and parameters or how exactly to re-derive keys and addresses, birthdate of wallet stores from which day on scanning of blockchain needs to start for that particular wallet. 16 bytes of raw entropy are used. A user can define a passphrase for the CipherSeed and this passphrase can be changed later by the user, which is a quite nice option (changing an optional BIP39 mnemonic passphrase, the additional thing, gives you a totally different wallet). Having a strong passphrase allows the Aezeed recovery words to be kept in plain sight if one wants it. (Of course, you need a safe and redundant backup of your Aezeed passphrase and you shouldn't loose the recovery words. Not going into details of the dos and don'ts...) It may be beneficial to read the short README.md text from the provided Github link above.