Notes on Paymail verification

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 either unwriter’s slack or metanet.icu’s slack. You can add 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.

Paymail and ElectrumSV

I like Paymail. Email as an identity is a superior approach to anything I saw suggested before Paymail, anything I have seen suggested since. The only reason ElectrumSV does not currently support Paymail, is that we have limited resources, and in order to support Paymail we have had to first improve our source code so that we can.

Something I have mentioned before, is that the other wallets who were present at the workshop where consensus on adopting Paymail as a common solution was obtained, are all hosted services. ElectrumSV is not a hosted service, and while it would benefit both us and our users to be one, we simply do not have the resources to provide one.

The question is how best to fit Paymail into ElectrumSV. At this time, I can only loosely capture some ideas, like the ones you will read in this article. My suspicion is that we will only really know how ElectrumSV can make best use of it, beyond basic address resolution, when we have it working.

Trusting Paymail hosts

One of the key problems with Paymail is that you have to trust the host is not compromised. That the addresses it gives you are actually linked to the given identity. Now for hosts like HandCash, MoneyButton or Simply Cash, you can take this for granted, but we’re not going to be dealing with just those hosts. And even if we are dealing with those hosts, then why shouldn’t we do better for our users if we can?

What I’ve always wanted since that first wallet workshop when Paymail was announced, is a way to verify that the address that a Paymail host gives you, actually belongs to the identity that that host hosts. I did mention this to a few people and got either lack of interest, or was pooh-poohed, but other people also have limited resources and have to focus on the things that are relevant to them.

Is it possible for ElectrumSV to verify addresses obtained via Paymail in a usable way? Yes, I think it is, and I think I can lay it out at least at a conceptual level in this article.

The de facto approach

The standard way that a Paymail host will provide your addresses, is through you giving it an extended public key (xpub)— which allows deterministic generation of the addresses that your extended private key also generates, without requiring access to the corresponding private keys that map to the generated public keys.

Paymail does not strictly proscribe that hosted identities provide basic address resolution through xpub derived addresses, but it effectively makes it the de facto approach because it is the only existing standard way in which address generation can be done. By not defining a better alternative in the Paymail specification, it makes it much harder to use anything else. Any decent wallet already handles extended public and private keys, and as a concept it can just be plugged into Paymail.

Note that currently there are no Paymail hosting services, just wallet services that expose their hosted wallets through Paymail. What these services do for their users, is not what we are talking about here. We’re talking about an ElectrumSV user being able to engage a third party Paymail host, to provide addresses on their behalf. And further we want the added ability for that user when they are requesting addresses, to evaluate whether the addresses are both correct, and how secure the service is.

Exploring an alternative

I envision a layered system. In the worst case that we do not actively advocate the user avoid, we can obtain and use the unverified addresses from a wallet service’s Paymail host. However, if a Paymail host supports the verifiable address extension, then we can instead opt to obtain addresses from that, and then verify them. There are nuances to the process, but I feel like it should be possible to define the edge cases and outline at least a proposal to consider.

The layered system

There’s nuances to the system, but the highest level layers are a follows:

  1. Does the Paymail host support the verification extension?
  2. If not, fetch an address using the basic address resolution approach, and indicate that it is unverified.
  3. Otherwise, fetch an address using the verification extension, verify it and either indicate that it is trustworthy or that verification failed.

A key part to the system is how ElectrumSV indicates a recommended level of trust for both a contact’s Paymail host, and any addresses generated for them.

Indicating trust

Let’s say that you are looking at your list of contacts, and amongst them you have a Paymail contact for chuck@example.com.

Contacts

ElectrumSV examines example.com and finds it lacks DNSSEC. So it now displays a warning sign beside that contact. Kind of like how a web browser indicates problems with the certificate of a web site.

Image for post
Looks good.
Image for post
Use at own risk.
Image for post
Use at own risk if you’ve got more money than sense.

Now we’re using DNSSEC here as a prerequisite for the ideal level of security, because ideally hosts should have be able to have it configured. But it may be there are a range of things that are “warning” level yellow, rather than “avoid” level red.

The indications in and of themselves are rather useless without context, so much like a browser allows, the user could perhaps mouse over or click on the warning icon to see a breakdown of clearly described problems with links to further context if the user desired to read more. Additionally, we might show confirmation dialogs if the user chooses to proceed.

Payments

Let’s say that a Paymail host appears legit, and perhaps it is even a well known wallet service. And better still, it supports the verified address Paymail extension. But unfortunately, the address it provides obtained through that extension fails verification. This would be “avoid” level red. And it would be strongly discouraged through both visual indication and confirmation dialogs.

ElectrumSV does not prevent our users from doing things they probably shouldn’t. We would still allow them to send money to one of these addresses, but we would make it obvious that this was a bad idea. At the end of the day, curating a wallet experience that only allows users to perform actions we approve both creates extra work for us, and limits users from doing things they might sometimes have the need to do.

