Direct payments solve a lot of problems, but what is the wider picture? What problems and solutions are needed to cover all the situations where they might be made? For that matter, what are all those situations, or at least what those I can identify? What do we need to do to get to the point where we can support direct payments in ElectrumSV?
This article isn’t intended to provide a correct model of the cases where direct payments may be made, it’s intended to provide a starting point for discussion. If you can help flesh out the model, then please get in touch. Methods of contact are provided at the end of this article.
What are the use cases?
The following should be a list of the situations where one party wants to make a payment to another party.
The two parties are in close proximity to each other, standing next to each other would be a precise example of this. In this situation, alternative methods of communication that do not involve the internet, are available. Let’s try and work out if they are suitable for our needs.
In most cases, this is likely an option that would suit two people standing around with wallets on their mobile phones. Perhaps we might use it to allow someone with a mobile phone to interact with desktop instance of ElectrumSV.
But can Bluetooth even be used for payments between two people? Or is it more suited for linking a pair of headphones to whatever device you have your music playing on?
Assumption: Bluetooth is not relevant for general payment negotiation.
As long as ElectrumSV does not have any mobile wallet, it is unlikely that it is worth us spending time on letting the desktop interact over NFC. For one thing, chances are that desktops do not have NFC support.
If ElectrumSV as a desktop application, did support negotiating payments over NFC, it’d need some form of NFC reader and to support that. That’s more an advanced merchant solution and not a general solution for all users.
Assumption: NFC is not relevant for general payment negotiation.
Local area network
If you’re sitting beside someone who is also on that WiFi network, then can you both communicate with each other using your address local to that WiFi network? If you’re both on WiFi anyway, it might even be the simplest way. But how viable is it to make use of it in this way, outside of home WiFi?
On an non-public business network, or a home network, it’s likely that this is possible. But on a public network, it makes little sense. I don’t know that it is possible, but I would lean towards it not being possible.
Assumption: When sharing the contact information as a contactee, we could optionally share the LAN address in addition to other addresses and let the contacter use it if it makes sense to do so in the context of the others.
Assumption: If the two parties can’t connect over the local area network itself, then we should assume they connect in a way that suits remote communication.
The two parties are not able to stand next to each other, and are perhaps not even in the same room, or even the same country. In this situation, the sole method of communication between the parties should be over the internet. And this will also actually apply even when they are in the same room, and standing beside each other. We may as well just go straight to this case for all cases, for ElectrumSV.
So let’s look at our remote use case.
In an ideal world one of the two parties is going to connect to the other party. This implicitly requires that they were able to obtain a current address for that other party, and also that the address routes the connection to that other party. At the least one of the parties needs to be externally accessible via “the internet”, and a party who isn’t externally accessible can initiate the connection.
If this was an ideal world, then IPv6 would be supported everywhere and every computer would have an internet address at which it could be connected to.
But the world we live in, is not the ideal world, and so IPv6 is not supported everywhere, and instead people use IPv4 on a network where they may not have an externally accessible address. So we should take advantage of direct connections between two parties, if it is an option. But when it isn’t, then we should fall back to an option that always works.
So in order to provide a service that always works, we need to provide accessible servers which can act as an intermediary. This solves the case where neither party can connect to the other, and pretty much appears to just work for all parties. This is not to say we put open relays on the network, far from it, just that the servers that ElectrumSV inherently relies on to make the wallet experience possible, get extended to support this for registered users.
The current servers
At this point, from the perspective of ElectrumSV, this is the only solution that works. We already have wallet server software (called electrumx) that runs on public servers for our users, run by community members at no cost to the user, that do the following:
- They provide us with the header when a new block is mined.
- They provide us with notification that payments within transactions arrive on our addresses.
- They provide us with transactions and the merkle proofs for those transactions, so that the transactions can be verified based on proof of work.
Current expectations of future needs
We’ve seen the recent news that it is becoming more and more expensive to run a node, and it is a given that going into the future our users are going to have to pay to use the servers that ElectrumSV requires access to, to be able to operate.
The ecosystem is also going to be moving to a user to user payment model, where the payer and payee will negotiate and the payer will provide the payee with the transactions and it is up to the payee to broadcast it to the network. The future is safe instant payments through this model. Pretty much all wallets are on-board with this, it’s just a matter of time.
The current ElectrumSV model is to watch addresses. It might very well be that given the direct payments, even aided by our servers to connect and even communicate, that this becomes only nominally used and this part of the API becomes less commonly used for day to day wallet operation.
Paying for server access
Above I came to the conclusion that in order to provide the universal ability for our users to connect to each other, we would always need at least the ability for users to use third party internet accessible online services to facilitate that connection. We already plan to monetise our servers so that the people who operate it can at least subsidise their expenses, but we also believe that these servers have a lot of leeway to expand and offer optional additional services for a variety of purposes. And not just for ElectrumSV, for any wallet who wants to do away with having to run their own node.
Monetisation isn’t just for making running the servers worthwhile, it’s also a way to add value to the services it offers. More and more people are seeing that free lowers the incentives that create quality.
The simplest way to monetise the node is to paymail enable it. It doesn’t have to become a paymail host for others, but it could become a paymail host for itself and negotiate it’s own payments. Then it can purely deal with payments through the paymail model, and can charge known identities instead of taking random payments.
Let’s keep some perspective. Users will always be able to create a new wallet in ElectrumSV and not have to pay to use the servers. Servers will have to provide a basic level of free usage, with a sensible model for putting value on services. Not doing so, compromises the user experience for ElectrumSV — or any wallet that depends on it.
For all those who suggest we should put an ad banner in the wallet and be done with it, you’re proposing a solution that does not address any known problem. We do not run all the servers that our users use, and that is where the cost is. If you ever see an ad banner in ElectrumSV, reformat your computer and reinstall everything except for the malware you just installed.
Assumption: Anyone who creates an application, whether a wallet, or something more general, should not need to run a node. They should have general services they can use, accessible via an API. And if you want to use a basic hobbiest cryptocurrency that is free to use, but doesn’t do anything interesting, it isn’t going to be Bitcoin SV.
How users might connect via the servers
Two users whether standing side by side, or talking on instant messaging or exchanging emails, just have to go “What’s your paymail address?” They each enter it in ElectrumSV, and ElectrumSV retrieves the relevant public keys somehow and employs some protocol to send the contact details (IP addresses of whatever form) of each user to the server.
The simplest way to do it is to have the server act as a messaging service for users. Then the ElectrumSV client can just send specifically encoded packets through that, and each user’s wallet can coordinate the exchange of relevant data to the direct payment. Exchanging IP addresses, technical ability of the relevant devices, whatever. And then the wallets can coordinate who tries what, and what would work, between each other.
For those who ask “are these messages encrypted?” Did you think before you asked? All messages would be encrypted, it makes no sense not to encrypt them. Perhaps you’re not aware how easy it is to encrypt things in Bitcoin, let alone create new encryption keys for every message with another party?
Assumption: The servers Electrum uses are going to get user accounts based on Paymail or Paymail-style identities and this is going to be used to provide lots of exciting stuff, that allows lots of useful and interesting things to be done — things that are not possible on free basic hobbiest cryptocurrencies — but are on Bitcoin SV.
Payments without servers
So we’ve covered the various ways payments might be made, and pretty much come to the conclusion that using our servers to coordinate communication does two immensely valuable things that are otherwise hard:
- Allows two users to establish communication.
- Allows two users who directly communication, to do so reliably.
But that does not mean that we won’t support other direct options that do not involve making use of a server that implements our API. We’re an open source wallet, we have limited development time to work on all the fancy “wouldn’t it be cool” features and have to concentrate on what just works for the majority of our users. This means that you can step in and work with us to support the direct methods of communication. Or you can fund someone to do it, perhaps by doing a public funding thing.
This might include:
- Working out how a desktop wallet might operate as a NFC-based merchant payments solution. Are there NFC USB dongles?
- Working out user friendly UI and protocols for detecting ability to directly connect over local or internet IPv4 or IPv6 addresses. And how the two wallets tell each other their addresses to begin with, so that they can know where to connect.
You get the picture.
Also a word to the wise, if a word is used in the context of Bitcoin and it has a suffix of “less”, it’s probably bullshit. mpapec on the Metanet ICU Slack recently aptly pointed out that “serverless” in the context where it’s normally used, generally means “using someone else’s server”. Let’s not even get started on “permissionless” 😃
Using the blockchain for communication
You might think that one alternative to us using the servers in this way, is users publishing transactions to the blockchain, and getting 0-conf notifications in order to coordinate communication. One problem with this is that it is a regression back to monitoring the blockchain, rather than making direct payments and avoiding that. I’m not that interested in this as a solution, and would be reticent to allow support for it to be merged into ElectrumSV.
The offline edge case
Users are going to find themselves in the situation where they are without an internet connection, or cannot be bothered to gain access to the internet. We will handle this case in some user friendly way, but it is an exception to the rule, and warrants special handling.
Do our servers need to support Paymail to monetise?
No. But it is one option. And one that builds on the best identity standard. They may not even need to self-host Paymail to accept payments. Who knows, there’s a lot of room for how this might play out.
As always you can contact us in the #electrumsv channel on either of Unwriter’s slack, or the Metanet ICU slack (if you are a member with access). Twitter is a painful platform to use for discussion, so do not expect any discussion initiated there.