ElectrumSV 1.2.1
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.
Changes to this article since it was first published
- 2019–04–29: Added a reference to the removal of Blockchair from the our listed block explorers. Added a section for users who run the latest development code, and how that affects their use of this release.
- 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?
A lot of the changes for this release are lower level, and not so visible. This includes changes to the lower level networking code we use in aiorpcX. It also includes the way we are slowly refactoring out Bitcoin-related code and adding more tests to ensure the correctness of that code in bitcoinX. But those are sort of hard to see, so we shall not go into much detail about them.
Let’s look at the things you can see or try..
Faster loading/saving for wallets with passwords
When you set a password on a wallet, it encrypts it using AES encryption. For some users the last release did not have the super-fast C support for AES encryption. When this is not available, ESV falls back to using the Python support for AES encryption. Unfortunately, this can be the difference between a wait of several minutes for a wallet to load, and instantaneous wallet loading.
Better networking support for heavy/high-load wallets
The blockchain servers that ESV uses are provided to you by generous people for free. But they aren’t unlimited resources, they have resource limits and blind use of them will result in them reducing the service they provide to you.
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.
Scaling testnet support
When you start up ESV, it will operate on the “mainnet” Bitcoin SV network by default. This is the one where all your money is, and is considered to be what Bitcoin SV is. But it has also been possible to start up ESV so that it operates on the “testnet”. With this release we add the ability to start up ESV so that it operates on the “scaling testnet”.
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:
The wallet window should show a visual indication in the title, which you can see below:
And now for scaling testnet, you can also use --scaling-testnet to instead connect to the scaling testnet.
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!
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.
Changing the listed block explorers
ESV is one of those applications with has menus have never probably bothered to really look at, but what you might not know is that when you view the menu for a transaction, you have the option to view it on a block explorer.
We keep track of block explorers and allow the user to select which one to use in their preferences.
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
We use a Python package, pyinstaller, to build our executables for Windows. One of the limitations this solution has, which is because of the way Windows console and GUI applications are different, means that when it starts up it does so as a GUI application and behaves in that way.
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.
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
This was neglected and untested. And it’s being replaced in an upcoming release by BIP270 payment request support. As such, if you are a user of the now unsupported BIP70 payment requests, you’ll have to use our old releases (assuming they worked for you).
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
This will not affect you unless you run the latest development code from GitHub. If instead you just download and run our releases — like the one this article documents — you will remain unaffected.
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
There are several reasons we want to get this release out.
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!
