Hopefully this will be the last beta version of ElectrumSV 1.3.0, but only time will tell. This release cleans up a lot of bugs, so if you are using any of the earlier betas it is strongly recommended that you upgrade!
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.
What has changed in this release?
If you don’t want to know the details, just read the titles.
Ledger and Digital Bitbox non-multi-signature hardware wallet signing was broken
Affects users who try to sign their own transactions with Ledger and Digital Bitbox hardware wallets.
An updated dependency or change in how one was used likely locked down the transaction object so that when these two hardware wallets stored signing information nothing used on the relevant transaction, they now errored.
Hardware wallet account creation broken
Affects anyone who created a new account using a hardware wallet.
The hardware wallet code is tightly coupled to it’s use of the UI. This means that if it locks up the account wizard while the account wizard polls for available devices, it is not possible to cleanly put that polling into another thread like I did without significantly more work. Qt5 does not like UI elements in one thread (the hardware wallet thread) that interact with the UI elements in another thread (the original account wizard thread).
It’s not worth fixing this properly. Hardware wallets are unlikely to be long for this world. And so the removal of the wizard lock ups through threading has been reverted so that all wizard triggered hardware wallet UI interactions, now implicitly happen in the thread for wizard UI interactions.
Memory usage by your transaction data is no longer unlimited
Affects users who process lots of transactions that contain lots of data.
One of the problems with the JSON wallet storage we inherited from Electrum Core through Electron Cash, was that when you loaded it you had to load everything in it. This included all your transaction data which had to be stored in memory. With this in mind, it’s not surprising to see a recent bug by a user who reported that on Linux, when restoring a master key which they had used to write a lot of OP_RETURN-based data on-chain, their Linux operating system slowed to a halt and became unusable.
With this change, we’ve added a cache that limits the amount of transaction data that ElectrumSV can hold for any given wallet. The default limit is 32 MiB, a unit I think was invented by hard drive manufacturers so they could say 32 MB and mean 32 * 1000 * 1000 and infer 32 * 1024 * 1024. So that’s a limit of 32 * 1024 * 1024, to be clear.
You can view the current state of your wallet’s transaction cache in the wallet information dialog.
The state of your transaction data cache is updated every second, or on some similar frequency.
Networking UI status was not always updated correctly
Affects people who were in a situation like where they lost network connectivity and regained it.
This was something along the lines of us only updating the network status when there were synchronisation-related changes, and not when there were connection-status related changes. This was fixed by hooking status bar updates to the latter, in addition to the former.
Sporadic rare networking issue
Affects probably very few people.
Networking would occasionally error when it got a new header and was in the process of connecting it to the existing blockchain, and it was also in the process of deciding if it was using the right server.
Affects people who want to see the ElectrumSV interface with text in another language.
You might not know this, but we accept user provided translations for non-English languages through our CrowdIn project. One of our users pointed out he had been updating and we hadn’t done a release with his translations in, so this should now be rectified.
I went over all the outstanding unapproved translations and verified it wasn’t someone childishly furnishing a language with expletives, and also got rid of some useless translations which we probably inherited from Electron Cash.
More consistent forms in user interfaces
Affects anyone irked by different user interfaces doing the same thing a different way.
I expect that many of the user interfaces we inherited through both Electrum Core and Electron Cash were done by programmers who didn’t really like doing them, and just did what was necessary to get their feature in. So there was no real attempt to maintain a style. And it doesn’t help that there’s a lot of pain in getting proficient with Qt5, and dealing with hard to fathom layout issues.
Some of my past prototyping created a standard styled widget for form layouts, which has now been reused in most places throughout the wallet.
And so on. It’s not perfect, but if we change the way the common form widget is styled all the places where it is used should change consistently.
Some remaining niggles you may notice:
- The buttons in the line edit in the wallet information dialog overlay the text in the line edit. It should be possible to style these “button edit” widgets to have a padding on the right hand side that prevents text from going under the buttons.
- Labels beside text are positioned at the same vertical placement. Labels beside edit widgets, especially in the case of line edit widgets like in the account information dialog (for instance the name and script type rows) are higher and are vertically misaligned.
Pull requests for these things are welcome! And if you do want to try and fix some of these, note the “Master public key” label has no colon (because it’s obviously passed into the form layout as a label and not text), take care of that while you’re there huh? 😉
Wallet export was broken
Affects anyone who has tried to export their account history in any of the beta releases.
We no longer export the same data, since we moved to a wallet database from the JSON format. The export process was trying to export something that it no longer had on hand.
Failed migration in some circumstances would appear successful
Affects some people who might have imported 1.2.5 wallets into 1.3.0b4.
Wallets should migrate successfully, of course. But if your wallet is partially synced in 1.2.5, and we cannot reconcile the state, we abandon the process and do not even try. I call this the halting problem. The wallet would appear to have migrated successfully, and who knows what happens after that. But any new wallet would have been empty, and the older wallet would have been there as a backup.
Changing the wallet password was broken
Affects everyone who tried to change their wallet password.
A badly chosen assertion errored when someone had loaded a wallet and tried to change their password.
There are only one or two outstanding changes required before we make the final 1.3.0 release.
The last feature is a notification center for the wallet. The primary reason this is needed is because I plan to track if people have copied down critical information, and remind them to do so if they haven’t. In the longer run it will be extended to do things like notify users of incoming messages from other users, and many more things that require their attention.
Something that needs to be tested and given a solid going over is the existing wallet label backups. This was changed, and wasn’t able to quite work exactly as it did before.
Other than that, the end is in sight and work has already begun on the road to Paymail, hosted services and similar things.