Backup & Restore VS Export & Import

[holzeis]

Backup & Restore VS Export & Import

Recently we are mixing up backup & restore with export & import functionalities. Let me start by describing my view on these functionalities.

Backup & Restore

Typically an infrastructural topic, where the storage will be simply copied to or from another device / storage. During that process the system will typically not available - neither during backup nor during restore. Creating a backup of a system while running brings some risks as the system and the backup process might interfere with each other. e.g. changing the database while the backup is running may result into a corrupted state.

There are several existing solutions that can simply be used. e.g. Start9 provides such functionality, longhorn on kubernetes, or simple rsync scripts.

Export & Import

In this context I refer to exporting or importing a wallet. This is a common functionality seen in other wallets as well with which you can export / import your keys so you can easily move your wallet from one app to another. As already pointed out in previous discussions and tickets BIP39 is a common standard for supporting that interoperability.

Conclusion / Open for Discussion

1. We should deem the current "backup" functionality merged with Allow exporting seed in taker UI #2988 as wallet export functionality. And the ticket Restore from seed file #2989 as importing a wallet, with the obvious drawback that you can only "move" your wallet within ItchySats.
2. We should eventually switch to BIP39 to make the import / export functionality useful. Otherwise I don't really see a use case (other than testing) for having that feature. that way you will support mostly any wallet -> ItchySats and the other way around.
3. The libp2p Identity should not be bound to the wallet seed. There is no reason that the libp2p identity is bound to the wallet seed. This introduces unnecessary complexities when importing a wallet as the connection to the maker has to be recreated.
4. Relying on the umbrel seed soley for the feature that umbrel will create a backup of that does not stand in relation to the effort it brings to maintain a separate way of managing seeds. I suggest that we harmonize that functionality and deal with the topic of backup and restore separately (as mentioned above - I see that as an infrastructural topic)

Related ideas

• Focusing on a better wallet experience we should extend on the pattern @bonomat introduced of the first login. At a first login we should ask the user to set a password and ask her if she wants to create a new wallet or import an existing one. In case of a new wallet - we will show the generate Mnemonic Code according to BIP39. We don't have to reinvent the wheel here. That would introduce a more reasonable export & import experience.
• Importing a wallet afterwards should always come with a strong warning that open CFD positions will get force closed / or we could ask right away if the user if fine with closing them, as they can't continue anyways.

How should we proceed with #1065 and #2989

Restoring the seed works prototypical - but the following tasks are still outstanding though.

• Splitting the wallet seed from the identity seed in a downwards compatible way.
• Extending the wallet UI with an import wallet seed feature.
• Warning the user upon importing a wallet seed in case there are open CFDs (will be eventually force closed).
• Refactoring the export seed to read directly from the file instead from the rocket state.
• Change naming in itchysats from backup to export, resp. restore to import.
• Disable export / import feature for umbrel users until we get rid of the external app-seed.
• Create automated regression tests

That being said I don't think this feature will have a clear use case without the migration to BIP39. If that's the plan we could continue, given that we don't think that a BIP39 migration will not bring too many changes to the export & import functionality.

Related discussions, tickets and pull requests

• Make it easier to back up the seed-file #1065
• Restore from seed file #2989
• Allow exporting seed in taker UI #2988
• Secure sensitive data with password #897
• Seedphrase based wallet that can easily be backed up #865
• User experience on different deployments #1088

[luckysori]

Thank you for the very thorough description.

Importing a wallet afterwards should always come with a strong warning that open CFD positions will get force closed / or we could ask right away if the user if fine with closing them, as they can't continue anyways.

That should not be the case AFAIK. The wallet is only involved in the lock transaction.

The keys that we use to spend that lock output are part of the Dlc and will remain unchanged in the database when we import a new wallet.

[bonomat]

There is another concern: the existing CETs go to an address from the old wallet. Which means, if you change the wallet and force close you will not be able to access the funds.

If you have open positions, I think the best way is to force a rollover which uses the new wallet's addresses.

[luckysori]

That's a good point: any final, chained transaction will pay to an address of the original wallet.

I would just show a disclaimer explaining that any open CFDs will pay (in the non-collaborative paths) to addresses that belong to the wallet (until a rollover takes place) that they're about to "replace". They can then just come back and load the wallet again if they want to claim those funds.

