This article is a progress report for the month of August, 2019. If you’re curious where the development effort goes, this might be of interest to you.
- Find our website here, where you can get the latest version.
- Find our issue tracker here, where you can work with us to fix any problems you might have, or submit proposals and suggestions for us.
- Discuss problems and ideas with us in the #electrumsv channels in selected slacks like Unwriter’s atlantistic and Metanet ICU.
Ongoing work proceeds in two different directions.
The highest priority is continuing to make fixes to and provide a set of stable and reliable working releases for our users. Beyond that, any additional available development time is spent on moving towards the minimum set of features that will allow us to do our first Paymail release.
We released two versions of ElectrumSV in August. These are made from our stable branch, which at this time is releases/1.2.
This release fixed quite a few bugs, from Windows updates breaking certain hardware wallets, to bringing in a change from Electron Cash which made it much less likely that our releases would be incorrectly detected as malware.
I write up each release going into the changes in detail, and if you want to find out exactly what was in 1.2.3, you can do that here:
Closely following our last release, ElectrumSV 1.2.3 is intended to fix outstanding bugs. If you missed what changed in…
There was one main reason we made this release, and that was to get coin-splitting working again after some necessary changes were made to the faucet we rely on.
If you want to find out more about that and the other changes that were included in 1.2.4, you can do that here:
This release primarily fixes coin-splitting to work with the changes to the faucet that it relies on.
It’s not recommended that you use our development branch, master, but beyond a few outstanding bugs it is reasonably stable. But it’s also a work in progress as I slowly refactor it in necessary ways so that we can do a minimal first Paymail release that will be ElectrumSV 1.3.
This is a task that aligns with existing plans from before Paymail, but happens to be a prerequisite of supporting Paymail.
The work completed in August was decoupling the keystores in a parent wallet from belonging to a specific child wallet, and allowing more than one keystore and more than one child wallet, and letting a child wallet specify which keystore it uses.
Now a parent wallet can in theory include a keystore for the user’s own personal usage, and a keystore for the user’s Paymail usage. The primary benefit for Paymail, is that the addresses that the Paymail host gives out will not overlap with those that the user themselves makes use of.
This is only the beginning of the required work to support multiple child wallets, and there are issues relating to the additional steps that still need to be completed.
Completing the move to a wallet database
Historically, Electrum stores all of your wallet data in a single JSON file, which it both compresses and optionally encrypts. Now if you’re using a altcoin designed for holding, and not actual use, this is all well and good.
But you’re using Satoshi’s original Bitcoin which was designed for real world use, and every transaction you create using your wallet gets added to this file, and loaded into memory when you open the wallet. Now, it’s not uncommon for people to post files to the blockchain these days, and each of these is composed of one or more transactions. And the path forward for ElectrumSV is moving all your child wallets into one parent wallet. This is going to start to add up.
To this end, some months back I did some initial work to move wallet storage to using the Sqlite database. This was not completed, and left us with a hybrid storage solution where some lesser data was still in the JSON file, and most of the data including transactions, merkle proofs and other related information was in the database.
The migration away from the hybrid storage model to just database storage is complete, but the work still requires some debugging and testing before it is ready to merge from the feature branch features/accounts, into the main development branch master.
Reference: Issue #213, move wallet storage to be completely sqlite-based.
As always work in the stable branch, and short term release needs outweigh ongoing work towards Paymail. And any new information or developments may direct anything listed here to be deferred in favour of more pressing tasks with higher priority— like unforeseen bugs.
It was pointed out that P2SH script outputs are going to be sunsetted, and where this affects ElectrumSV and it’s users, is that there will be no ability to make new multi-signature payments. ElectrumSV needs to provide a replacement way to do multi-signature payments, and this will be what is called bare multisig.
You can read this article to learn more about how P2SH is used in ElectrumSV, as a vertical slice from ElectrumSV down to the node through the indexing server ElectrumX.
You can read this article to find out my thinking behind the path forward for ElectrumSV and multi-signature options.
You can read this article to learn more about how I am going to try and fit bare multisig wallets into ElectrumSV.
And as before, any additional development time that becomes available will proceed to work through the tasks that lay out the path to the first Paymail release.
This is loosely laid out in the following sequence of tasks:
- Issue #213: Move wallet storage to be completely sqlite-based.
- Issue #180: New ElectrumSV wallets should be created as multi-account wallets.
- Issue #181: Paymail integration.
- Issue #182: Multi-account UI polishing.
- Issue #184: Multi-account wallet restoration.
Beyond this, there are a large number of outstanding things we want to do that rely on both the complete move to database storage, and the refactoring so that the historical wallet becomes a parent wallet containing “multi-accounts”. I don’t have an official list, but this might include the following tasks some of which I have discussed with users recently.
New default coin management policy
Craig makes a good point that coins should be in smaller sized amounts, both for privacy and security. Think of the extreme that all your coins are in one lump, and as you pay, you split off the amount you are paying. This both links all your expenditure and makes one target for attack.
ElectrumSV should try and manage your coins in some default way where they are kept split for best practices privacy and security-wise.
Practical split coin tracking
We have no way to know without a tremendous amount of additional work, whether your Bitcoin SV coins are already split (from any attached Bitcoin Cash) when they arrive in your wallet.
At this time, coin-splitting is a blind operation. There is no visible way to see the coins you split earlier, and the coins that have subsequently arrived in your wallet.
What we can do practically, is colour the coins that you have split, so that we can identify those that are already split and indicate those we do not know to be split. Now you might be able to select the coin and split it explicitly, or even say “I know this is split mark it as coloured it for me”.
Track created transactions that have not been broadcast
This is just tracking different transactions you have created, and what you have done with them, and managing your interaction with them. At the moment we only track transactions that have been mined in a block! You create the transaction, you send it to the network and it’s gone. We have no record that you even used the coins that the transaction used! Excuse me for employing some vulgar parlance, but this is some basic shit we are lacking.
And so on..
The tasks above are not necessarily first in line. They’re just the first ones I thought of when I thought of things that are deferred until we have the database and multi-account refactoring done. There are many many more.
I will be considering writing one of these articles each month, from this point on, to give a picture of the progress and direction for ElectrumSV.
Summing up, the two focuses are:
- Do a stable release with bare multisig support.
- Proceed with ongoing work related to the eventual ElectrumSV 1.3 Paymail release.