## Bitcoin Backups
:::info
Since slack often deletes history and we lose some interesting perspectives here is a record of one such thread.
:::

Daniel Nordh Oct 18th at 4:02 PM
Will an interoperable standard for backups supporting Lightning state ever happen?
I posted a question in the LDK slack, not encouraging:

15 replies

Dan Gould 8 days ago
why is this desirable?

Stephen DeLorme 8 days ago
@Dan Gould With layer 1, one can take a recovery phrase from Wallet Software A and reconstruct the same HD wallet with Wallet Software B. This is seemingly not feasible with LN wallets because each implementation backups their state differently.

Dan Gould 8 days ago
@Stephen DeLorme I'm not sure this is the complete picture. Recovery phrase alone is not sufficient to back up. You also need metadata and each software needs to implement the derivation technique the other used to find the money in the first place. Further, any metadata like labels is lost with recovery words only. I'm still not sure why this is desirable (edited)

Stephen DeLorme 8 days ago
Yes, agreed, saying “recovery phrase” alone is not sufficient. However, with the correct data (such as recovery phrase, derivation path, etc) one could take an existing HD wallet and use it with another piece of software. Layer 1 backups are more interoperable.

Stephen DeLorme 8 days ago
@Daniel Nordh We may need to adjust our mental model of guiding the user through “restoring” a wallet that is LN compatible. To me, it seems clear that LN wallet backups should always be restored in the same application that created the backup.
If a user wants to stop using said LN wallet, then there are two paths out:
Start a new LN wallet, sends all the funds from your existing wallet to the new wallet
Move the funds from the old LN wallet to on-chain address (either through a sub-swap or simply closing all of the channels)

Daniel Nordh 8 days ago
Given that one of our principles in the guide is 'Interoperability', and that it avoids product lock in, I'd say it is very desirable.
And sure, you can always send all your funds to a new wallet, so there are ways around it. But in a world where more people hold funds on Lightning in their wallet, it will also render restoring in general less feasible in another application.
I had certainly operated under the impression that it would one day be possible. If that's wrong, it's good to find out sooner rather than later.
:100:
1
:white_check_mark:
1
:star:
1

Hampus 8 days ago
Will an interoperable standard for backups supporting Lightning state ever happen?
Highly doubt that... sorry.
Even for on-chain, lnd is not using the same seed format as the others (BIP32 vs Aezseed).
:white_check_mark:
1

Hampus 8 days ago
However for wallets using the same lightning node, I'm seeing great success for my Blixt wallet.
I've had a lot of users with broken Umbrel nodes that have been able to recover their funds with Blixt. (edited)
:eyes:
1

Hampus 8 days ago
https://darthcoin.substack.com/p/umbrel-btcln-node-shtf-scenario
Courtesy of Darthcoin. :100:
:fire:
2

Stephen DeLorme 8 days ago
Interesting. So from your perspective @Hampus it is feasible to restore LN state provided that the two LN nodes use the same implementation?

Hampus 8 days ago
@Stephen DeLorme I would say it's definitely possible, given some effort.
Personally I've thinking about how to make this happen with Blixt<->Breez.
But as aforementioned, not seeing cross-node interoperability happening in the foreseeable future. (edited)

Stephen DeLorme 8 days ago
I read through that article, and most methods want the user to use the Umbrel recovery script. I see that Blixt is the only one with a “recover node” option. Pretty cool.

Hampus 8 days ago
Yep as Blixt is literally running vanilla lnd, it's a pretty good and convenient choice, albiet being number 3 in the list (first option is arguably the best if the user got the command line skills for it).

bosch 7 days ago
Start a new LN wallet, sends all the funds from your existing wallet to the new wallet
I think for now this ^ is probably the best option for switching wallets. It's not the best solution but it's also not the worst. It's still probably easier than switching to a new bank with traditional finance.
But yes it would be great if there was some standardized backup that was interoperable between different implementations - it is very desirable from a UX perspective.
:100:
3

Johns Beharry 27 minutes ago
./migrate.sh ldk.json > blixt.json

---

## There has also been mention about how BlueWallet will migrate custodial lightning wallets created with LNDHub to the new LDK

> Hey @Nuno I'm interested to know how Bluewallet will be migrating users funds from LNDHub to the new LDK model?

Johns Beharry 7 days ago
How might we migrate users with funds on lndhub to their new node on device?
How might we use lndhub funds to pay for LSP fees when provisioning a new on device node?

Nuno 6 days ago
Not completly defined yet.

Johns Beharry 6 days ago
@bosch was telling me about a more abstract migration pattern for sweeping funds — as blue wallet is a multi-wallet app (which i absolutely love btw) this could look like “transfers” between them (contacts may also come into play here).
The idea of using the lndhub funds someone might have as a way to pay for opening a channel with bluewallets LSP also came up.

## The saga about backups continue with Christopher Allen of BlockchainCommons doing an assesment of Muun's backup

