As the process of polishing ElectrumSV 1.3.0 continues, I am trying to release usable beta releases as often as possible. If you are using one of the previous beta releases, you are encouraged to upgrade to this release. Bugs are fixed, and features re-enabled.
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.
Bare multi-signature is the default multi-signature script type
Affects users who are creating new multi-signature accounts.
The previous release was made before the Genesis upgrade and still defaulted to P2SH scripts for multi-signature accounts. As we are now past the Genesis upgrade, the default script type for multi-signature accounts is bare multi-signature.
Standard accumulator multi-signature script type supported
Affects users who wish to try more miner-friendly multi-signature transactions.
One of the core requirements of the changes that allow the use of bare multi-signature scripts, given that payments to P2SH scripts do not work after the Genesis upgrade, is that an account can choose any viable script type it should use for a new transaction and keep track of it.
With this already in place, it was a minimal amount of work to also add support for the standard form of accumulator multi-signature scripts. These are more lightweight than bare multi-signature in that they specify which signatures to check against which keys.
In the longer run when these have been more widely used and the implementation tested, we will set this script type as the default one used by new multi-signature wallets.
Fix opening wallets with accounts that are mid-synchronisation
Affects some users who closed their wallet while it had cleared but not yet settled transactions.
I am surprised we didn’t hear about this happening more often. A cleared transaction is one we know is in the mempool, and a settled transaction is one we know is mined. So it should have been affecting some users who closed their wallet after sending a transaction, but before it had been confirmed. Any user experiencing it, would have encountered an error loading the wallet and the wallet would have been broken until they upgraded ElectrumSV.
Account synchronisation has been optimised
Affects both users who are restoring accounts from seed/a master key, and users whose account is being synchronised on opening it.
UTXO caching has been added in 1.3.0 to greatly increase transaction creation speeds but the algorithm for processing new or used utxos was aimed at correctness rather than speed. As a result, updating the utxo set was O(n²) with respect to number of outputs in a transaction. This has been optimised to O(n).
A transaction with 1000 unique outputs creates 1000 new key subscriptions to ElectrumX. The problem was that to update the utxo set, this costly algorithm was iterating over all 1000 outputs for each of these 1000 subscriptions (1 million iterations). To avoid this duplicated computation, a cache was added that maps scripthashes to txo indices in a given transaction and allows processing of only the relevant outputs for a given transaction (usually just a single output if keys are not reused).
Synchronised messages larger than 1 MB are no longer discarded
Affects users who restore accounts that have previously been externally for writing data to the blockchain.
The connection that an ElectrumSV wallet makes to any server has a default limit of 1 MB, where if it receives a message larger than that, it discards it. With the move to larger transactions on Bitcoin SV, especially those that either pack data into
OP_RETURNor pushdata, this is not longer large enough.
The new default is 10 MB. We should ideally handle this better, and even allow the user to customise it either globally in the wallet, or on a per-account basis. But for now, due to resource constraints this is good enough.
MacOS builds might require Mojave (10.14) or later
Affects all MacOS users who use our builds and have an earlier version of MacOS than Mojave (10.14).
Our builds are created on (almost) every commit we make to Github, using Azure Pipelines. Detecting that we used their 10.13 VM image, they emailed us and told us that it was being removed, and to switch to their 10.14 VM image.
ElectrumSV does not devote resources to making sure that all new versions released work on all old computers that people have ever been able to run earlier versions of the wallet on. We focus our limited resources on whether it works on more recent systems.
Handle BIP276-style BIP21 URLs
Affects anyone who happens to receive a payment URL that contains a BIP276 payment destination. Or wishes to give one out.
With the Genesis upgrade past us, people can give out payment destinations that do not have addresses. This might be bare multi-signature scripts, accumulator multi-signature scripts or for that matter anything else. This is what BIP276 was intended to facilitate until we could support Paymail.
Add support for Python 3.8
Affects no-one except developers and users who run from source.
ElectrumSV currently requires a subversion of Python 3.6, but at some point we are going to upgrade our minimum Python version to 3.8. What stops us at this point is that PyInstaller does not currently support Python 3.8, and until it does we cannot upgrade because we can’t provide builds.
MacOS builds now use Python 3.6.10. Windows builds now user 3.6.8, and are unable to upgrade as that is the latest version of 3.6 that the Python developers provide the required prebuilt development binaries files for. Otherwise users running from source are required to use 3.6.0 or higher.
It is very possible that we will switch away from PyInstaller, to other solutions before PyInstaller gets Python 3.8 support.
Change the SQLite database support to use write-ahead logging
Affects users with wallets that have accounts that engage in activities that heavily use the database.
The initial motivation for switching to SQLite was that we had to move away from the JSON wallet storage because in order to use any of it, we had to load all of it. And as it accrued more large
OP_RETURNtransactions, these were all held in memory and included in any saving of the wallet’s data.
While SQLite is very popular, using it is problematic and requires some degree of faffing about. Without every piece of related high-level logic reconciling the state of database operations in progress, it was necessary to lock lower-level logic so that there could be no overlap and race conditions. This meant that both read and write operations were very slow. In addition, as we let non-overlapping read and write operations proceed, we then encountered the limitation that SQLite could not have multiple concurrent read and write operations. You can read a post by someone else on this topic.
Our first change was to make all write operations non-blocking, and they are now handed off to a writer thread that takes care of all writes. The second change was to switch to write-ahead logging, which removes the remaining issue of reads getting blocked by the writer thread.
The stability of the write-ahead logging and dealing with rare and sporadic issues related to it, was the primary cause of the delay of this 1.3.0b4 release.
In the longer term, we will likely add support for the Postgres database, which will likely be required to provide more scalable backends for those who create a lot of transactions likely programmatically using ElectrumSV as wallet service.
Accounts can now have per-derivation path gap limits
Affects advanced users who use ElectrumSV as a wallet server likely via it’s REST API. Normal wallet users should never use this, and have better options for their related issues.
For now, most users just use the standard derivation paths. And if they need additional keys beyond what the standard gap limit provides, they can simply call a function in the console to generate as many as they need for either of the receiving or change derivation paths — while preserving the standard gap limits.
Developers who are building ElectrumSV “dapps” (short for daemon apps) where they run ElectrumSV as a wallet server, and customise it’s behaviour are likely the target audience of this change.
User interface polishing for the wallet wizard
Affects all users who select an existing wallet or create a new wallet.
The wallet wizard, which is used to select or create wallets, has been refactored to provide a consistent way of entering passwords. Additionally, various bugs have been fixed.
A user can also open a context menu for any of the entries, and use a menu to open their operating system folder view of the wallet directory. On Windows this is called “explorer” and on MacOS “finder”. Linux has no support for this, so users running from source on those operating systems do not get these options.
An initial implementation of in-application contextual help has been added, in the wallet wizard. This is currently in development, and it’s completion will not hold up any final 1.3.0 release.
Requests for passwords now appear using the upgraded existing dialog. When you enter the correct password, the “OK” button will be enabled and you can simply press the enter key while the focus is still in the password field to submit the “password” you entered.
Similarly, providing a new password uses a standard provide a new password dialog. Once a matching password is entered and confirmed, the “OK” button will be enabled and you can simply press the enter key while the focus is still in the password field to provide the “password” you entered.
Completion of the account wizard user interface
Affects all users who add a new account.
The account wizard, which is used to add an account to a wallet, has been completed. The main remaining piece of work was the ability to create new multi-signature accounts.
Once the user has specified how many cosigners there are, and how many are required to sign off on each transaction, they proceed on to specify who those cosigners are.
If for instance, this was an observational account and it did participate in signing any transactions, the user could simply paste in the extended public key of each cosigner and proceed to add the account.
If cosigners were signers, or needed to use the user interface to get their public key into this account, they could click on the key button to do so.
There is no restriction on how many of the signers can be handled by this account. The existing multi-signature transaction signing logic does not force itself to only sign for one of the cosigners, so there is no reason the user-interface should either.
Eventually the in-wallet user interface for the account will also let users convert external signers into local signers by replacing their extended public key with either of their extended private key or seed words. This is along the same line as a planned change to allow hardware wallet owners to provide the seed words for their hardware wallet account and convert it into a software wallet account that no longer requires the given device. Resource constraints put these tasks on the back-burner for now.
Fix transactions remaining unverified until state changes
Affects no-one, but maybe you.
In the rare case that the server notifies the account of events related to mining of it’s transactions before the server sends the headers for the blocks the transactions were mined in, the wallet will never know to verify them and show them as confirmed.
No-one ever has reported seeing this problem and it was only observed happening in development, so either it is really really rare or it’s one of those things that only starts happening after fixes elsewhere allow it to see the light.