This article covers the release of ElectrumSV 1.3.4, and some of the more important changes that have been made since ElectrumSV 1.3.3.
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).
ElectrumSV 1.3 migration guide
This article is intended to illustrate a few of the common uses of ElectrumSV, that have changed between the older…
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.
What has changed in this release?
If you don’t want to know the details, just read the titles.
Broadcasting transactions not already in an account errored
This affects people broadcasting external transactions.
One of the changes that came in ElectrumSV 1.3.0 was that the wallet holds onto a copy of a fully signed transaction if it was the last to sign off on it. These appear in the Transactions tab.
It has always been possible to broadcast transactions from within ElectrumSV, in several different ways. This is accessed through the “Load transaction” sub-menu of the “Tools” menu.
However, the transaction broadcasting logic had changed so that it expected successfully broadcast transactions to be there in the “Transactions” tab, and it would change their state to reflect them now being in the mempool. For external transactions this would result in a bland error. The transaction would still have been broadcast successfully, but the user would be left confused with a non-ideal experience.
We now correctly handle external transactions and no longer error on broadcast. And if there is an error in the ElectrumSV code, it is displayed in full rather than showing a bland summary that could have come from the remote server.
This is not ideal. In an ideal world we would hook this up to the logic that asks the user to submit it into our bug reporting system, and in the longer term we will do that. But the way this error happens is outside of the automatic reporting, and for now the goal is to allow the users that want to be able to broadcast external transactions without seeing this dialog to do so.
Help users export payment destinations
Affects users who want to export 10 addresses for instance.
I’ve been contacted by several people asking how they get multiple addresses from their ElectrumSV wallet. From 1.3.0, not every payment is made to an address so we no longer have a tab that lists all the addresses where a user can go through and copy however many they need. We now refer to the set of things that includes addresses, as payment destinations.
In order to help users export payment destinations for an account, whether they are addresses or perhaps BIP276 structured data, there is a new menu option and window. The new “Export destinations” sub-menu, is accessible from the context menu of a given account.
Selecting this menu brings up a window to help a user access their accounts unused addresses. Be warned there is no actual generation on demand, the user is literally accessing their account’s upcoming addresses. It is very possible that you can give them out again through the “Receive” tab which won’t know they might be in use until your wallet has received a transaction that actually uses them.
As the user changes the number requested, the list will update to include that number of upcoming unused destinations. They can then either click on the “Copy to clipboard” button to copy all the destinations into their clipboard (separated by newlines), or the “Save to file” button to save a text file with all the destinations (again separated by newlines). Once the export is completed, the user will see a warning dialog.
What changed before this release?
You can read more detail about bug fixes and changes, included in these.