You’ve done your homework on Bitcoin and are learning about Lightning or just set up a node. You aren’t sure how it works and are nervous about losing funds
What’s involved in backing up a lightning node?
I’ve been using lightning for years, let me break it down for you 👇
What’s involved in backing up a lightning node?
I’ve been using lightning for years, let me break it down for you 👇
Your Bitcoin is in cold storage. You stamped your mnemonic into a piece of solid steel.
It won’t be destroyed in a flood, fire, or acid bath.
You can finally sleep at night knowing your Bitcoin are safe.
With Bitcoin covered, you are excited to experiment with Lightning.
It won’t be destroyed in a flood, fire, or acid bath.
You can finally sleep at night knowing your Bitcoin are safe.
With Bitcoin covered, you are excited to experiment with Lightning.
You fully expect a similar security model when booting up your lightning node for the first time.
I’ll get a seed phrase and stamp it into another piece of steel.
Unfortunately, it won’t quite be as simple.
What makes lightning more difficult to backup and secure?
I’ll get a seed phrase and stamp it into another piece of steel.
Unfortunately, it won’t quite be as simple.
What makes lightning more difficult to backup and secure?
In Bitcoin things are simpler.
You have your set of UTXOs and a seed phrase that can be used to generate all the keys needed to unlock those UTXOs as well as all the UTXOs you might create in the future.
Everything you need to recover funds can be generated from a single seed.
You have your set of UTXOs and a seed phrase that can be used to generate all the keys needed to unlock those UTXOs as well as all the UTXOs you might create in the future.
Everything you need to recover funds can be generated from a single seed.
In Lightning there is a lot more state that is needed in order to recover your channels and that state is not deterministically generated from some single piece of information.
Each channel consists of the most recent commitment transaction and a set of revocation secrets.
Each channel consists of the most recent commitment transaction and a set of revocation secrets.
While the keys used to create and sign each new commitment transaction can be backed up similarly to your on-chain keys, the latest commitment tx and revocation secrets cannot.
They change every time a payment is made or HTLC is forwarded.
They change every time a payment is made or HTLC is forwarded.
This doesn’t mean all hope is lost.
It just means you need to make a backup every time the channel is updated.
Your wallet or node implementation should handle this for you.
They will backup both pieces of state to your hard drive and ideally encrypted in the cloud as well.
It just means you need to make a backup every time the channel is updated.
Your wallet or node implementation should handle this for you.
They will backup both pieces of state to your hard drive and ideally encrypted in the cloud as well.
With this backup and your keys to sign the commitment tx you will always be able to claim your funds and protect yourself from potential theft by your channel partner.
What about restoring these backups on a different wallet or node implementation?
Not today.
What about restoring these backups on a different wallet or node implementation?
Not today.
Bitcoin has been #blessed by BIP-39 and BIP-32.
These are industry standards that define how to generate a seed from your mnemonic and then an entire set of addresses from your seed.
This means you can import your mnemonic into almost any wallet and recover your funds.
These are industry standards that define how to generate a seed from your mnemonic and then an entire set of addresses from your seed.
This means you can import your mnemonic into almost any wallet and recover your funds.
There is no equivalent standard in the lightning ecosystem.
Each implementation represents this channel state in slightly different ways internally and on disk.
This structure is not defined in any BOLT spec nor is it required to be the same for payment interoperability.
Each implementation represents this channel state in slightly different ways internally and on disk.
This structure is not defined in any BOLT spec nor is it required to be the same for payment interoperability.
All hope is not lost.
At the end of the day all backups must contain the same minimum set of information needed to recover.
In theory a brave engineer could implement software that knows how to read each implementation's backup structure and write it out in any of the formats.
At the end of the day all backups must contain the same minimum set of information needed to recover.
In theory a brave engineer could implement software that knows how to read each implementation's backup structure and write it out in any of the formats.
Such a tool could allow for cross implementation channel recovery.
This tool would likely come with a large maintenance burden as there’s nothing preventing each implementation from continuing to iterate on their internal structures.
Anyone out there working on this?
This tool would likely come with a large maintenance burden as there’s nothing preventing each implementation from continuing to iterate on their internal structures.
Anyone out there working on this?
I hope this helped you understand why backing up and restoring state on lightning is more complicated than it is with on-chain bitcoin.
I hope it didn’t scare you off lightning as nodes and wallets really make it pretty simple to safely backup this state.
I hope it didn’t scare you off lightning as nodes and wallets really make it pretty simple to safely backup this state.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