A loose verification extension

Keep in mind this is part of a layered system.

The key assumption I make is that in order for a payer to be able to verify that addresses they obtain from a Paymail host belong to the payee with the given identity, is for the payer to be able to generate the addresses themselves. The obvious question is why we would request addresses from a Paymail host, if we can generate them ourselves. That question is only relevant if you apply it to this part of the system, I might address it later in the article, but I expect the question to become less important as the system is further explored.

Let’s start with looking at how this would have to work, if we based it on extended public keys. The only way for a payer to be able to generate the addresses is for them to also have that extended public key — it’d have to be attached to the contact entry for that payee. But the extended public key is a linear source of addresses used for addresses for all requesting payees, and the payer would have to search that linear path and how would it know how far it has to look? And that path is a source of addresses for all requesting payees — possession of that extended public key is the ability to monitor all payments to that payee. This is just unworkable. I’m fairly sure it was also suggested as one pre-Paymail identity solution.

What’s the alternative? Craig’s whitepaper #42. If you’re talking about address generation and you’re not considering it, or don’t know how it works, then on the balance of probabilities your suggestion should be ignored outright. I was pleased to hear Brendan Lee bringing it into the picture, in his Coingeek Seoul talk. As Brendan points out, all you need is the identity public key of a payee, and from that a payer can generate a unique stream of addresses for that payee. I feel obliged to mention that if the payer and payee each have the other party’s public key, they cannot use this technique privately — to do that requires a shared secret. And for this, and for many other things, the presence of a Paymail host representing the identity is invaluable in coordinating the connection between two contacts.

The Paymail host that supports the verifiable address extension, at the very least can provide the public key for the payee if the payer does not already have it. This reduces the known level of trust, and ideally the payer might obtain that public key as part of a packaged identity from a second source, and we’d indicate the trust issue, but it’s not a deal breaker. The payer needs it, and it’s their decision as a grown adult to take that leap.

With the payer having the payee’s public key, and the Paymail host having access to their own public key, both parties need to know the shared secret used to communicate. The Paymail host would generate a shared secret on behalf of both parties, and would keep track of those shared secrets. For generation of addresses between those two parties, it would use a deterministic process to generate a sequence of addresses. The simplest way to generate a shared secret, is to just generate a fresh random number for them. In this scenario, the Paymail host would make available to the payee all the addresses, perhaps public keys, and shared secrets of all involved payers. Their wallet might sync these occasionally.

So now the payer and payee know about each other, and they can generate a mutual sequence of addresses. They can ask for one from the Paymail extension and verify it is correct. And I think this is a workable foundation to build a verifiable address extension on. There are a tremendous amount of other possibilities if you consider the Paymail host to be a mailbox for the identity, where the messages can be easily encrypted in a way where the host never knows what is in them. And whitepaper 42 allows the two users with public keys to completely bypass the host in creating additional address streams in addition to the payment addresses the host knows about.

Pointing out some things that you likely already thought of:

  • The Paymail host does not have to generate a random number for the shared secret, the payee who has a hosted identity with them could provide a way for them to generate a shared secret perhaps as part of a deterministic sequence that they can monitor without needing to poll the host — perhaps some other way with other more useful benefits.
  • If contact has been made and the shared secret exchanged, the Paymail host could be excluded and further communication made through use of a deterministic sequence of addresses. Monitoring addresses as a core technique is a regression. We want to avoid doing it, although we can do it as part of the layered system in special cases or as a fall back. But we are building on Paymail, if a host supports message posting to the hosted payee, then it should provide a more private direct channel for communication which is implicitly more preferable.

Final thoughts

It might be argued that from our perspective the most valuable parts of Paymail are that it represents the user as a service on the internet in an intuitive way that cannot be beat (email addresses), and that even if it just acts as a messaging service for that user, we have a obviously useful building block that we can extend in ways that create an friendly and intuitive experience for ElectrumSV users.

It is very unlikely ElectrumSV would launch it’s Paymail support with this extension, assuming that it is viable. But I would expect to be discussing it with any hosts that we planned to feature in ElectrumSV for our users, and after the initial release that supported Paymail, we would look to factor it in.

Wallet services that offer Paymail hosting to their users might find it hard to support this, as it uses an alternative address generation technique. How suitable it is for them to support verifiable addresses, is dependent on how their services are architected and this is an unknown.

Do not forget that this is just a shallow pass over the concept writing up ideas I’ve discussed with various people, and is mainly intended to lay out the idea. It does not go beyond doing so in the context of basic address resolution, and how this might work for BIP270 and payment requests is another matter. But at the least, that messaging service can fill in a lot of the gaps.

I could easily have spent a lot more time on this article polishing the concept, but I have other things to do, and spending all my days just writing about ways I could be working on ElectrumSV burns the limited time I have for it. So, I hope that this is a good enough effort, enjoy!

— rt12

Written by

ElectrumSV developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store