ElectrumSV 1.3.0a1 — UNSTABLE

Roger Taylor
Oct 12 · 7 min read
Reputedly the best desktop wallet for Bitcoin SV.

This release is not a final release. It is an unstable release made for two reasons. We want our users to be able to try out the wallet and see the direction it is going, benefiting from improvements made. And we also want our users to be able to help us ensure it is as solid as we think it is, before it is released to the public at large.

The next official release for our users will be 1.3.0, and it is part of a milestone primarily oriented at ensuring we have ongoing multi-signature wallet support. The current type of multi-signature wallet we have is based on P2SH, and we will be adding bare multi-signature as an future-proof alternative. And this will lay down the groundwork for including other types of multi-signature wallet, like those presented by Steve Shadders at Coingeek Seoul.

You will note that this release does not yet include any changes to multi-signature wallet types. Ongoing development work on ElectrumSV proceeds in chunks, where a task is completed to a solid and stable level, and then merged into the main development branch. Multi-signature work for now, is kept separately.

Useful links:

How can I use both stable and unstable releases?

ElectrumSV by default will store the wallets and wallet state in your operating systems user directory. But you can run it in portable mode, which forces it to store it’s user state in a sub-folder of the folder you are running the portable ElectrumSV from. By only running the portable version for 1.3.0a1 you can avoid upgrading the wallets in your user directory — but don’t worry, if you did you’d still have the backups in 1.2.x form, but it’s convenient to avoid this if you wish to continue using 1.2.x day to day.

For Windows, ElectrumSV has a standard executable and a portable executable. For this unstable release, you can download the portable one and run that.

Observe the normal executable and the portable executable on our download page.

For other operating systems, you can specify a --portable command-line argument, which will make ElectrumSV run in portable mode. You would run the stable 1.2.4 version without it, and the unstable 1.3.0a1 version with it.

Example use of the “portable” command-line argument used with other arguments.

How do I find out about further releases like this?

Open the preferences window for your current wallet, and uncheck the “Ignore unstable releases” option.

The checkbox to see further unstable releases.

This will feature new unstable releases in the results when you “check for updates.”

What has changed in this release?

As usual, you can read the subtitles to get an overview of the changes. If you want more detail, read between the subtitles. In any case, many of these things have been mentioned in previous articles, so you may already be familiar with them and might be able to skim those parts.

Upgrading wallets to use a database for storage

In the code we inherited, wallets are stored in a text file, specifically they are persisted as JSON. If the user has opted to do so, and we support it for their wallet type, this lump can be encrypted with a password.

A different filename

We do this using sqlite, every wallet is now upgraded from the JSON file which might be stored under the filename of mywallet, to the sqlite database that is stored under the filename of mywallet.sqlite.

Your existing ElectrumSV 1.2.4 wallet would look like this:

1.2.x JSON wallet file (no file extension)

And when you next load it and approve the upgrade, it would look like this:

1.3.x sqlite database-based wallet (sqlite extension)

Upgrades automatically back the wallet file up

When we load a wallet, we notify the user that it needs to be upgraded, and ask them to approve it. One concern you might have, I know I do, is what if something unforeseen goes wrong — but ElectrumSV thinks it succeeded?

You do not need to worry about backing up your wallet before an upgrade. We automatically make backups of your wallet file, with any upgrade in 1.3.x.

Here you can see that my existing wallet with the exciting name of 17_testnet_standard_bip39_encrypted was upgraded, but was first backed up to 17_testnet_standard_bip39_encrypted.backup.1 by ElectrumSV, and the original was deleted after being successfully upgraded to 17_testnet_standard_bip39_encrypted.sqlite.

The backed up 1.2.x JSON wallet file, with the upgraded 1.3.x sqlite database-based wallet.

ElectrumSV will detect the original backup and use a new variation on the backed up file name, if for some reason you try to upgrade the original file multiple times.

Multiple sources of payment destinations

First, let’s touch on what a payment destination is. Then we’ll devote a small amount of attention to the reason you might want more than one in your wallet, and highlight how the wallet experience changes.

What is a payment destination?

The addresses you use, whether you give them to people directly, or whether you give someone a QR code where the address is in the URL along with other payment details, are payment destinations. They are called “public key hashes”, and are included in transactions in a standard script template that is called “pay to public key hash”. Every payment to your address is highly likely to be made by the exact same script, but in different outputs within different transactions. Every payment to a public key hash you have the private key for, is within a transaction output. The amounts in the transaction outputs that you have not spent, are your unspent transaction outputs, another name for which is UTXOs. The address is just a convenient way to map unspent payments to you, using the same form you tell people how to pay you.

But the concept of an address is a stop gap measure. They do not work as a way to represent the full set of payment destinations that Craig Wright designed Bitcoin to allow. I’ll leave it at that, but if you see me refer to payment destinations, know that it includes the kind that addresses currently represent and more.

A use case for handling more then one payment destination source

Paymail is a way for ElectrumSV to delegate the ability to receive payments on your behalf, to a Paymail host. It is in your interest to keep the Paymail payments you receive, separate from the ones you receive from other sources.

Consider that you might have several different identities, each with their own linked Paymail host that can receive payments on your behalf. You might even have multiple hosts for each identity, where different hosts offer different services.

This change gives ElectrumSV a lot more possible ways it can create a useful and flexible wallet experience.

The changing wallet experience

The 1.2.x wallet user interface is based around the single payment destination source. It needs to change to allow users to be able to manage multiple sources.

The 1.2.4 single payment destination source oriented view.

For now this is not an area we are focusing on. The interface will only receive incremental changes forced by the underlying technical changes. At some later point we will rethink the user interface to meet our longer term goals.

Minor changes in 1.3.0a1 to allow separation of payment destination sources.

Final notes

This release should not actually be that unstable. To the best of our knowledge it is pretty stable, and has an extended test suite of older pre-database wallets that should ensure whatever version of ElectrumSV people have, their wallets should upgrade correctly when they finally move to the latest version.

Well, there is that bug in transaction verification. Just close the wallet and reopen it, and they should verify. Probably pretty annoying if you use this release day to day.

It’s not strictly an alpha, as we are not feature complete in any sense. But that’s the way I coded the update system, and there’s no general way to release in-development versions for people to try and test.

Moving forward as large features are merged into our development branch, we will look at doing unstable releases for each of them to give our users a chance to make use of, or just check them out.

What changed before this release?

You can find even more guides to changes in earlier versions from within the following guides: