ElectrumSV 1.3.7
This article covers the release of ElectrumSV 1.3.7, and some of the more important changes that have been made since ElectrumSV 1.3.6.
Do you need an introduction to how ElectrumSV works?
We have a selected range of guides to common tasks that our users may want to do in our documentation, please check it out.
There is also a 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). This is partially replaced by the documentation guides, but still has some useful additional information.
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?
The main fixes in this release have been listed below. If you don’t want to know the details, just read the titles. If you want to find out about smaller fixes, you can check the release notes in the Github repository.
The allocated funds summary has been corrected
Affects people who have signed but not broadcast transactions.
If an account has local transactions that have not been broadcast, they are found in the Transactions tab. However, it is not that obvious that these transactions are there, and some users forget they signed but didn’t broadcast transactions. So if there are transactions there, we display a summary in the History tab saying how many coins are allocated and in how many transactions.
The only problem was that we were not showing how many transactions were present there, but rather some other count like how many coins in total were in use by those transactions which is pretty useless information.
Commits: #1
Prevent sending to partial multi-signature addresses
Affects people who try and manually select whatever their computer lets them.
When you select text with your mouse, you often do not select all the text you wanted as your operating system has it’s own ideas for how text selection works. If what you want to copy is longer than what is visible, then it is possible you may only select part of what you want to copy and not even realise it. As the way that ElectrumSV does addresses for multi-signature accounts results in long addresses, this is very possible.
The main reason for the “pay to script hash” (P2SH) mechanism in Bitcoin was so that more complicated scripts could be treated as an address. Addresses are a kind of unreadable bank account number to begin with, but given the lack of a better solution, they are a standard way to make payments to a destination. As P2SH is an abomination and has been disabled in Bitcoin SV, more complicated scripts now lack a way to easily be copied and pasted to people you want to pay you. Paymail in the longer run could very well make this a lot easier, especially making use of SPV Channels. But we’d still likely need something like an address anyway.
ElectrumSV came up with a way which is documented in BIP276. Unfortunately a legacy feature of what you can tell ElectrumSV to make payments to, is that the entered destination can be the assembly language form of a Bitcoin script. If you partially copy some text from the BIP276 “address” for a multi-signature script, it can be treated as valid Bitcoin script assembly language. This is not good.
Even after this fix, we still allow assembly language payment destinations because.. we’re ElectrumSV, but now we require the script to be prefixed by asm:. e.g. asm:OP_FALSE OP_RETURN 20202020. This means that mis-copied BIP276 payment destinations will be invalid and now payment will be prevented until they are corrected.
Below I construct a payment to both an address and a Bitcoin assembly language script in the send tab for my current account.
Next I press the preview button to see what this transaction looks like. You can see the destination address, the destination script and the change address in that order.
If we sign the transaction and view it on the ever useful WhatsOnChain blockchain explorer’s decode transaction page, we can see verify that this is indeed correct. Remember that there is no direct marker in a transaction showing what network is associated with, so you should go to the correct subsite for your transaction — in my case this is the Testnet subsite for WhatsOnChain.
This should now prevent a possible problem for multi-signature users who copy only part of their BIP276 address. We won’t mention that there is a copy button right there beside the address which copies it all properly.
Thanks to Brendan Lee for reporting this, and not using the copy button..
New documentation
Affects people who want some actual documentation to help them.
We have added support for documentation, and an initial set of documentation pages to our source code. The idea is that as changes are made to ElectrumSV, updated or extended documentation can be included with those changes. Or if you or any other user wish to add some information, you can make a pull request with the desired changes on Github. The actual generated documentation is published to the handy Read the Docs hosted web site, almost as soon as we upload the changes to our Github source code repository.
Again, you can already read our published documentation at:
We’ll continue to improve it as we get the time and opportunity, but it will be an ongoing task and won’t be as complete as we’d like as fast as we’d like.
Transaction dialog improvements
Affects people who want a more dynamic ability to inspect their transactions.
We had a false alarm a week ago. A user who makes use of our provisional REST API reported wallet corruption problems where transaction outputs in their wallet were spent, but not marked as spent. This results in a broken experience where the wallet can create bad transactions that try to re-spend already spent coins. It turns out that this can only happen if the user is actively spending their coins from different wallet software than ElectrumSV and it is conflicting with their use of those coins in ElectrumSV. We can never support this officially, even though it may work if a user understands the problems and is prepared to deal with them.
Anyway, in debugging this some improvements were made to the transaction dialog. And by improvements, I mean minimal changes that allow some interaction with inputs and outputs.
In the above screenshot you can see:
- The “Copy <column name>” menu: It is now possible to copy column values from a given transaction input. This is useful where you might want to copy the value or the transaction Id that is being spent.
- The “Details” menu: If the account has the input transaction then this will open another transaction dialog showing that transaction.
Double clicking on the input row will do the same thing as the “Details” menu without requiring use of the menu, much like in the history tab.
- The “View on block explorer” menu: This will view the input transaction on the current selected block explorer. You can customise your preferred block explorer in the Preferences, or use one chosen at random.
- The “Spent input value” amount, which allows the user to avoid having to manually add up all the inputs that are being spent from their wallet.
Note that the only way to know an input value is to have the transaction it comes from, so in this case even though the spent input value of 0 is correct as the transaction is not ours, the “unknown” might reflect that the spent transaction is not one of ours (or in this case that the code failed to detect it was one of ours). Similarly if you do not know the input values, you cannot know the fee and so the fee also shows as “Unknown”.
- The “Received output value” amount, which allows the user to avoid having to manually add up all the outputs being received into their wallet.
As the second output is obviously a standard bare multi-signature script, it can be assumed to be the change to the paying wallet.
In the above screenshot you can see:
- The “Copy <column name>” menu: It is now possible to copy column values from a given transaction output. This is useful where you might want to copy the value or the payment destination.
While it is not formally documented by us, the colouring is that your account’s change coins are yellow, and the received coins are green. This is how we inherited it from Electrum Core. We have added a new colour, red, and if you see this your coin is broken because you used your coins (and therefore seed words) in multiple different wallet applications at the same time and didn’t know why this may corrupt a wallet.
I will sum this up and say that this is not how we envision this dialog working. We will eventually be redoing this completely, and making it more interactive and less developer-centric by default — although we will retain the developer introspection in a better and more extensive form. If you have ideas please get in touch and share them. But technical debt has to be paid off first before this work will proceed.
Extended REST API
Affects users who are using our provisional REST API.
We do not have a finalised REST API yet, but we do have a provisional version in the form of a reference application that extends ElectrumSV to be used as a headless (no GUI) wallet server. Some of our more adventurous users have already discovered it and are using it despite it’s limitations and rough edges.
AustEcon [SV] maintains the example REST API application and has both fixed some of the problems with it and also extended what it allows. But remember that this API will change in future, so if you use it you must either be willing to maintain it yourself or upgrade later.
Documentation for the example REST API can be read in ElectrumSV’s new documentation web site.
Commits: #1
What changed before this release?
You can read more detail about bug fixes and changes, included in these.
