This post originally appeared on Medium, and we republished with permission from Roger Taylor. Read the full piece here.
When Paymail was broached at the first wallet workshop, it seemed like a good idea. I went away and wrote a Paymail hosting service for ElectrumSV’s users, implemented a contact system for Paymail addresses, the required user interfaces and more. ElectrumSV was probably going to be the first wallet to support Paymail, all that was required was for the patents to be granted and Paymail to be announced.
You might be aware that near on four years later ElectrumSV somehow still has no support for Paymail. So, why is this and what do I think about Paymail? I’ll try and describe my thoughts on Paymail below, but keep in mind I am not a Bitcoin expert, or an expert in anything for that matter. Maybe I am completely wrong!
Some of the problems
Sometimes you need to work on something and see how it lays out, before you realise you have problems. This was the case with Paymail. I didn’t realise that I wasn’t happy with including it into ElectrumSV until I had implemented it and considered how I (and any other user) would use it.
Meet the new boss, same as the old boss
What Paymail at the surface level seems to provide, is a way for an identity to be hosted on your behalf. In theory anyone can run their own servers and host their own Paymail addresses, but the modern services 99% of people rely on show that this is both prohibitively complicated and not a viable proposition. The core businesses that provide the services (Google, Facebook, etc.) sometimes end up being the only options for “identity,” although most but not all websites still support email-based sign-up which is pretty much a different form of the same thing. After all your email address is going to be at one of the same places even if you log in with email rather than linking your account!
Paymail is a way for a business to say, you are my customer and this is the way that others interact with you on my business platform. It is unclear what value it could add in the peer to peer world, where the user controls their own data, keys and coins. It is not an identity, but an account at that business and one that is is advertised by showing use of unfiltered unsolicited payments in an unsecured way.
Paymail is … an account at that business and one that is is advertised by showing use of unfiltered unsolicited payments in an unsecured way.
Paymail is more akin to a postal service than a bank account. You are not directly paying the person the Paymail address represents, you are paying through the service that is hosting that address and maybe paying that person. Or worse you are paying a hacker who has been waiting for large payments to come through—keep in mind that even Apple and Microsoft which are huge multinational corporations get hacked. The hacker can sit there waiting and then pick off selected payments and the hosting service or wallet might take a while to work out what is going on. They’d probably be more likely to blame the sender not sending the payment than detect the hacker, until a large amount of damage is done.
A wallet that supports payment to Paymail addresses should inform the user that a payment to “[email protected]” is not guaranteed to reach “Bob” and they send at their own risk. It’s what I was going to do. If they do not warn the user then either they are choosing not to do so to avoid the unpalatable sheen it gives Paymail, or they are not technically skilled enough to realise this is the case. Whichever the reason is, that wallet might find themselves liable by the paying user whose payment did not go where the wallet said it would.
If you are a Paymail hosting business and you host “[email protected]” and you are hacked and a payment goes missing, your best bet is to deny you were hacked or that the payment ever reached your service. In fact, you might even think that that is what happened. However, if it is proven because the paying wallet keeps records and receipts of some sufficient form (assuming this is even possible), then you may be liable for the loss.
I’ve never heard anyone say they think twice when they send a large payment using Paymail. That they have ever actually thought to ask their wallet how large a payment is safe with Paymail. Whether it will reach the intended recipient and what the wallet will do if the recipient claims never to receive it. But these are critical details we should all know about wallets that send or receive our payments.
The design of Paymail is structured around being able to send anyone you want money whenever you want. This is a terrible idea! If someone deposits money into your bank account and you did not expect it and do not know who it comes from, you do not touch it. You certainly do not spend it unless you are an idiot, because chances are their bank will talk to your bank and remove the money from your account. Any unsolicited payment you receive should be quarantined until you know it is safe to spend. If you are sending people money, you double check you have the right bank account number it is not a casual thing.
This is even worse with BTC. People send you dust in order to tag your funds and identify where your payments go. You do not want to just include that in your available funds and spend it. Even worse still, are tainted coins. Maybe someone sends you some stolen coins and you unsuspectingly mix those into your own coins. Maybe someone sends you some coins that have gone through a mixer. There are all sorts of ways, some I am not smart enough to think of, where this could be abused.
I believe that unsolicited payments is a short term thing that seems cool, but has no longer term benefits.
No one asks if Paymail is adding anything or whether it just limits us and prevents us from using better solutions. This is the first thing we should ask about Paymail before we adopt it.
Isn’t a Paymail address like email but better?
No. Email is already broken. We do not run our own email servers because it is hard and complicated. So we find ourselves in the situation where we let companies host our email and eventually we hear about people who lost access to their email address. I have vague recollections where at the first wallet workshop where Paymail was formalised, someone might have mentioned something like “Wouldn’t it be cool if Gmail supported it?” I now say it would not be cool. Imagine all your payments going to an address you no longer controlled, in much the same ways as you use that email account you can no longer access to regain access to other services which use that email account to gate-keep access.
It was also suggested at the first wallet workshop that users could host their own Paymail servers. I pointed out that no, they could not, it had been tried and people just do not have the inclination to do so. This had already been tried with OpenID where users were supposed to run their own web server to host their own identity and what happened was exactly what we saw with email, user identity centralised onto Facebook, Twitter, Google and other popular services.
Email addresses are already problematic without the link to Bitcoin, and based on the nightmares we hear about emails it is very likely tying payments to email addresses is a bad idea.
Isn’t a Paymail address just like a bank account?
No. It was suggested to me that there were modern services where you could pay to an email address, there’s even some company in the USA where they do it. You are not paying to an email address, you are paying to an account associated with that email address at some registered banking business. There are safeguards and laws that protect you as a user, either limiting liability or forcing the company to perform in certain ways to protect you. There is nothing bank-like or bank-account-like about Paymail addresses, or the businesses that host them.
We accept banks and similar licensed businesses as part of society that law knows how to deal with and that we trust. A company that runs a Paymail server is outside of that. A Paymail address is nothing like a bank account.
Without Paymail how would we do it?
This is the key question. And if there is a valid use for Paymail we would benefit from looking at all the use cases and examining whether Paymail adds anything, is required at all and whether it just complicates things.
Bob and Alice are in a restaurant. They finish their meal and then the server comes to them for a payment.
Bob and Alice get the server to split the bill and pay individually. The server holds out the restaurant’s tablet to Alice, who waves her phone over it and it contactlessly pays her portion. Bob does the same. In this case at no point is there a reason to exchange Paymail addresses, and injecting Paymail addresses into the process only serves to weirdly complicate things. The tablet likely offers a customised invoicing process to Alice’s phone, and a customised invoicing process to Bob’s phone and collects both payments to satisfy the bill.
Bob and Alice are in a restaurant. They finish their meal and then the server comes to them for a payment.
Alice pays for the whole meal and Bob plans to pay Alice back as he has forgotten his phone or the battery is dead. Bob has Alice in his contacts because they have a personal or professional relationship of some sort, and directly sends a payment to Alice. It is likely Alice has a peer channel open designated for contact with Bob, which allows her to receive payments whether her payment device is online or not, and pre-agreed upon templates for payment which were exchanged as part of setting up the relationship.
Bob and Alice meet and decide to exchange contact details. They tap on the button on their screen, and then hold their phone out. Their phones exchange contact information. Alice knows that the entry that says “Bob” actually identifies Bob, because of the exchange. That it can be used to securely contact Bob, or perhaps even pay Bob if that ability was exchanged. Similarly Bob knows the same of Alice. And any interaction will be associated with the imported contact identity.
While it is not required, additional security can be added by a user having their identity information signed by an authority. Let’s say Tokenized offer an identity oracle, and sign Alice’s information. Then on Bob’s device given he and it recognise the trustworthiness of Tokenized’s oracle, he sees a green checkmark beside Alice’s identity. This supplements Bob’s personal knowledge that he obtained Alice’s contact information directly from her.
Carol knows Alice, and either Bob wants to get in contact with Alice or Alice wants Bob to get in contact with her. So Carol holds her phone out to Bob and shares Alice’s contact information. It might be that this is a permission Alice has to grant Carol in some way and that just because Carol has Alice’s contact information, she has no way to share it otherwise.
Alice can email something to Bob — or IM or any other method of communication to existing contact points. It might be a link that Bob clicks on that opens his desktop wallet. It might be a QR code that he scans into his mobile phone. It could be anything. This can give him access to contacting Alice, or even be her contact information tailored to him.
When you sign into a service, why do you have to say I am “[email protected]”? Why can’t you present an attestation from an identity oracle that gives the service the minimum information necessary (you can insert other P2P friendly mechanisms here) and just click register or login. If you think about having to provide a Paymail address to log in, all the Paymail address does is tie your usage of one service to your usage of another service. That does not benefit you, it benefits the two services.
All you should have to tell the service you are signing up to, is that you are a unique individual who can with some legal action against the identity oracle be held accountable. The service may ask for identifying information like your real name or KYC data, and if you think it is worth it, you can grant it access to a further attestation from the identity oracle. They might not even need access to the KYC data, but rather just the verification from an oracle they trust that the conditions are fulfilled.
Other use cases
There are many ways that external verification can be given to the correctness of the exchanged contact information — a known and trusted identity oracle can likely provide private proof for Bob from Alice using Bitcoin signatures. Or the root certificates we use in our browsers can be used to sign documents, so you can see a checkmark from “trustedoracle.com.”
Maybe Paymail is the best thing to happen to Bitcoin SV. Maybe the people who suggest we should feature it front and center are right. But we should at least examine whether it is a wrong path. There is no-one asking why are we using Paymail and what does it really add! If I were adopting a technology as the core of my business, investing money, I would want to be able to at least see that discussion and where the detractors had the flaws in the arguments pointed out to them.
You might ask, why am I only posting about this after four years. Because discussion is unwelcome, and it is labelled as negative and even insulting to question Paymail. And to be fair it is in a sense. You do not enter someone’s house where they only eat vegetables and introduce meat, it’s just rude. But it means that the real benefits of Paymail have never been identified to me, rather I get told discussion is unwelcome and I can leave if I do not just agree with whatever is being proposed.
We should at least look at what the model of using Bitcoin SV would look like without Paymail, and whether Paymail makes it better or just complicates and limits things. Whether there are fixed identifiable use cases where Paymail is the right approach and when it is not. Where is that discussion? I have concerns and they are unfortunately negative, I’ll sit over here and shut up and not rock the boat.
Watch: The BSV Global Blockchain Convention panel, Re-Inventing Business with Blockchain
Editor’s note: This has been slightly edited for clarity.
New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.