ElectrumSV 1.3.5
This article covers the release of ElectrumSV 1.3.5, and some of the more important changes that have been made since ElectrumSV 1.3.4.
Do you need an introduction to how ElectrumSV works?
Perhaps you might be better served just heading over to our guide that illustrates some of the common uses of ElectrumSV. Especially if you are new to ElectrumSV, or coming from ElectrumSV 1.2.5 (or even earlier versions).
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?
If you don’t want to know the details, just read the titles.
The MacOS user interface has issues
Affects people who use MacOS.
ElectrumSV uses the well known Qt5 framework for it’s user interfaces. Unfortunately, like many open source projects there are many bugs that do not get the attention they deserve. One of these will lock up your ElectrumSV application if it happens to you. The ElectrumSV developers do not have time to spend weeks debugging someone else’s project to fix there bugs, so MacOS users are going to have to deal with it.
The problem here is that modal message boxes are displayed as what Apple calls “sheets” where they aren’t a window per-se, but are rather a drop down panel over the current window. However, Qt5 seems to leak a blank sheet that cannot be dismissed, and this is what locks up ElectrumSV. It however only seems to happen under rare cases. On some other occasions there might be some remnant text from a previous sheet.
In order to help MacOS users who suffer from this Qt5 problem, we offer an option that disables use of “sheets” and uses modal message boxes (that can be dismissed) in their place. It breaks the preferred Apple styling, but it beats the “sheet of death”. You can find this option in the “UI” section of the “Preferences” window.
Interestingly many of the bugs that are exhibited on MacOS because of Qt5 eccentricities are also exhibited on Linux. So fixing them in one place (or more likely working around them) will fix them on the other — the “sheet of death” excepted. Windows Qt5 support however seems much more resilient and less prone to eccentricities, crashes and so on.
The “Requests” list on the Receive tab is polished
Affects users who want to know if requested payments have been received.
The Requests list was only ever shown if the user had saved a request using the form above. Now we show always show it. In theory when payments to the address associated with a given request were received, the request would flip from the “Unpaid” state to the “Paid” state. Did it do this in 1.2.5? Did it stop doing it in 1.3.0? I had a quick look and I am pretty sure this didn’t work in 1.2.5.
We could of course do more to flesh this out, perhaps notifying the user of completed payments in some way, or setting the description on incoming transactions to be accessible from the History tab, or even marking incoming transactions that complete a request in a similar way to how invoices are marked. But there’s a lot of other priorities to focus on.
Issues: #414
Commits: #1 #2 #3
BIP 270 support and polishing of the “Invoices” list on the Send tab
Affects users who want to pay external payment requests.
The Invoices list was only ever shown if the user had imported a BIP 70 payment request in some way. This meant it was useless in ElectrumSV as we had removed support for BIP 70, and we added support for BIP 270 a year or so ago — but it wasn’t fully hooked up as there were no BIP 270 servers for us to make payments against. Now that there are some servers, we have enabled the list and always show it to make it more visible to the user. What drove this work was we suddenly started receiving error reports where people were trying to use this, and it would error.
There are several ways that you can import a BIP 270 payment request into ElectrumSV. The easiest is to paste the URL into the “Pay to” field, and then things will start processing and the invoice/payment request will import. But you can also pass it as a URL on the command-line when starting ElectrumSV, if you look at the command line help.
In the following screenshot, you can see where I have imported a payment request from Paypresto’s BIP 270 demo site and have paid it.
The transaction that your payment of an invoice makes, appears in your History tab with the description from the invoice you were paying. And it has a distinguishing icon which is supposed to resemble a wax-style seal, although it might also be mistaken for a rosette not unlike the one the judge at the town fair pinned on your prize cabbage.
Transactions associated with an invoice have an extra menu item that allows the user to quickly view that invoice (assuming they haven’t deleted it).
The invoice window is pretty simple and shows a naive breakdown of the payment request details.
Issues: #379
Commits: #1 #2 #3
An “Account” menu has been added
Affects users who many not think to try for a menu on the accounts list entry.
Many of the menu options for an account had been moved to a menu on the entry in the accounts list, in preparation for the enabling of multiple accounts in a wallet (which is still not enabled).
Some users may not think to try for a menu there, so in order to make the options more visible they’ve now also been added to the main menu for the wallet window.
Upgrades to the transaction dialog
Affects people who view a transaction.
The transaction dialog is useful to see things like which inputs and outputs of a viewed transaction are related to your wallet, but it’s a little rough. It could be a lot better. It has received some bug fixes and minor visual polish. Like many other parts of ElectrumSV, there is much more that can be done — but it’ll have to wait for another day.
Issues: none.
Commits: #1
Add filter and refresh buttons to most tables
Affects people who did not know that you can refresh and filter.
It isn’t always guaranteed that the lists in the wallet will be updated immediately, or for all changes. If a list hasn’t been updated, a user should refresh it and shouldn’t need to restart the wallet.
The list in the History tab now has visible filter and refresh buttons. The other button is for exporting the list entries.
The invoices list in the Send tab now also has visible filter and refresh buttons.
The requests list in the Receiving tab now also has visible filter and refresh buttons.
The list in the Keys tab now also has visible filter and refresh buttons. It has always been possible to filter for addresses here, but now those who need visible buttons to know this can press them and gain whatever satisfaction that gives them.
The list in the Coins tab now also has visible filter and refresh buttons.
Commits: #1
More visibility for the Transactions tab
Affects everyone who wondered what this tab was for.
We now show a summary of the transactions in the Transactions tab and the value of allocated coins. This is because it isn’t always obvious that the user has signed a transaction but not broadcast it, and since we retain signed transactions, that coins may be allocated but the user has to guess they need to go look in the Transactions tab to see where.
The Transactions tab is generically named. So now if there are no entries present we show a placeholder description to let users know what it would be used for.
Commits: #1
Other bug fixes
A range of embarrassing bug fixes.
Incoming mined coins wouldn’t properly be marked as coinbase-related. This mwas not that bad, as in the worst case the wallet might try and spend them and fail, and a wallet restart would reclassify them correctly.
Commits: #1
Disconnection from a server could leave the wallet deaf to new transactions and unresponsive. This was pretty terrible and would require a wallet restart to get it working again.
Issues: #451 #459
Commits: #1 #2
Disabled the “Save Copy” File menu option for wallets. This no longer works reliably with the wallet data stored in an Sqlite database.
Commits: #1
It was possible to open the same wallet twice. What normally happens if you open a wallet that’s already open in the same ElectrumSV instance, is that it just shows you the relevant window for that wallet. However Qt5’s file selection does not respect platform-specific path separators (it always uses “/” for consistency rather than “\” on Windows), so this was breaking comparison.
Commits: #1
What changed before this release?
You can read more detail about bug fixes and changes, included in these.
