These are my current ideas for the future of ElectrumSV wallet restoration, written up to get them solidified. Often many of the things we plan are far in the future and it’s good to map out nuances of how we think they will happen so that when we get there we won’t forget some useful idea.
As always, please correct me if you find something wrong in my assumptions or knowledge. Comments welcome below, or in the #electrumsv channel on either of the excellent Unwriter or Metanet ICU slacks.
Our plans for ElectrumSV include making your wallet a private collection of all your information. This means that it will evolve towards an account-based model where you can group both data and coins in a hierarchical manner, and this includes coins and keys that are not derived from your wallet’s master private key.
Within this you might have delegated keys from your employer, where you have access to work funds. You might have a stream of keys mapped to a collection of documents that are encrypted on-chain. You might have your Paymail account, upgraded with enhanced functionality depending on what extensions your Paymail host supports. And so on..
The Paymail milestone
In my notes on further wallet refactoring, I alluded to a longer term plan of restoration being linked to on-chain metadata. But for Paymail, we need to limit the scope of the work, in order to ensure that we can get it out in the short term.
This lays down the foundation for ElectrumSV wallet structure. All future ElectrumSV wallets are going to be standard Electrum wallets (non-BIP39) that will be explicitly multi-account. Simplifying it somewhat, these will both be containers for accounts derived via BIP32 from the multi-account parent wallet, and beyond this milestone also for accounts derived from external keys.
Electrum wallets are not BIP44 wallets (BIP44 defines a shitcoin-compatible derivation path template for wallet restoration). They are not BIP39 wallets (BIP39 defines a standard for mapping mnemonics to private keys). I don’t think that any other wallet supports importing and restoring our mnemonics, and I don’t think that is a concern to us if they do moving forward with this.
It starts with the mnemonic, or seed words. What we want to prevent is user error, and avoid the problem of users restoring old style mnemonics as multi-wallet mnemonics. This exposes them to a future wallet, where because in the past they gave out an xpub for the legacy Electrum single-account wallet, that has privacy concerns. We should be able to do this by bumping the Electrum seed version, and in this way going forward Electrum multi-account seeds will distinguishable from legacy single-account seeds.
We are starting with a reduced scope of only accounts using keys derived from the parent wallet, which ensures that no metadata is needed for the restoration, and that it can be done by enumerating possibilities. Much like how the current naive legacy single-account BIP39 and Electrum wallets are restored. The primary difference is that we not only enumerate accounts as we do now, but we wrap this in a higher level enumeration that finds used accounts.
BIP44 has accounts in it’s scope, but it is clumsy to just adopt BIP44 for our parent wallet. Better to just go with our own top-level BIP32 scheme, and the most likely candidate at the moment is “m/<type>’”. If type is 0, then the path extends to “m/0’/<account>”. And type represents what kind of entity is contained under it, and when that kind is accounts, the children of that are the used accounts.
This is enough to move forward and get us the base to work from. Is this the right scheme for future ElectrumSV wallet state going forward? Do we need to account for more in the path structure? It’s not possible to say at this stage, but I think it’s fairly safe.
Beyond the Paymail milestone
On-chain wallet restoration metadata is our future. Once we get that implemented the future is bright.
ElectrumSV uses it’s own approach, it doesn’t use BIP39, it doesn’t use BIP44, or even the arbitrary BIP32 paths other non-BIP44 wallets use. Other wallets do not need to support us, but what we need to do is support them.
There was some discussion at the wallet workshop about wallet restoration going forward, and when I asked who else supports restoring wallets, Tokenized made it clear that they consider this very important.
I don’t really think other wallets need to take us into account. Not unless they plan to migrate to something similar to our standards, and want to work with us to ensure they are encompassing enough to support their later use.
I am also not that concerned about whatever they choose to do. If they specify how their wallets work, and it’s based on BIP32 — or even if it’s not, it does not matter. I expect that the way I plan to do wallet restoration can support it naturally.
Wallet restoration metadata
ElectrumSV doesn’t need to settle on how we do our on-chain wallet restoration metadata at this time. This is just going to be a list of concepts, but I’ll try and extrapolate each so that you can see some of the thoughts behind them.
We might define our BIP32 path to have type 1 (“m/1'/…”), where this is top-level wallet restoration metadata. Under one child (“m/1'/0'”) this might enumerate addresses which encapsulate atomic pieces of metadata. Under another child (“m/1'/1'”) this might checkpoint state, so that all the atomic pieces up to that point do not need to be enumerated and applied.
As we envision your multi-account wallet from grouping not only accounts linked to it by derivation, but also external data, including accounts based on imported keys, this means that restoration is no longer tied to enumeration of BIP32 hierarchies and addresses within them. Now we need to dynamically pick out data from on-chain and jump off to restore from that.
This is fine, as long as we have on-chain metadata, this is just a natural extension of wallet restoration.
Restoration and procedural grafting onto BIP32
All current wallet restoration is naive exploration of receiving and change addresses under the BIP32 key-space defined by the extended key that your wallet is based on. You start with a mnemonic, and maybe enter a derivation path, if you can search the web and try out a few ambiguous guesses some internet randoms have made. But beyond that the wallet just explores the address space, and hopes the original wallet didn’t do it badly.
What I envision for ElectrumSV is for the metadata to build on this as a primitive operation. We can do that naive exploration for our wallet restoration metadata, and maybe even for the use of our derived accounts at least initially before we get on-chain wallet metadata, but it goes beyond that.
Every key-space is a projection from either a master private key, or an imported key of some sort. Some of these projections may be based on BIP32, and some may be based on whitepaper 42, and others further still on refined techniques like token chains. This includes all the derived accounts in the new multi-account ElectrumSV wallets, which can be mapped in via a BIP32 projection.
In the longer term what we may very well do is no longer even enumerate our own accounts, but define a metadata operation that maps them in as the restoration metadata is processed. So then the only BIP32 enumeration we might do, is to locate and apply the restoration metadata. We can grandfather that restoration metadata in easily enough, as the first metadata we burn to the chain for a user’s wallet.
What I plan to do here is inspired by what is discussed in this article.
At this point I feel fairly confident about where we are heading both in the short term and long term. The path forward is both clean and flexible. We have a solid short term goal which transitions cleanly into the longer term goal when we add the on-chain data.
BIP44 is dead, except when we need to support externally imported mnemonics/keys and project them into your multi-account ElectrumSV wallet. We should be able to define metadata operations to cover almost anything and restore/project them into our wallet.
One thing about the wallet workshops is that almost all of the other attendees are businesses, and the discussion and results are often business oriented. Paymail is an example of this, if you do not have a secured and trustable hosted server, then it doesn’t naturally fit you. Businesses do, and we don’t. If their wallet restoration needs conflict with ours, we don’t need to use it, we just need to support it. We can define a metadata operator that types their data and projects it into our wallet as accounts or whatever it may be.