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.

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.

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.

  • 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.

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.

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:

ElectrumSV developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store