ElectrumSV is based around a low-level representation of a wallet’s state. It shows a raw history of transactions, allowing a user to view and spend from individual addresses, or even specific UTXOs. But one thing that the need to support both bare multi-signature transactions and Paymail has highlighted, is that not everything has an address. This article will probably not have a resolution, but attempts to gather my current thoughts at time of writing in a solid form.
There are two goals with the articles I write, the first is to hopefully engage people in discussion and get feedback. And the second is to capture ideas as a kind of journal of notes. Due to the limited resources ElectrumSV has, it might be some time before I work on the things that the articles touch on — being able to come back and revise the nuances and exploration of ideas has some value.
If you have thoughts/feedback on this article, please get in touch via the #electrumsv channel on either unwriter’s slack or metanet.icu’s slack. You can add also comments here on this article, but it’s not the best forum for discussion. And you can also tweet, but I will actively avoid engaging there as it is a terrible forum for discussion.
Addresses and payments
So in the simplest case you want someone to pay you, but the way you want them to pay you does not have an address. What do you do? You give them an output script. This is the basic building block of Paymail. When someone asks for an address, they don’t get an address, instead they get a script. In the Paymail specification, this is titled “basic address resolution” but interestingly the capability is named “payment destination”. If it were up to me, I would drop the title and replace it with a variation of the capability name.
But this isn’t how it currently works, so let’s take a step back.
Why do we have addresses?
If you watched Steve Shadder’s presentation at Coingeek Seoul, he suggested that addresses should be abolished. He also suggested that they were a stopgap created because IP2IP was not available yet. Note that they were provided out of the box, by Craig, as one of the initial script templates. Now Craig also provided IP2IP out of the box, so I can’t quite back that stopgap rationale.
Bitcoin Core didn’t understand the IP2IP model, or perhaps even philosophically disagreed with it, and removed support for it. They also doubled down on addresses, and the payer broadcasting the transaction, and the payee monitoring the blockchain. To do this, they locked in approved script templates in the form of a rigid regime of approved standard scripts. Of course, these weren’t part of the consensus model, you could of course mine non-standard scripts. But really, this is the same as a consensus rule to any non-miner as the barrier to getting a miner to mine your scripts is so high, that in the real world standard scripts were effectively a protocol limitation.
Addresses are the most obvious way to move Bitcoin forward if you do not have Craig’s insight into the alternative IP2IP model. It’s easy to tell someone where to pay, just paste in the short sequence of characters. Ignore that it looks like line noise, and that you probably wouldn’t know if you pasted in the wrong address. Obfuscate it with a QR code, so you no longer see the line noise and it’s all good. And so P2SH becomes a thing, and sounds like a good idea. You can make everything an address, cementing the model in place doing more damage than good to Bitcoin as a whole.
I think it was inevitable that until someone pointed out how the IP2IP model can work, everything would be based on addresses as a building block. You can call them a stopgap, and they are, but only in hindsight knowing about the IP2IP alternative when you can also see that Bitcoin Core were blocking the evolution of Bitcoin, and stunting it’s growth. And similarly, applications and wallets had limited potential, and were also stunted. If you look at Electrum Core as a developer tool that allows low-level control of one’s wallet, then it makes sense. But as an intuitive tool that helps the user make safe choices, that should be employed by real people, not so much.
Is there a need to abolish addresses? As a wallet developer the mere existence of non-addressable payment destinations, from whatever a Paymail response might return after the Genesis update to the Bitcoin SV protocol, to any bare multi-signature payments in the meantime, means that addresses are now irrelevant. No-one can build a usable tool that focuses on addresses, and in fact I think it would be detrimental to do so. But they’ll still be around.
The future of ElectrumSV as I envision it, is the developer tool we still pretty much still are, but presented behind the facade of an intuitive tool that helps those real people using it make safe choices they understand. This of course depends on available development resources to get us there, and comes second to our primary goal of making sure that all historical coins are accessible. So don’t expect it any time soon, but hopefully I’ll get there in the end.
Returning to payment destinations in the form of scripts. I don’t need to go into this much, it gets complicated and even an output script might contain partial contributions from multiple parties post-Genesis update. The fact is that I have illustrated that balances are not necessarily in addressable locations, and while it might be possible to get balances for addresses, the lowest common denominator is unspent outputs. This is what ElectrumSV actually works with already, and an unspent output is a script, or payment destination.
ElectrumSV has two milestones currently in it’s roadmap:
- Bare multi-signature. This is intended to ensure we provide an alternative to the current P2SH form of multi-signature wallets that we currently support. As bare multi-signature wallets are non-addressable, this means that part of this work is refactoring ElectrumSV to work with non-addressable outputs. I touched on this in my article on bare multi-signature wallets.
- Paymail. The future of Bitcoin payments is payments between identities where addresses are never reused. And I would be surprised if anyone in the near future finds an identity solution that beats Paymail for being approachable and intuitive to real people. Any wallet that does not support it will get left behind. This will work to complete transitioning from any remaining support for addresses, as part of the first seen user experience.
Exactly how ElectrumSV will work internally as we move from addresses, I am not going to try and flesh out here, there’s other things I want to get down before I forget them. And I don’t expect there’s much variation possible on how we proceed with the implementation details.
Addresses and user needs
ElectrumSV allows users to do things with their coins that other wallets do not. It would be tempting to say, if you want to do this thing that is no longer supported, use one of our old versions. But it would be better if we could isolate needs and consider if we can handle them.
Whenever I have raised the subject of not supporting address reuse, some people pipe up and say they reuse addresses and it’ll affect them. As we transition to the IP2IP model, and Paymail becomes more and more pervasive I feel less and less inclination to support this. In fact, they should move to Paymail, and for instance, build on MoneyButton. I think there’s little excuse for not doing so at this point.
But can we completely abandon support for address reuse? Is it possible that someone will use a poorly developed tool and get accidental payments to a reused address, or payment destination. Yes, I think it’s almost guaranteed to happen to someone. What about a payee transitioning from having an address on their web site, and some laggard payer still has the address and lazily pays them. I’m not sure how it could happen, but I guess it could. Perhaps it’s a subscription service, and the user does not read the web site where the payment process changed or something along these lines. I am sure there are legitimate cases, or at the least arguably legitimate ones.
To me, I think we need to retain the ability to scan used addresses, even just specific known used addresses. But whoever is running the server which is looking up use of those addresses, or even transactions matching some payment destination, will most possibly charge you. And if you want to rescan all your addresses just to make sure there were no payments, this is probably going to be proportionally priced. In the shorter term while our servers are all based around address monitoring, and the legacy address-based Corean model, enjoy it while it lasts.
Addresses and privacy
People say that addresses add privacy. I don’t understand this, or the nuances of it if there are any. An address is a payment destination, expressible in a short concise standard form. It for the most part, either is a clipped form of a public key or P2SH script. If you spend an address, it is at that point linked to a public key (or public keys).
ElectrumSV never reuses public keys. All of it’s wallets are created as deterministic wallets that operate on a stream of addresses, offering the latest unused one for payments to be made to, or picking out new unused change addresses as needed. This is true for both P2PKH standard wallets, and P2SH composite multi-signature wallets. The P2PKH wallet has a linear stream of both receiving addresses and change addresses it can pick from, and the P2SH wallet creates an aggregate stream of addresses for the synchronised stream of receiving and change addresses it can generate on behalf of each participant.
You may argue that the user can opt to reuse addresses or payment destinations, even if ElectrumSV tries not to. But we have the idiom about “shitting where you’re eating” for a reason, and I think it applies here. If people choose to be sloppy about their privacy, then that’s always their choice.
Maybe there’s something I am missing here about addresses and privacy. Please let me know. I’m sure it’s obvious if you already know it.
In my opinion addresses are already mostly irrelevant in any user-visible sense, for any wallet that correctly and usefully manages a user’s funds. ElectrumSV has a way to go before it gets to that point though. The obvious exception is where whatever wallet a payee is using, needs to provide the payer’s wallet with a payment destination, in lieu of Paymail support.
As more and more wallets transition to Paymail, addresses will become more and more irrelevant. I think ElectrumSV supporting Paymail will accelerate this, as it is likely a significant reason existing applications and wallets that do support Paymail have to continue allowing payments to addresses.
I’m going to end this here. I need to do some more ElectrumSV architectural planning related to reorganisations, ascertaining what state the wallet will track going forward and how it will have to change to match what I describe above. This factors into the implementation for the bare multi-signature milestone.