bosch Today at 3:58 AM
Interesting thread on issues with Muun’s recovery kit: https://twitter.com/christophera/status/1452735401207107584?s=21
Christopher AllenChristopher Allen @ChristopherA
The Lightning Wallet @MuunWallet has failed my #SmartCustody test, and I am unable to recover test funds. Many fragile points: confusing & non-standard recovery process, no mnemonics, logs you out of old device before new device success, too many fragile parts, and more.:-1: …
TwitterTwitter | Yesterday at 10:34 PM
8 replies

bosch 5 hours ago
Def something to consider with the backups page @Stephen DeLorme

bosch 4 hours ago
Breez and Phoenix I found recovery to be very seamless, going to test out Muun today and report back

Andy R. 4 hours ago
Thanks @bosch - I use Muun for some small amounts but have never tested the recovery (I know, I know). I might move my sats considering the above.

bosch 4 hours ago
Muun's a great wallet don't get me wrong, but I agree with the premise of having a very unique backup method can have lots of edge cases. Also makes things much less interoperable

bosch 4 hours ago
Phoenix is my fav :heart:
:pray:
1

Christoph Ono 1 hour ago
We could do a review session on recovery processes of the wallets we’ve reviewed so far?
:100:
1

Christoph Ono 1 hour ago
See the reply by @Nuno. https://twitter.com/nvcoelho/status/1452737459742248960?s=20
NunoNuno @nvcoelho
@ChristopherA @MuunWallet I think the most impressive part is that you were just trying to recover a 2of2 multisig. There’s no lightning involved… :sweat_smile:
TwitterTwitter | Yesterday at 10:42 PM

Christoph Ono 1 hour ago
If Allen was expecting a single-key Lightning backup process, then naturally his expectations do not match with how 2-of-2 multi-key backup works. Is it then maybe helpful if Muun provides slightly more insight into what is happening behind the scenes, so experienced users can adjust their expectations? (edited)

## Mega Thread by Stephen

Hey everyone, I have been working on the Onboarding > Backing up a recovery phrase section and it’s subordinate chapters for LN :zap:️ content. Here is a rough in-progress document. This is really 3 pages, just presented in one document. https://docs.google.com/document/d/1y19VskiZcm6AXO1fVECr2ze_xTehyz4GtGs4zzheKLU/edit?usp=sharing
I really needed to clarify my thinking around backing up Lightning wallets and what is needed in order to restore them, so I did a lot of research and thinking around what data is required and how that data would be used in a restore scenario. @Daniel Nordh this may be relevant to your interests.
Here is a FigJam where I outline different backup and recovery scenarios: https://www.figma.com/file/9BYQVePTMMDSRwsUKxnCAn/Bitcoin-and-Lightning-Backup-and-Restore-Flows
And here is a video where I discuss my thoughts about, for those who are super curious or would rather listen for 10 minutes than read.
https://vimeo.com/637098615/55c5b2aaa2
FigmaFigma
Bitcoin and Lightning - Backup and Restore Flows
Created with FigJam (22 kB)
https://www.figma.com/file/9BYQVePTMMDSRwsUKxnCAn/Bitcoin-and-Lightning-Backup-and-Restore-Flows

VimeoVimeo | Stephen DeLorme
Backing up Lightning wallets - design thinking

:raised_hands::raised_hands::skin-tone-6:
3
:100:
3
:fire:
3
:pray::pray::skin-tone-6:
3

29 replies

Pavlenex 6 days ago
Nice work. LGTM.

Pavlenex 6 days ago
I still cannot believe how LN implementations managed to fuck up the backup part. Incredible overlook.

Pavlenex 6 days ago
I guess backup may include channel closing, retriving funds to the on-chain wallet and then retriving the on-chain wallet?

Daniel Nordh 6 days ago
It was only when I asked the question the the LDK slack that I realized that there most likely never will be a standard, and everyone seems … fine with it?

Pavlenex 6 days ago
I really cannot see how this can be fine, was shocked how okay everyone seem to be.

