Paymail, Identity and ElectrumSV

Version 3, 2019/11/21

Overview

These are just notes on my current thoughts on how we would integrate both on-chain and Paymail identities into ElectrumSV. In theory it is a proof of concept for how we might fit them into ElectrumSV, but as I am not in the near future going to be working on this, the value of it is more in sounding out the approach it outlines for the purposes of reaching consensus.

Note that this was written up in November 2019, and does not necessarily reflect my current thinking, or any commitment from ElectrumSV to go any particular way. I don’t think they were published elsewhere, but maybe they were.

Image for post
Image for post
Our logo, because Medium like you to bung this sort of thing in there.

Why not the current Paymail?

The existing Paymail extensions are oriented towards hosted wallets where the wallet provider is already trusted to a degree. ElectrumSV will allow users of our wallet to choose their own hosting services, or even the hosting services of parties who might look legit, but may not be secured well even if they have the best of intentions. It is very likely that we will curate the experience for regular people and only offer as visible options services we have more faith in — the minority of people who want to manually enter an alternative would do so through the wallet settings.

We are not the one and only hosted service for our users, and although we could very well offer a hosted service for them to use, they would be able to opt to use other ones that support our API. For a hosted wallet like HandCash, Centbee and Moneybutton, you can assume that they have spent the time to secure their services and this allows them to act as an agent for the users of their wallet, in a way where those users can trust them to act reliably and securely for the sake of their own reputation and the future of their business.

Looking at Paymail differently, we need to work out how we can use it in a way that is secure for users of our very different wallet. They shouldn’t have to blindly trust any host, and especially not any one we run for them. I think there are two key aspects that Paymail gives us:

Those two things, in the context of a wider model of identity including both P2P identity exchange and on-chain data, should hopefully result in an intuitive user experience for regular people. But to get there we cannot use the existing functionality that Paymail provides.

A case for unique naming

There are numerous proposals for systems where people buy or claim a name and then supposedly everyone adopts this system and that name can be assumed to be a way to look up and find an exact identity. I do not believe that the ability to find a contact by name and obtain their identity, has to be intermixed with the identity itself. We can have multiple ways to find a contact and obtain their identity, some from Paymail, some from trusted on-chain indexers, some indirectly from other contacts, information sources or even directly from the contact themselves.

A good example of a naming system is HandCash’s handle system, where they had their own curated phonebook of their users and each wallet owner was required to choose a name that was not in use, and they could then be looked up in HandCash’s phonebook. With the addition of Paymail, this phonebook can easily be extended so that every user in it is exposed on their service’s Paymail host as a value added service for user’s of their wallet. In this case because they are a hosted wallet and each of their users is using their product, it makes sense their identity and name are inherently linked.

Another example comes from the idealists. They believe that we need some permissionless system where people claim names in a global registry that has no manager and manifests itself on-chain, and that this will somehow work. They might have thought out a system that tries to either prevent or reduce the harm of people preemptively claiming all the best names, and often the identity is inherently linked to the name. Could this work? Perhaps. But what happens if it turns out to be flawed like other things that become a form of consensus, like custom difficulty adjustment algorithms.

My own belief is that I think that permissionless on-chain naming is dead in the water. It is a complex ideal that socialises a likely problematic design, installing the ensuing problems into the blockchain, and the world would be a much happier place if we completely ignore proposals for one, from anyone who tries to market theirs.

We saw how HandCash users can now be contacted externally by other wallets that support Paymail, solving the global naming problem, and replacing their local handles. This is an improvement, but HandCash do have their own locally unique names, and any user cannot claim a name that any other user is already using. I do not consider this to be a real problem, users already have options, HandCash could choose to allow any user to use any name they want on any other domain that is pointing to the their wallet’s official Paymail host. Is your name Alice? You don’t want people to have to look you up as “alice1212121@handcash.com”? No problem, HandCash could if it suited their business model support your own domain referring to their official Paymail host, so you can have “alice@smitt.com” or whatever. Would HandCash do it? This is irrelevant. You can switch to another competing wallet that does allow it. You can offer to pay them more to be able to do it. They could add vanity domains and a user might have the option of choosing those where Alice is available.

Let me state it clearly. Paymail solves naming in a way vastly superior to anything anyone else is proposing. We can leave naming to Paymail.

The user experience

Our use case is outlines the various ways you might add Alice as a contact in ElectrumSV.

The on-boarding process

When a user on-boards a contact, they might look at it’s claims and verify them, perhaps change the name they want to see the contact as, and then formally add it. This will then cache a pinned version of the identity and it’s metadata as a contact in their wallet. I expect we want to prevent our users sending money to non-contacts, because there is no reason they should not have a record of who they paid along with what they paid.

The key problem with this is that they can unwittingly obtain contact metadata that is for a different identity, however what it claims to be appears correct for who they expect it to be. So they have no easy way to know it is really who they say it is.

In order for the solution presented in this document to be suitable for adoption, it needs to encompass a reasonable solution for this problem, so that it is not a concern for our users.

On-boarding via Paymail

