ElectrumSV 1.3.3
This article covers the release of ElectrumSV 1.3.3, and the things that have changed since ElectrumSV 1.3.2.
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.
What has changed in this release?
If you don’t want to know the details, just read the titles.
Inability to sign multi-signature transactions
Affects all multi-signature accounts that have a subset of required cosigners.
A multi-signature account constructs an unsigned transaction, then as it is signed by another cosigner it is considered partially signed until it has the required number of cosigners. Now it is signed, or complete. The required number of cosigners is called the threshold.
It turns out that the space allocated in an incomplete or unsigned/partially signed transaction, was constrained by the threshold. This means that some cosigners who were placed later in the signature order, happen to fall outside of the signature space and cannot sign. This was not a problem if all cosigners were required to sign.
This is a pretty bad bug and it’s surprising it was not reported earlier by anyone.
Wallet and account creation was unstable
Affects an occasional person who creates a wallet or account.
We use the Qt5 QWizard and QWizardPage for our wallet and account wizards. The buttons you see in the wizard are shared between pages, and so moving from page to page would leave the handling from the previous page in place as well as adding the handling for the new page. There are no events in this design for the pages to use to remove their handling before the new page adds it’s handling. This means that occasionally these wizards break and do not work for some users, if they use the right combination of button clicks.
An concrete example of this was when you move from the splash screen on wallet startup..
To the wallet selection page..
What is not obvious, is that the Create New Wallet button in the wallet selection page is the same button as the Release Notes button in the splash screen page. Now that we have the ability to remove the release notes handler when the splash screen page changes to the wallet selection page, trying to create a new wallet won’t oddly move you to seeing a failed wallet migration.
Increase the maximum incoming data size to 50MiB
Affects people who have large transactions if they are lucky.
Where to start..
ElectrumSV as an application has an in-built limit which prevents malicious servers from sending them endless data. It was set to 10MiB, which because all data is sent as the JSON text format, means ElectrumSV can receive 5MiB of binary data (one byte of binary data converts to two bytes of hexadecimal text in the JSON). We have now bumped the limit to 50MiB, which in theory allows 25MiB transactions to be received.
This does not really help anyone. ElectrumX servers are run by kind community members using their own time, effort and money. Each defines a MAX_SEND value which is how large a piece of data they can send. It turns out almost every server has a limit of 1 MiB, again that is a 500KiB transaction. One exception to this is Neil’s server, which has a limit of 2MiB, again that being a 1MiB transaction. Until these limits are lifted, it accomplishes little for an ElectrumSV user to be able to increase the limit in their wallet.
But it’s not that simple. This value caps any kind of data that an ElectrumX server sends, so to bump it increases the other kinds of work it will do at the behest of a user. If I were running a server, I would be very hesitant to lift it, especially to anywhere near 10MiB from 1MiB. It is arguable that ElectrumX needs a special case to send low work data like transactions, versus the kind of key history usage data that allows a user to restore an account.
Commits: #1
Loading a transaction without an account
Affects.. people who load a transaction without an account 🤷♀️
To view a transaction in ElectrumSV, does not require that it is related to your account. You can just load one in from the blockchain, or a file.
Yes, this UI is obscure. But until we can reconcile identity of the involved parties, it will always be complicated. Also, perhaps it is the advanced user view and the everyday view is yet to come as we move towards Paymail.
What changed before this release?
You can read more detail about bug fixes and changes, included in these.
