If you are seeing this article, it is because we have an upcoming release of ElectrumSV (ESV) and likely referred you here to read more about the different changes we have made. I’ll attempt to put the changes in context, and help you visualise them better. Welcome, and I hope you find this an improvement over the way we used to do it.

It is possible that the new release is already out, you’ll be able to see it on our website when it is, or keep an eye on the visual indicator in your existing version of ESV which should change to a red colour. You might also get a popup notification when a new update is available. You can always click on this button and force it to do an update check if you want.

When this is red, update. Or don’t and deal with the problems.

Changes to this article since it was first published

  • 2019–04–28: Added section on the faster loading/saving for wallets with passwords. Added a section on the removal of BIP70 payment requests.

What have we changed?

Let’s look at the things you can see or try..

Faster loading/saving for wallets with passwords

Better networking support for heavy/high-load wallets

Recent attacks on network servers (mainly in BTC but also affecting BCH and BSV networks) have meant server operators taking measures to rate-limit requests so genuine users are served. This includes slowing down responses if request load is high, and timing out responses if the number of pending requests rises too high. ElectrumSV did not properly handle such situations and would resend all failed requests immediately. Worse, it would sometimes get impatient, dropping requests that hadn’t received a response for 10 seconds or so and resending them. This means the server gets the request twice (it doesn’t know the client has given up on a request) and when it finally responded, the client would no longer have the request it was a response to, meaning no progress was being made at all. Both effects exacerbated the server flooding, and the server would respond by throttling requests further.

The client now adjusts its request rate to the server’s response rate, and throttles its own request rate to roughly match the rate the server is responding. This means even heavy operations such as restoring wallets with long histories and many addresses should now complete successfully, though it may take some time.

A calming sea of green checkmarks from a fully synced wallet.

Scaling testnet support

The most common way to use a different network is to run ESV from the command-line with an extra parameter specifying which alternate network it should connect to.

For testnet, you simply use the --testnet option:

Starting up a testnet connected ESV on Windows

The wallet window should show a visual indication in the title, which you can see below:

ESV indicates on Windows the network it is connected to in the window title

And now for scaling testnet, you can also use --scaling-testnet to instead connect to the scaling testnet.

Starting up a scaling testnet connected ESV on Windows

Again, the wallet window indicates that you are connected to the right network. It’s a good way to ensure when you are liberally sending around large chunks of change, it’s play money, not real money!

ESV indicates on Windows the network it is connected to in the window title

Testnet access on Bitcoin SV is somewhat neglected. Often the only versions of applications and services, are hosted on the real network (mainnet). This requires developers to use a wallet with real money in, to test and develop their applications. All you need to do is start ESV with a different network, create a wallet for that network, and then obtain some funds. You can get testnet coins from bitcoincloud.net, right before you tip them for it. And you can get scaling testnet coins (not the same thing as testnet coins, just to be clear) from bitcoinscaling.io.

Getting some of those sweet scaling testnet coins.

Changing the listed block explorers

View this transaction on the selected block explorer.

We keep track of block explorers and allow the user to select which one to use in their preferences.

Pick your preferred block explorer.

Among many other possibilities, this allows you to verify that the transaction actually exists on a known service you probably use already.

In this release we’ve added a new block explorer, satoshi.io.

Additionally, the Blockchair block explorer has been removed as it displays the Bitcoin Cash ABC cashaddress style addresses for Bitcoin SV and has not responded to requests from the community to change these to be proper Bitcoin addresses. When and if they correct this, we are happy to add them back.

Improved Windows executables

Where this becomes problematic, is the way us ESV developers get details of what went wrong, is to get the console output. A pyinstaller-based GUI application does not write that console output.

This wall of text might actually be helpful in some circumstances.

We’ve known of the way to deal with this, but it’s not ideal, and we kind of had workarounds that let us still get the diagnostic information if the user was willing to do a few commands for us. But it’s recently become evident that our workarounds might be too late in the process, and we might miss earlier console output where the problem happened. It’s just one of those many many many many tasks that are waiting for someone to prioritise enough to make it happen, because we have so much to do.

Fortunately, Axel Gembe provided a fix, which we obtained and added to ESV. Now when an ESV executable starts up from the console on Windows, it can output all that useful information.

This is in fact very timely, because in the past month we’ve had two problems where this would have provided some context and helped us get on top of them. In the first case, I wrongly assumed it caused by some environmental problem with a users computer. Sorry Boris, and thank you Axel! 👍

Removal of BIP70 payment request support

We have plans to properly support BIP270 payment requests, and the initial code is already done. What we are waiting for is a workable identity system, so that the payment request process can involve signing by involved entities.

A warning about our development code on GitHub

But for those who do run the latest development code, and load their existing wallets into it, be aware that your wallets will be migrated to a new wallet format. The process should also backup your older wallet, but you will need to be aware you will no longer be able to load your updated wallet file into the ESV 1.2.1 or earlier. You can of course load the backup there, instead.

Last but not least

We’ve had recent problems that have not been easily examined, which this release should address. We’ve had reports of wallets that did not load or synchronise properly, which this release should address.

But we’re also going to be making more extensive changes that we have previously mentioned in our roadmap. These changes are going to require users to do things like migrate their wallet to a new format, and so forth, in order to help us move towards a better product.

By getting these fixes out there now, we can have a clean slate to start incorporating those more extensive changes, and users can have an updated application which will work better.

As always you can contact us on Unwriter’s slack, or Metanet ICU slack if you are a member with access. You can also submit issues on our GitHub repository.

I hope you enjoy our new style release notes!

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