The first problem is that you, like most of us, are potentially ham-fisted. You might very well type “alice@smitt.com” and not realise it. So now you add this as “Alice”, and might proceed to assume it is Alice, and send them money. This might be someone typo-squatting, or it might just be another person legitimately named “Alice Smitt” and you have unwittingly just been careless.

The second problem is that we need to trust the Paymail host to provide correct data. It might be that you followed some misguided instructions and set your wallet up to use a dodgy ill-intentioned Paymail host. Or it might just be that the Paymail host for all their best efforts, failed to secure their services and they were compromised.

On-boarding directly

There are numerous ways this might work. It might be that Alice has some physical thing that encapsulates her identity metadata and she can use that to load it into your wallet. It might be printed out as a QR code on a card, and she gives that to you to hold in front of the screen. Or she might send the QR code as an image in an email to you. Or your wallets might establish direct connection and exchange it directly.

As you are both in direct and immediate contact, it is possible to engage some process where if you want to be very sure that the identity you have for each is correct, you can do so visually with the aid of the wallets.

On-boarding indirectly

You might also obtain Alice’s identity metadata indirectly. This might be from a third party who happens to be nearby and might be a friend or family member. In the same way that Alice might share her identity directly, the third party might share it indirectly with you. It might also be that you go to Alice’s website or an email you think is from Alice, and scan the QR code you find there.

The problem with this is that you have to trust the third party has conducted their own due diligence — or is valid and uncompromised. It isn’t enough for the third party to sign the identity metadata and vouch for it, this process does not vouch for their personal competence, just that it is actually the data they think is correct. For this to be safe, there needs to be some form of evidence that it is actually Alice’s identity. This is a problem it has in common with Paymail addresses.

External identity verification

The user is on-boarding a contact, and they ultimately have responsibility for their choices and decisions. But to not help them detect or avoid mistakes where possible, is to create a poorer user experience. So we come to the question, given that we have obtained identity metadata for a potential contact, how can we check it is who they are looking for?

From a Paymail address

In this situation you entered Alice’s Paymail address and ElectrumSV is attempting to verify it in order to provide you with the best on-boarding experience. It is expected that you have entered it correctly, and where possible we aided you in doing so.

If Alice has is using a Paymail host that we cannot credit with reputation and trust, then we can immediately flag the identity metadata as risky for this reason. This is immediate feedback for you, and you can act on it as you see fit. The problem here is that there is no cost for it to give you back identity metadata with a public key which it created, and therefore has the private key to claim or sign anything it needs to related to that identity.

If Alice is using a Paymail host that has reputation and trust, then we do not raise any immediate red flags. We can double check with multiple external independent sources that the service has not had any reported problems before doing so. Then we can assume that the identity metadata should be correct, but we should also look externally for verification.

Every user should be encouraged and helped to put their identitymetadata on-chain. Let’s say in this case Alice’s wallet pushed her to do so, and she did. Assuming that the core identity metadata that she puts on-chain is the same as the identity metadata the Paymail hosting service provides, and it is then wrapped along with signatures from the Paymail hosting service and other points of contact she wishes to associate with the identity, then the whole package is signed by her. And this could be what is published.

The verification services can show a proven history of her identity on request, and most commonly might provide the latest updated version along with some metadata like how old it is. This they might sign. On request they could provide the merkle proofs of the full identity. And other services can be checked for independent confirmation they observe the same thing, if necessary.

Given that the Paymail host has good reputation, and the verification services do not provide bad data, or responses that do not match with the Paymail host’s claims, you at this point can be allowed to onboard Alice with no red flags. We can show a green tick, and allow her to view a summary of the things the wallet has considered in the process of showing it.

Including a Paymail address

Verification of identity metadata that contains a Paymail address follows much the same process that obtaining it from the Paymail host directly does.

Without a Paymail address

In this case, the lack of a reputable Paymail host and a unique name for the identity, means that the verifiability of the identity metadata relies on the nature of the source and perhaps whatever the verification services claim about the corresponding on-chain identity for the given public key.

Nature of sources of identity

Direct word of mouth

If you know and trust Bob and Bob knows Carol, and Bob hands you Carol’s contact packet which includes his record of her identity, this should be a trustable contact. You will have onboarded Bob to your satisfaction and where possible ElectrumSV will have highlighted both successful verification and glaring problems along the way. So now when Bob signs Carol’s contact packet and gives it to you, you have a way to check that what you receive is what he is giving you. ElectrumSV will again engage in verification and highlight both the success or glaring problems, but generally unless there are glaring problems this should be a “green tick” process.

This can be done in person, or it can be done indirectly. By proximate NFC, bluetooth, wifi or QR codes. Or even email, or other electronic media. As long as you already know Bob, and he provides it signed, this provides the direct link.

Anything else

If we have no direct source we trust, we can simply flag it and tell you, and leave it up to you to make the decision.

Purely on-chain identities

From our perspective, what an on-chain identity has to encapsulate is not much more than what a hosted identity has to encapsulate. It can be the same core identity metadata. The difference becomes that a purely on-chain identity is not addressable. This means you cannot simply use a globally unique name that regular people can look at and understand, to find them and reliably obtain their identity metadata. This isn’t a deal breaker. I suspect that direct acquisition of contact metadata, whether as bulk lists from your employer of coworkers, or a family member of other family members, or even someone specific, should be trustable simply through obtaining them from an already trusted party. The nature of the source of the identity metadata should be more than sufficient.

Given this is not contentious, then it becomes a matter of defining what identity metadata needs to contain, and then defining a protocol and making services that index it and allow verification of it.

Identity metadata and contact interaction

Unsolicited payments

In an ideal world you can connect to Bob and use BIP270 directly. But this is not always possible. If Bob and you cannot directly connect, then there may be a situation where you want to pay him immediately and not wait.

But it’s no use to Bob if you pay him in a way that is inconvenient for him. And why should either of you want to make it public if you can have it done privately. So we want to generate unique keys for the payment. And we want to construct the payment in a form that Bob wants.

Let’s assume you are paying Bob and he specifies he wants a P2PKH payment. This is the simplest case, and we can use a shared secret to derive a custom payment public key from Bob’s identity public key, and construct the P2PKH payment. We can iterate the sequence for additional payments, if necessary.

Now what if it is more complicated. What if it is the West Brisbane Bridge society and they want a multi-signature payment. In this case, let’s say that inside the signed identity metadata is a script template with indexes and for each a base public key. With this and the shared secret we can generate unique keys for each component key and inject them into the script template to create a suitable payment script. And we can create a sequence of unique private payment scripts in the same fashion.

In theory, almost any desirable payment script could potentially be included in the identity metadata in this fashion, for the purpose of unsolicited payments. However, keep in mind that if the payment script is going to be sufficiently complex, then perhaps that use case isn’t really suited to unsolicited payments. And if there are multiple outputs to the party being paid, it might be worth passing the derivation paths, so that the process includes no pain points.

Just because you can make a payment script does not mean Bob wants your transaction. The same goes for the West Brisbane Bridge Society. They might prefer or even require you to use merge avoidance if applicable, or just a wisely chosen number of suitable denominations for the sake of privacy. This can be defined in a payment policy. Also it follows that you do not want to broadcast your own transaction, you want to give it to the party you are paying. If it is broadcast, this means they accepted payment. If it doesn’t within a suitable amount of time, then you should consider double-spending if you change your mind. Or your wallet might do it automatically, for the sake of an intuitive and low maintenance user experience.

Because you are using unique keys, unless you tell the other party, there is no way that they can know that you are paying them. By making the process of payment include handing the transaction to them to accept and broadcast, this is solved. And if they want the payment but it is not constructed in accordance with their preferences with regard to inputs and outputs, they are encouraged to come back to you and renegotiate.

How do you give the transaction to them? I suspect that any contact that wishes to receive unsolicited payments needs to provision for it in their identity metadata. This will include the payment script templating, the policy on acceptable payments, and a reference to a mailbox service where the payment can be posted to them. Or if there is addressible contact information like a Paymail address that can be expected to include this information, the mailbox service endpoint can be resolved there.

No mailbox, no unsolicited payments. Any initial contact via the mailbox can be done in the same manner as whitepaper 42 suggests, along with encrypted data which might include the transaction. My own preference is that the process defaults to requiring that all unsolicited payments are associated with an identity. If someone wishes to receive tainted coins from Ralph McFentanyl anonymously they might perhaps be able to opt-in.

I have a suspicion that the unsolicited payment that falls back to negotiation, can do so by falling back to using BIP270.

Other forms of contact

We’ve outlined that identity metadata can include a reference to a service that acts as a mailbox for the contact. Or that if addressable contact information like a Paymail address is included, that the service can be resolved from that. So we can expect to have a service that acts on behalf of the contact.

This might provide different forms of access to the contact.

One key form would be the ability to post messages to them using a mailbox hosted on the service. A service would be incentivised to provide their customers, your contact being one, with the ability to maintain an open connection to the device their wallet application is running on. Then they could relay anything they needed to, including events like new messages.

Another key form would be the ability to establish a direct connection to them. This could happen in either of two ways. The first might be the safer way for the contact or even you, where the service is compensated to relay the connection. Although in the case neither party is directly contactable, perhaps because they are behind routers, it is also useful there. The second would be the ability to establish a direct connection, by exchanging IP addresses.

If contact through either mechanism is unsolicited, it might be preceded by the construction of an unsolicited payment to prove you are not wasting the contact’s time. If you’re compelling enough in your introduction, they might waive it in the spirit of goodwill, and if you are not they might take it before engaging you.

All contact should be encrypted, and encryptable easily, given two identities and the simple application of whitepaper 42.

Conclusion

This document has covered Paymail, locating contacts by their ownership of a unique name, and how to make private payments between contacts. It is my belief that while it could likely be improved in a lot of ways, it forms a proof of concept and both covers the ability to access a new contact by their unique name (Paymail address) but also reasons out how on-chain identity can work both with Paymail and independently.

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