Pavlenex 6 days ago
I guess we can look at it from two perspectives: (As Roy from breez mentioned)
Depenency Can you restore the client w/o the vendor (backup data doesn’t reside on vendor servers)?
Interoperability: the ability to restore in a different application using same lightning network implementation.
Cross-compatibility (or sth) - the ability to restore in an application using different LN implementation (LND to c-lightning, LND to LDK, etc
(edited)

Pavlenex 6 days ago
The first two seem possible, but how may a user know about implementations, I guess it’s up to vendors to provide this info?

Pavlenex 6 days ago
@Roy maybe you have some thoughts/insights on ^

Roy 6 days ago
@Pavlenex I think you're right. It's up to the vendors to document the restore process. Btw, I don't think "everyone is fine" with not having a standard. It's just that every implementation saves the information differently, and not sure having a standard is the right solution (because every implementation/vendor has different capabilities, needs, requirements etc). More likely that in time there will be conversation/export tools to enable greater interoperability (similarly to the way you switch from one db implementation to another). (edited)
:pray:
1
:+1:
1

Roy 6 days ago
Just FYI, in Breez we didn't want to create a dependency on the Breez node, so we offer backup to the cloud (currently Google Drive, iCloud, Nextcloud or any WebDav server). Although we're using lnd, we decided not to use SCB, but save a pruned version of the app databases. These are exportable via the developers scree and users can use any lnd node to restore the channels state.

Roy 6 days ago
SCB is really not an option from a UX standpoint.
:100:
1

Stephen DeLorme 6 days ago
Glad to see this well received. I began to feel like the meme of Charlie from Always Sunny with the board full of red string as I was assembling this.

Stephen DeLorme 6 days ago
I will put together a PR tomorrow and we can discuss this topic even further.

Stephen DeLorme 6 days ago
In the absence of an interoperable standard, it seems to me that the best thing that wallet developers can do is just illustrate how the user should remove their funds from the wallet if they choose to stop using that wallet. E.g. “you could send your funds to another LN wallet like so…“, “you can send your funds to a bitcoin address like so…“, etc.

bosch 5 days ago
Is SCB not an option because it closes channels when used? Compared to the pruned DB Breez uses which I presume does not? @Roy

bosch 5 days ago
A feature LN wallets could have is an option in the settings called 'Switch wallets' which would:
Sweep all the users funds to a new wallet, preferably an LSP enabled one that auto-creates a channel so the payment can be received easily.
Mutually closes the channels with the current wallet as to not lock up the wallet devs funds indefinitely.
(edited)
:+1:
1

Roy 5 days ago
@bosch yes

bosch 5 days ago
Something to consider on this page is also that recovery phrases differ from LN implementation. LND uses AEZEED, Eclair uses BIP39, c-lightning uses Bitcoin core's backup method (no phrase at all). https://coldbit.com/what-types-of-mnemonic-seeds-are-used-in-bitcoin/ (edited)
:+1:
1

Daniel Nordh 5 days ago
@Stephen DeLorme I think you mean this / also include this when you say wallet developers should say ‘how to remove funds’, but just to make sure: can a user recover the funds WITHOUT using the application? (developer stops maintaining, no longer possible / willing to install it etc.)

Christoph Ono 5 days ago
Although Muun is on-chain only, I think they cover it very well with their emergency kit. There’s a “Muun” folder in my iCloud with a file called “Muun - Emergency kit.pdf”. It includes a simple step-by-step process using their recovery tool on Github, as well as advanced information (output descriptors). While other wallets state that they back things up on iCloud, I can’t actually access that information and work with it. Even if the individual backup formats differ for Lightning per wallet, I think it would be fantastic if the backup process was as clear and transparent as the one Muun has. That could cover issues with varying standards as users only need to follow simple instructions they know where to find.

Christoph Ono 5 days ago
The cost of sweeping should also be considered, it may be problematic for a lot of people to close and open lots of new channels.

Christoph Ono 5 days ago
Also, do LSPs always want channels with users who switch away from their apps? Are there benefits or disadvantages for them/users? Let’s say I start a wallet with an LSP, and it takes the role of advertising routes to my node. If I switch to another wallet that allows me to open channels manually, does this cause problems with routing?

Christoph Ono 5 days ago
Also, great video, thanks for sharing your thoughts.

Stephen DeLorme 5 days ago
can a user recover the funds WITHOUT using the application? (developer stops maintaining, no longer possible / willing to install it etc.)
@Daniel Nordh My current understanding is no: users can only recover funds on LN using the same wallet. That’s why I think it is very important for developers to build in a clear exit path for their application.
(There are definitely very technical ways to get around this, but nothing easy and user-friendly at the moment).

Stephen DeLorme 5 days ago
While Muun is primarily an on-chain wallet and not the same as a true LN wallet, I love their method of having a stand-alone recovery tool. I think it just builds confidence that they provide a clear way to get your money out of your Muun wallet. It would be cool to see more of those, especially in the Lightning space.

Stephen DeLorme 5 days ago
@bosch I personally don’t care for SCB because I see it as a security risk. I believe SCB is backup from when the channel was opened. It’s basically asking your channel partner to force close on you. If you are lacking your own channel state data, then I worry the channel partner could close with a prior commitment TX without fear of punishment.
Caveat as usual: I’m not a LN dev, so I’m open to being corrected on that.

Stephen DeLorme 5 days ago
@bosch Agreed, I’m concerned about the different recovery phrases. That’s why I want to promote including the derivation path and fingerprint in the backup. Perhaps it’s also helpful to include the “type” e.g. BIP39, AEZEED, etc.
Overall, I want to move away from this concept of saving a “recovery phrase” and focus on saving a “backup kit”, because it really needs as much information as possible to truly help preserve funds.

bosch 4 days ago
Yeah I agree, SCB seems like a bad solution. Force closing is inherently a bad practice / costly as well if we are factoring in scaling it make's Bitcoin much less scalable if everytime someone recovers a wallet they need to close and re-open channels. The wallet the backup was made with is also quite important, especially in the context of LN of which recovery seems to only be viable within the same wallet currently.

Pavlenex 4 days ago
This screenshot by Bosch is good example on how we may want to communicate things when it comes to backups. It’s quite relevant to the discussion here, so sharing how it works in the wild that may help us how we thing about things and maybe we can come up with concrete solution here?
Screenshot 2021-10-22 at 13.10.44.png