This article is intended to evaluate the path forward for multi-signature wallets in ElectrumSV. Another article follows this on the specific subject of bare multi-signature wallets.

The best desktop wallet for Bitcoin SV.

Useful links:

Find our website here, where you can get the new 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.

The current situation

There are two types of multi-signature (multisig) wallets, one is called “bare multisig” as described in BIP11. The other is called “Pay to script hash” (or P2SH) as described in BIP16 (general P2SH), BIP67 (predictable P2SH multi-sig addresses) and who knows where else 😉.

ElectrumSV only supports P2SH multisig wallets, but what does that mean?

Existing wallet support

Keep in mind we do not need to run bitcoin scripts for the transactions in your wallet. This means that if any type of wallet receives any kind of transaction, multisig or not, we can still factor in the increase or decrease in your wallet balance. It does not matter what the script does.

The current releases of ElectrumSV have a limited set of types of wallets that can be created:

Standard (Electrum mnemonics). This is deterministic, so can generate new addresses for sending and receiving as needed.

Standard (BIP39 mnemonics). This is deterministic, so can generate new addresses for sending and receiving as needed.

Multi-signature (P2SH scripts). This is deterministic, so can generate new addresses for sending and receiving as needed.

Address or public key watching. This is read only, and cannot spend funds.

Specific private key usage. This is non-deterministic, so no new addresses can be generated for receiving funds or sending change to.

As you can see, we do not currently support users creating or using a bare multisig wallet.

The P2SH situation

P2SH is considered to be an ill-conceived addition to Bitcoin. Because of this, it is being sunsetted, which means that no new coins may be sent to P2SH addresses after the date of sunsetting. As Bitcoin SV believes in stability and maintaining access to existing coins, any that are in P2SH addresses will be spendable going forward.

So if P2SH is broken, why is it the multisig solution that ElectrumSV uses? Because unlike bare multisig, it provides addresses that can be sent to — much like normal addresses in standard wallets. And new addresses can be generated for both receiving and change, by any user or entity who is participating in the multisig wallet.

This means it fits cleanly into the existing user interface and works the same as standard wallets, and has the same level of use and flexibility (beyond the signing requirements and signing operations) as standard wallets.

The bare multisig situation

If I were to say why we do not have bare multisig support, I would say that from our perspective we do not have it because Electrum Core does not have it.

A bare multisig wallet is non-deterministic, that means it cannot generate new addresses to receive funds or send unspent change back to itself. It makes a lot of sense that Electrum Core went with P2SH, given the superior wallet experience it provided.

Possible paths forward

The key thing holding ElectrumSV back is lack of manpower.

Neil (Kyuupichan), as the other main developer, is focusing on making ElectrumX a workable solution for both a bigger block future, and a future where ElectrumSV has a need to do more than just simple address monitoring for the wallets that rely on it.

Myself, I am focusing on the wallet refactoring that is intended to allow it to support multi-account wallets and Paymail as the initial usage of that.

Any choice that requires additional complicated work, detracts from my ability to progress towards Paymail.

Disabling P2SH wallets

After some discussion with Kyuupichan, I was initially inclined to disable creation of new P2SH wallets. I think this is a solution that has merits, but as I have mulled on it, I find myself hesitant to do it without a replacement method of multisig for our users.

We can modify the P2SH multisig experience, both for new wallet creation and existing wallet operation, to highlight the sunsetting. I expect we can do it in a way that does not add yet another popup confirmation dialog that users can either choose to be reminded of, or can choose not to see again.

So, let’s assume that in the stable 1.2 branch we continue to allow P2SH wallet creation indefinitely. When I know the date P2SH outputs will no longer be standard, we can then disable new P2SH wallet creation and can activate that at the correct time.

Bare multisig

ElectrumSV has a philosophy of supporting a wide variety of things, and allowing users access to things that are not supported elsewhere. There is of course a limit to this philosophy, because as we add support for things the technical debt and time requirements of wallet maintenance and testing increases.

But I am coming to think we need to support bare multisig. It is entirely possible there are users who have these wallets who want a way to spend the funds in them. Making those funds accessible is a win.

It’ll require a non-trivial amount of work on the wallet internals and UI to make them usable in a moderately user friendly manner — given inability to retain change and a lack of addresses. But let’s face it, ElectrumSV 1.x maintains for the most part it’s legacy approach to usability which expects a certain level of pro-activity and responsibility on the user’s part. We don’t need to go overboard here in terms of making a completely new UI. This should be doable.

Threshold signatures

I haven’t looked into threshold signatures, but I should. Kyuupichan has a longer history of Bitcoin development than I, and knows a lot more. And what he indicates to me is that the real work is in the coordination between signers. But otherwise, the output script should be a P2PKH output script, and the experience and operation from a UI experience should be much like that of the current P2SH multisig wallets.

Final thoughts

This leaves me with the following plan:

Roughly prototype bare multisig wallet creation and restoration. This should aim to get a working prototype in the stable branch, with the goal of having an idea of the final time requirements for making a polished prototype. Unless there are unforeseen problems, polish bare multisig wallet creation and restoration. Including addition of strong suggestions that this should be preferred over P2SH multisig wallets. If we decide to retain P2SH until it is no longer viable, even with the presence of the bare multisig alternative, add strong warnings to P2SH wallet creation about the sunsetting and a time-activated deactivation of P2SH wallet creation. Research threshold signature wallets and discuss them with the appropriate people to develop a clear picture of what is involved in adding support for them. Continue multi-account work and Paymail support while doing this.

There’s a lot to be done. If you’re interested in helping out with ElectrumSV development, please get in touch. There are lots of tasks that provide valuable experience to anyone who wants to pad out their resume with either work on a well known Bitcoin application or functionality that works directly with the Bitcoin protocol.

Continue reading the next article on bare multi-signature wallets. ▶▶

Contact us

Once again, if you do wish to get in contact, to either discuss anything in this article, or even to get involved in ElectrumSV development, you can do so in the following locations: