Notes on Paymail verification

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.

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?

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.

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.

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.

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

A loose verification extension

Keep in mind this is part of a layered system.

  • 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.

--

--

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