Closely following our last release, ElectrumSV 1.2.3 is intended to fix outstanding bugs. If you missed what changed in previous versions you can find the guides for those at the end of this.
What has changed in this release?
If you don’t want to know the details, just read the titles.
Loading non-deterministic wallets sometimes broke
Affects anyone who uses a wallet that cannot generate new addresses when it needs them. Introduced in ElectrumSV 1.2.2.
ElectrumSV supports many different types of wallets. It supports it’s own standard wallets, which are deterministic (can generate new addresses). It supports BIP39 wallets (which are the ones other wallets make), which are deterministic. And among some of the others it supports are imported address wallets, which let you watch addresses. This is non-deterministic, and triggered the bug here when someone opened one in ElectrumSV.
I’d like to thank Jason, who popped into our issue tracker and pointed out the detail that this happened with his imported address wallet.
Broken search functionality
Affects anyone who knows about and uses this feature. Predates ElectrumSV 1.2.2, but exact version problem was introduced is unknown.
ElectrumSV does a lot of things, and some of them we ignore because we don’t use them, we’ve never heard of anyone using them, and we have a lot of other things to do. One of these things is the search functionality. I know it’s there, I know it’s neglected, but I have more pressing demands on my time.
It works something like this. You press Control+F and a search box is shown, then you enter some text of some sort, and maybe hit enter, and maybe it matches something somewhere in some user interface. Yeah, you can tell I have never used it. If you use it, and you think it should be doing something it isn’t, feel free to submit an issue. But it should be a naturally useful request, not some niche wish that you might have.
In any case, it now works again, or at least doesn’t break in obvious ways.
Transactions paying to public keys errored
Affects anyone with a wallet that receives transactions that include payment to public keys. Predates ElectrumSV 1.2.2, but exact version problem was introduced is unknown.
Neil has been moving bitcoin-related supporting code out into a supporting library. As he goes he has been refactoring the ElectrumSV code to use the new supporting library, and part of this is the code that implements public keys. When this got changed, the code that compares transaction outputs which can be addresses (P2PKH, P2SH), public keys (P2PK) to the addresses in your wallet broke.
This means that if you synchronised a wallet that had P2PK outputs in it, it would error. It meant if you had an existing wallet with transactions that contained P2PK outputs, you couldn’t view the transaction.
More reliable transaction verification
Affects anyone who monitors an address with lots of transactions, for instance one that gets mining rewards. Predates ElectrumSV 1.2.2, but exact version problem was introduced is unknown.
One thing the test case we had for the P2PK problem demonstrated, was that if there was a lot of transactions using an address, that timeouts could mean the verification process would break. And this would happen consistently, every time the wallet was loaded.
Neil rewrote the verification networking code, and now the same wallet that sluggishly choked and dies before, synchronises promptly and smoothly.
ElectrumSV daemon instances never exited
Affects anyone who runs ElectrumSV as a wallet server. Predates ElectrumSV 1.2.2, but exact version problem was introduced is unknown.
You can run ElectrumSV on Linux or MacOS (but not Windows) from the command-line as an application or JSON-RPC server/daemon. Because of refactoring I did a while ago, it turns out that when you stopped the daemon the ElectrumSV instance would not exit.
People tend to use the daemon to run ElectrumSV as a wallet server, generating new addresses and watching their activity, from an external application of their own via the JSON-RPC API. It’s very fragile and I wouldn’t recommend it to anyone as a production solution at this point. It needs a lot of work beyond this fix.
This means that every time you ran it, it would eventually leak a copy of ElectrumSV running in the background. This was fixed by tying the main loop of a daemon application to the life of the daemon thread, instead of blindly looping infinitely.
Updated checkpoints = faster wallet startup
Affects people more and more over time as the blockchain gets longer. As the checkpoints have not been updated since ElectrumSV 1.0, this includes any version of ElectrumSV before 1.2.3.
One of the features I contributed to Electron Cash before their misguided fork off to focus on BCH, was checkpoints. Without checkpoints, a wallet has to get all the headers for the blockchain and check each one against the previous one all the way up to the header for the latest block. Then it can know that new blocks it hears about are valid based on both the chain of headers each confirming the preceding one, and proof of work calculations, and then simply adding the new block on the end and validating it in the same way.
When the Bitcoin Cash blockchain owners colluded with exchanges to fork off from Bitcoin SV, they secured their chain with checkpoints. This prevents people from mining at a lower point and rewriting the blockchain, which sounds good in theory, but in practice is a complete mess. Some people misguidedly assumed checkpoints in a wallet like Electrum SV (or Electron Cash) are the same as the ones used to take the reins of BCH by the colluders. But that’s naive, and ignores the reason that we use checkpoints in a wallet.
When a new user (or a user who has not used ElectrumSV in a while) starts the wallet, it downloads the missing block headers. What used to happen back before Electron Cash had checkpoints, was that if you got a bad server, it could take hours before Electron Cash started working correctly. I had servers that downloaded the headers at 200 bytes per second, and for 80 megabytes, of headers that’s around 111 hours! This is a usability failure on so many levels.
How does a wallet checkpoint work? You basically define a header, with it’s hash, and the merkle root, as the checkpoint header. Any header you need before that height can be validated against that merkle root as being valid, in conjunction with a merkle proof. So of those older headers, you can just fetch the ones you need, and validate each independent of the chain of hashes. If you want to know more about this, you can look at the code.
Checkpoints in a wallet, allow it to not download any headers it does not need. This means the wallet can start working right away, rather than 111 hours later (in one of the worst cases). If the checkpoint is recent, then it does not need to download many and the wallet can indeed start right away. If the checkpoint is not so recent, then it does need to download headers and we get a little of the old problem. This change rectifies our old checkpoints, and makes wallet startup almost immediate again.
Working around the broken Keepkey/Trezor firmware updates
Affects anyone using Keepkey or Trezor on Windows with the latest Windows upgrade, and latest Keepkey firmware. ElectrumSV version not relevant.
For those that do not know what a Keepkey is, it is a hardware wallet that is now used by Shapeshift to push their exchange. That link is the one given to Keepkey users to get them started with their devices, and it’s really quite unhelpful mainly now being about pushing Shapeshift signups. I suggest you buy a Ledger. Trezor is another hardware wallet vendor, and also has similar problems after the Windows upgrade.
If you just kept using your Keepkey hardware wallet as is, things were fine. If you updated your computer to Windows update 1903, things were still fine. But if you both updated Windows to that latest update, and updated your Keepkey firmware you’d see an error when you tried to create a wallet for it.
Apparently, Microsoft now require some extra permissions to access USB in the way Keepkey do it in their latest firmware, and it affected Electrum Core, Electron Cash and also us — ElectrumSV. If you run ElectrumSV as Administrator, it would of course work, but that’s an unreasonable request.
Because Keepkey do not consider fixing this a priority, Axel Gembe who works with our other friends over at the Electron Cash for BCH, got in there and created a workaround. I don’t know who pays Axel, and I hope he is getting paid considering how hard he works, but I hope he’s well rewarded for his efforts.
The end result is that I could reproduce the problem, and after doing a build with Axel’s fixes, I could reproduce the problem was fixed. Keepkey (and Trezor) will work again for the subset of people that use it on Windows, and have both the latest firmware and the latest Windows upgrade.
Reducing antivirus false positives
Affects Windows users who have to jump through hoops to use ElectrumSV due to false positives by virus checkers and malware detectors. ElectrumSV version not relevant.
I’ve talked about our problem with antivirus false positives before. We use PyInstaller, which is also purportedly used by malware, and so we often have virus checkers telling our users our downloads are bad.
Axel Gembe made some changes to the pyinstaller bootstrap code which changes the fingerprint of the executable in some way, which is aimed at reducing the antivirus false positives that rely on similarity to the malware that use pyinstaller.
Hopefully this will make an additional difference.
Hardware wallets without a name could prevent them loading
Affects anyone who likely cleared their hardware wallet name and did not set a new one. Likely a problem from ElectrumSV 1.0.
You can name your hardware wallet in ElectrumSV. I think what happened here, if I recall correctly, was that someone set their hardware wallet name to an empty string and this then stored the name as a non-string, and the next time they loaded it, it errored.
What changed before this release?
These are the changes that are coming in ElectrumSV 1.2.2, there’s nothing particularly important, but..