Forcing a rollover seems tricky because:

• We can't ensure that it actually happens. There's logic that might prevent them from immediately running a rollover and their maker could be unavailable or refusing to cooperate for whatever reason.
• The user might not want a rollover to happen (we charge fees).

But perhaps the simplest, least surprising option would be to just forbid the user from importing a wallet if they have open positions.

[bonomat]

Thanks for this thorough write up.

Here are my two sats on this topic:

Backup vs Export

The initial ticket was about backing up the seed file with a focus only on the wallet seed.
Personally, an export not for backup reasons does not make sense, hence I always referred to them together 🙈
From now, let's only focus on wallet backup or if you prefer, wallet export.

PeerID vs Wallet

I agree, these two things don't necessarily have to be derived from the same seed. We made some attempts in the past which allowed us to pass in a Bip84 xprv as arg for the wallet.

Wallet export

It was probably for simplicity reasons that we went for a seed file and not for Bip39 right away. This is biting us a bit now because we cannot generate a Bip39 seed phrase from our seed file.
Which means, our current wallet can only be backedup (exported) by copying the seedfile somewhere else.

Wallet import

Assuming the wallet and peer id are decoupled it should theoretically be easy to just import a seed file again and replace the wallet. This comes with a few caveats though:

Existing positions

Existing positions have CETs which spend into an address generated by the wallet. These CETs are already final and cannot be changed. However, on every rollover a new set of CETs will be generated. Meaning, we have the option to force a rollover when a (new) wallet seed was imported so that all existing positions will end up in the new wallet.
We can then drain the old wallet to the new wallet.

Note: we need to be careful if there is a transaction currently pending.

Force close

A force close of existing positions is probably not the best idea: Our protocol enforces a timeout of 12 blocks (~2h) between including the commit transaction and publishing a CET. Additionally, if you force close now, your CET will only be valid in 24h. This would make the wallet upgrade a bad experience because the funds will only show up in 24h.

Bip39

It looks like that the de-facto standard is Bip39. Even though, there are attempts to push for a new approach using descriptors. The reason for this is that a seed phrase alone does not tell you how to derive addresses, i.e. which derivation path was used. This can be troublesome if we upgrade to Taproot which uses Bip86 while Segwit uses Bip84.

Long story short, I'm still in favor of using Bip39 😅

---

Proposed approach

My proposal is as following:

For existing users

When importing/creating a new wallet notify the user that the old wallet will be drained and existing positions will be forced rolled over. If this fails, we fail the wallet import/creation.

The way how I imagine this is a simple edit field which generated 24 seed words or allows you to edit it to import an existing seed phrase. We did something like this before in our browser extension and this wasn't too bad.

For new users

We generate a default wallet (using Bip39) but let the user create a new one through the wallet interface which then goes back to the same functionality as above. That way we don't have to provide a different setup scenario for new users vs existing users.

[luckysori]

I'm generally in favour of what you propose. But I would insist on opting for simply disallowing swapping the wallet if there are any open positions, because it just makes things a bit complicated:

• What happens if forcing a rollover fails?
• What happens if the funds end up in an address that belongs to the previous wallet?
• What happens if a revoked CET is confirmed and the funds appear to be lost?

I just don't see much benefit in allowing quickly swapping out wallets, given that the side-effects can be hard to anticipate and impossible to understand for the user. I would be more in favour of eventually supporting "profiles", so that if a user wants to use more than one wallet at the same time we just force it to be in a different data directory.

[holzeis]

But I would insist on opting for simply disallowing swapping the wallet if there are any open positions, because it just makes things a bit complicated:

I agree with that - at least I would not implement it first and wait if there is even a need for that.

[bonomat]

Sounds good to me 👍

[bonomat]

I think we came to a conclusion here. Unless there are any objections, let's roll with this: #3172

[holzeis]

I continued with the issue and finished the import seed feature with the seed file - #3173. This feature is disabled for umbrel users though as 1) the seed is not stored to file and 2) the seed is 32 bytes instead of 256 bytes long. Theoretically we could implement a compatibility, but I don't think the added complexity is worth it.