ElectrumSV 1.3.12

Roger Taylor
6 min readApr 26, 2021

--

This article covers the release of ElectrumSV 1.3.12, and some of the more important changes that have been made since ElectrumSV 1.3.11. Skip to the “What has changed in this release?” section to see what has changed, if that is what you are here for.

We have not been making smaller releases like this. Most of the work is devoted to a larger update that prepares ElectrumSV for many of the exciting things you might see coming in the Bitcoin Association roadmap! However, a couple of the changes in this release are important enough to warrant setting aside the larger updates for now and getting a smaller one out.

Do you need an introduction to how ElectrumSV works?

We have a selected range of guides to common tasks that our users may want to do in our documentation, please check it out.

Where can you download ElectrumSV?

The only safe downloads are available on: electrumsv.io

Where can you get help?

Find our issue tracker here where you can create a ticket. Fill out the issue template, please! Otherwise we have no idea what steps you took or any of the other details and then we have to spend time asking you them anyway and you get help much later. Fill out the template for your own sake, if not ours!

We do not provide support over Twitter or any other forms of social media. Not only is it not guaranteed we will see your comments, it is a very painful way to do support that we avoid. If you need support, submit an issue on our issue tracker. Or you can raise subjects of interest on Unwriter’s Slack, or the Metanet.ICU Slack.

If you are a MacOS user and cannot install/run our latest release, please read this article.

What has changed in this release?

The main changes in this release have been listed below. If you don’t want to know the details, just read the titles. If you want to find out about smaller fixes, you can check the release notes in the Github repository.

Re-enabling change

Affects users of 1.3.11 who had not manually enabled this setting.

Unfortunately, one of the changes made before the release of ElectrumSV 1.3.11 was in how we looked up a wallet’s setting for whether it should use change. Before it defaulted the value of this setting to enabled, but that default was lost and the setting became disabled by default.

The wallet settings.

It should not be necessary for users to alter their settings to correct this, unless they stay with 1.3.11. The update to 1.3.12 will change the default setting, and only users who have explicitly set their wallets to not use change will override that default setting.

We in no way expect people to understand the following view of what a transaction looks like. But users who are able to understand the more technical side of things, can gain a visual hint of where the coins involved in their transaction come from or go (this is not perfect and has flaws). A green entry is a coin that has been received into the account, and a yellow entry is change made from a payment that stays in the account. An example of how it is flawed, is that this wallet is sending to one of it’s own addresses, so the first entry in the outputs should be green instead of grey (we will fix that eventually).

An imperfect way to verify that your transactions are making change properly.

One difference with this fix, is that we now also enable multiple change by default where it was not enabled before.

Issues: #699
Commits: #1

Signed Windows builds

Makes the wallet seem more respectable as users should not get a nebulous warning.

Just before Christmas, I was sent a code signing key that lets me sign our Windows executables. This should mean that users no longer get shown this message about an “unrecognized app” when they run one of our executables. Thanks to the Bitcoin Association and Patrick Prinz for sorting this out for us, these things are very expensive and complicated to get.

Windows protected your PC!

With a signed build, running one of the executables goes straight into the wallet.

Per-release unique first dialog shown on startup.

Ledger “unverified inputs” known issue

Affects Ledger users with later versions of their firmware.

This is not so much a change in the wallet software, as it is an extension of the known issues page we maintain for hardware wallets. The core problem is that Ledger “solved an exploit” where someone could get a user to sign a transaction multiple times, hope the user didn’t realise it looked weird when they signed it multiple times, combine the result and end up giving the miners a higher fee. And so now an ElectrumSV user, using a Ledger device, sees the follow screen of a set of confusing screens.

No real world user understands what this means.

What the “unverified inputs” message means is related to the coins that your transaction is spending. The transactions those spent coins are in, need to be fed into the Ledger device by ElectrumSV. We do have code that will do that, but it does not appear to be working. And to be honest, it’s probably better to just show these screens to the user.

In case you wonder why we do not enable this code, consider Trezor users. In their case we do feed the parent transactions into the Trezor device because there is no other option to keep the device working. But Bitcoin SV, unlike Bitcoin Core or Bitcoin Cash, can handle large transactions and hardware device cannot. The maximum size of the locking script for a spent coin (on a Trezor, no idea for Ledger) is under 15 KiB and that is not a thing on Bitcoin SV, so we can never guarantee it will work.

Commits: #1

Wallet window leakage

Affects users who open multiple wallets at the same time.

This isn’t a critical problem, it only happens once per additional wallet that is opened while ElectrumSV continues to run. However, we have had reports of locked resources when we have had similar issues related to wallets not being cleaned up properly in the past.

The details aren’t interesting, in fact quite the opposite. A future linked to a cancelled async task had to be dereferenced, in order to get the reference to the wallet window in the exception on the cancelled task to be released, allowing the wallet window to be garbage collected. I consider this more a Python language failure than a bug we caused.

Commits: #1

Disallow opening future wallet formats

Affects users who have used older and newer versions together.

When a wallet has been created with a newer version of ElectrumSV, it should not be possible to open it in an older version of ElectrumSV. Doing so would result in either errors opening it, or wallet corruption.

A wallet from a later version of ElectrumSV is reconised and a load failure message shown.

Issues: AB#183
Commits: #1

An option for MacOS 10.13 and 10.14 users

Affects MacOS users who are stuck with 10.13 and 10.14.

We cannot support MacOS 10.13 or 10.14 as we do not have anyone willing to do it, or who has the knowledge to get it working. For this reason, the later releases of ElectrumSV do not work with those versions of MacOS. Users however who are stuck with 10.13 or 10.14 have reported that ElectrumSV 1.3.4 works fine. For this reason we are making it available again on our web site.

Issues: AB#181
Commits: #1

What changed before this release?

Each of our release articles links to the article for the release before it. You can follow our releases back and see what changed in each, by the article that accompanied that release.

--

--