I already explored what the path forward for multi-signature wallets in ElectrumSV is likely to be, and now I am going to go into the nuances of how we will likely do the “bare multisig” type of wallet.
Please speak up if I have gotten anything wrong, or have left something out. I am not a Bitcoin expert by any means.
- 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.
Variations on bare multi-signature wallets
When a payment is made to or from a bare multi-signature wallet, it involves inputs and outputs within transactions making use of public keys and signatures as specified in BIP11. That’s what a bare multisig transaction is, when it comes down to it.
So what are the variations?
Existing multisig wallets are created using multiple extended keys. This means that public keys for each can be generated for receiving and change payments, as needed. Remember an address is just a clipped hash of a public key. This is what we already do for address generation in normal bitcoin wallets, which we call a standard wallet in ElectrumSV.
What happens when you create a P2SH multi-sig in ElectrumSV, is that you create a new master private key for your part in the wallet, then you enter the extended public keys (xpubs) for all the other participants. And you (and all other participants) have a wallet that can generate the public key for each participant when needed, to create a new payment to that wallet. And because the P2SH is a payment to a script hash — this implicitly provides a short address you can give out to non-participants.
But a BIP11 bare multisig output script has no hash, it is the raw list of public keys of each participant in the multi-signature wallet that are being paid to. Unlike standard wallets, unlike P2SH wallets, there is no short address you can give out. But we do have unique change addresses and receiving addresses that we can use for the wallet for each participant — the problem is that without the short address it becomes hard if not impossible to tell someone where to pay.
A special case is when a user has one payment which they have their private key and the other public keys for. This is one BIP11 payment, or one payment in a deterministic wallet, and it should be possible to make one or to create a wallet that allows access to an existing one.
The usual disclaimers apply that the biggest hurdle for ElectrumSV is the lack of manpower. Any work planned factors in, that at this time, I am the primary if not only programmer working on it.
Deterministic bare multsig wallets
This is mostly a modified version of the P2SH wallet code that we already have. It has per-participant deterministic keys, just not per-payment addresses, which is a problem that extends out through the user interface.
We know how someone pays to an address, but wallets do not have any way in the existing paradigm for users to take a bare multisig output script and pay to it. You can’t paste them in place of addresses.
Let’s be clear. This is a solved problem, it’s just not solved now in a form we can include in our stable branch. That’s because it comes back to Paymail, which specifies payments should go to scripts — not addresses. This means that it is completely transparent to you if someone asks you to pay to an address (which may be a P2PKH script, or a P2PK script) or a multi-signature script (which may be bare multisig, or it may even be P2SH for as long as that lasts). So that’s the eventual path forward in the development branch, that will in theory just generically plug in and make bare multisig payments work.
Which brings us back to our stable branch (the 1.2.x line of versions). If we want to support future proof multisig payments, we need some interim solution because Paymail support will never be in the stable branch. So what to do? What is the scope of the work needed to make this work? Is it doable, or does it require deferring bare multisig to the development branch post-Paymail?
If I had to guess at the steps to get there, it’d resemble something like this.
- Refactor a similar version of the P2SH wallet/keystore for the bare multisig case. It will instead of generating P2SH output scripts, generate bare multisig output scripts.
- Refactor the address generation concept to be payment script generation, for all wallet types, with the option to extract an address (or public key) where appropriate.
- Allow copying of payment scripts in a form that ElectrumSV can parse from anywhere addresses are input. The key goal is that we do not aim for inter-wallet payments, just ElectrumSV payments for bare multisig. If anyone is wanting to pay to a bare multisig wallet, they will need (until we support Paymail) to use ElectrumSV to do so.
- Now payment scripts can be copied and pasted, some of which will be addresses and some of which will be long hex or something for bare multisig. We can make a long base58 format with a custom prefix, if necessary.
- QED? I don’t know. Is this the best approach?
Static bare multisig wallets
This is such a narrow case that it will go on the backlog. It’d be nice to support it, but no-one is asking for it, and to do it anytime soon, and as anything other than a luxury feature, is wasting precious time.
That’s it for now. I feel like the above (deterministic bare multisig) should be pretty doable, and can be placed before continuing the Paymail work.