Planning for wallet backups

This article is intended to start movement on how ElectrumSV will do wallet backups. We will need to start fleshing out the design for this, and implementing it in the short term — so if you want to be involved in the discussions you should join the Metanet.ICU slack and it’s #electrumsv channel.

Addressing seed words

Before we can touch on backups, it is necessary to first address the subject of seed words. When seed words were invented, Bitcoin wallets were simpler things. The idea that you could use those seed words to restore the wallet was at that time more or less realistic.

An expectation without an understanding

The problem with seed words comes when the original ability to be able to restore a simplistic wallet with them, evolves into a belief in them as a form of magic where any wallet should be able to restore using them as a kind of magic spell. Some people latch onto this fabulous promise so hard, that when you suggest the magic is a shallow illusion, they get angry.

When magic does not exist but the user believes it does, they get an unpleasant surprise when the shallow illusion is revealed. An example of this is the users who load the same seed words into different wallet applications and use the different applications concurrently. More than one person has loaded their Money Button seed words into ElectrumSV and used them there, and found that Money Button no longer works and they require technical support to fix the problem they created.

If you find yourself asking why the Money Button developers and the ElectrumSV developers don’t work together and make it work, please don’t. It’s just insisting that people make things harder for themselves for no real benefit beyond a futile effort to make it looks like seed words are still magic. Stop it. Think it through, I don’t have to do all your thinking for you. It’s a bad idea for a number of reasons. Do your own thinking and work it out.

Can they be made to work?

Of course. Almost anything can eventually be made to work with enough time and effort by someone. And it’s best if that someone is someone else, whose time and effort can be spent as you desire at no expense to yourself.

The likely path forward for seed words

The work involved is prohibitive. Having to design every part of the wallet to restore from the blockchain in a future proof way, slows down general development. In my opinion this is what is considered a “nice to have” feature, and not a “must have” and we will very likely sideline it. It’s much much easier to add it later, if it even proves worth the effort of doing so.

What is likely, is retaining the benefits of deterministic keys. If key derivation is deterministic then data can be located, stored and signed in a private manner. One example of this is if we pack per-transaction metadata into the actual transaction — this might include any description the user provided for the transaction, the fiat value at time of payment and perhaps even tags as I believe Tokenized currently associate with their transactions.

Different forms of data and backups

Local data

The local data is not a form of backup, but the state the wallet operates from. The knowledge of what coins the wallet has access to, the transactions made and even who they were made to.

It might include these things:

• Any notes the user has attached to a transaction, and perhaps even a history of what past notes the user has replaced.
• Who you paid, and specifically which identity you paid.
• What is being paid for in a transaction, perhaps even recording the fiat value.
• Tags could be associated with the transaction. If removed tags are tracked the user could even search the wallet content that had tags at a given point in time.
• The contacts in your wallet, the past and present identities they have associated with them. It should be possible to map a payment to an identity to a contact, and perhaps even the name you had for that contact at the time.

And it would extend to support more advanced usages as we reach those things. There would likely need to be a access control model for the wallet, where who can use what state is known. This would allow signing authority for various purposes to be delegated to perhaps your phone, and a loose change account also. The nuances of and requirements for this require a separate design.

Cloud stored data

This would be the way that ElectrumSV is backed up. A user specifies some form of cloud storage that meets a limited set of popular APIs, and ElectrumSV synchronises with their account. We’d show UI indications of a need for backups, and actively highlight what was not backed up.

In the shorter term this would be owned by one wallet installation on a given device, but in the longer term as the contents of a wallet are delegated to different devices, there would be some nuance to this.

On-chain data

I currently expect the best use of on-chain data is point of time metadata. So when a user makes a payment, we encrypt relevant metadata into it. What notes they attached to it, and any other data that they wouldn’t want to lose in the case of data loss. This isn’t really useful as a method of backup, as the user can later edit the notes and add or remove tags from the payments and so on. It’s value is directly related to the time around when the payment is made. As time passes this data becomes dated and potentially obsolete, and it’s value as a hedge against data loss reduces.

Final Thoughts

I reiterate:

We will need to start implementing wallet backups in the short term, so if you want to be involved in the discussions you should join the Metanet.ICU slack and it’s #electrumsv channel.

ElectrumSV is already constrained by having no way of doing backups other than the limited seed-based approach. We are going to have to move on this. If you have any stake in the outcome, please get involved.