Notes on adapting Paymail

I’ve said repeatedly that I think Paymail provides the most usable and approachable solution for identity, that it is significantly more intuitive to any real person who might newly arrive to Bitcoin than any alternative that has been proposed. And I’ve also said that it’s designed for the wallet as a service case, like Money Button and HandCash. ElectrumSV is not service based, and does not have the resources at this time to reasonably secure any service, like SimplyCash for instance does. Even if we did, we would still need to extend and build on Paymail, and adopt it in a way that best fits ElectrumSV and it’s user’s needs. Also, something else I try to repeat often, I am not a Bitcoin expert by any means.

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 the #electrumsv channel on either unwriter’s slack or’s slack. You can add also comment here on this article, or write an article reasoning out what you find interesting or objectionable. And you can also tweet, but I will actively avoid engaging there as it is a terrible forum for discussion.

The premise of this article is how can I provide the best experience for an ElectrumSV user, who opts to use Paymail.

This article is not going to propose a specification, or even provide a solid outline of what I ideally want for ElectrumSV with regard to Paymail. It is however going to flesh out a possible picture of what might work, to address our needs. And it should do so with the user experience in mind.

An idealised Paymail integration

Replacing xpubs with shared secrets

The shared secret approach has benefits and applications that extended public keys are unable to provide. But while it starts with two parties having their own private keys, and the public key of the other party, they also need to establish a shared secret and a communication channel.

A Paymail host will have to expose an API which ElectrumSV, or any other client wallet, can make use of behind the scenes. The wallet having obtained the public key of the Paymail host, and can use this to engage in private direction of and communication with the Paymail host via it’s API. I expect that any Paymail service that wants to be competitive, will have to act as mailbox for a hosted identity. And this mailbox can be used to both establish a communication channel, and establish what shared secret to use.

Without the communication channel, just having the public keys likely means that if you want to contact someone, you have to post an on-chain message linked to that public key. Even encrypted with that public key, at the least the initial contact with that public key can be observed. And the receiver has to process everything that is addressed to them.

With the point of contact that the Paymail host provides, this can be done more privately. The host can also value add, filtering unsolicited messages out, pre-authenticating them as belonging to existing Paymail identities — should that be important. And so on. I’m sure there’s a basic level of service and an enhanced level of service that hosts can do here to differentiate from each other.

Messages sent through the host would be structured according to some protocol, and for the most part would be intended for the user’s wallet, and after processing would be displayed in some way guided by the content.

Some possibilities:

  • Actual messages for the identity holder. These might be bundled with data the wallet can also process, if the message is part of an interactive form of communication.
  • Iteration on a payment channel which the two parties wallets are making use of an intuitive process to negotiate. There might be a variety of negotiations presented to the user in an abstract fashion.
  • A real-time process that includes the parties exchanging their internet addresses so that they can attempt to direct IP2IP communication. The messaging service can act as a fallback, in the worst case that neither can open a port or be accessed by some process like NAT traversal.
  • The initiating of contact by a new party, including some token fee to justify the recipient’s time, a message of some sort for the recipient’s eyes to engage their interest, and whatever else might be useful perhaps including a shared secret and bundled identity packet.

I expect that the both the API and any communication made through it, will be based on shared secrets or some other techniques. BIP32 and xpubs will likely be used solely for older applications, and accessing older coins and data.

So we have a building block in the form of key generation using shared secrets, a way to let another party know about our interest in communication with them, and a way to exchange shared secrets. And we have a small range of the possible applications we can enable using this building block.

Considerations and layered alternatives

Indicating lack of DNSSEC support

We indicate a pass for this concern, if DNSSEC is enabled where it is expected to be. If it is not, we indicate a fail. If a Paymail host does not enable it when it can, then this is a warning sign, and we should let our users know. Some hosts can’t enable it, but this is not a binary decision, rather a situation where trust should be evaluated.

So we try for the ideal which is DNSSEC secured resolutions, and then we fall back to unsecured resolutions.

Indicating unverifiable payment destinations

And so we find ourselves back to the topic of Paymail, a service that provides payment destinations on behalf of a wallet user. Your wallet takes the contact identity, which will be a Paymail identity like It in a high level sense relies on to provide it for both the public key or payment destinations for the identity user hosted there. There is a certain level of trust that you can lend to well known businesses and the services they host, but there is no system built into Paymail where the trustworthiness of the hosting business is factored into resolutions and presented to the user before they make their payment.

Even if you know a Paymail host is run by a reputable non-anonymous business like Centbee, Money Button or HandCash, you don’t know how well secured their services are. Even if you do know they not only make best efforts to secure their services, you don’t know what new exploits are going to be developed, or how profitable it will become to exploit a Paymail host. However, there’s no such thing as perfect security and at some level you have to trust a service is secured otherwise you probably shouldn’t use the modern internet.

If we can source the identity packet of a Paymail identity from a reliable source other than the Paymail host, we have confirmation of the correctness of the hosted public key for that identity. If the Paymail host supports shared secret based extensions, then we can obtain a mutual shared secret for the hosted identity and we can use the host as a communication channel. Then we can use the host to generate addresses for that identity, and we can also generate them ourselves. This may seem like it makes the related Paymail services otherwise redundant, but this isn’t necessarily the case.

In an ideal world, we would only indicate a pass for payments if they supported this mechanism and we had that externally sourced identity packet. And we’d indicate a fail otherwise. We of course don’t live in the ideal world, so in the interests of usability over a blind algorithmic verification that produces a pass or fail, this also becomes a matter of trust evaluation.

Indicating public key conflicts

It should be a rare situation where the public key changes — except where there is a system already in place where the key change can be observed and taken into account by the wallet, the Paymail host and any other parties. If the public key matches, we indicate a pass the concern. And if the public key does not match, we indicate a fail.

A system where an identity is sourced and updated independently from the linked host is outside of the scope of this article. My feeling is that it should be possible to decouple such a system from the use of compatible identities.

Compliance with our onerous requirements

The mark of compliance

Does anyone care if a site is “ElectrumSV verified” and shows a logo? Maybe you click on the logo and it goes to the ElectrumSV site, where we confirm we approve the site. Nobody should. Who needs some vague mark that is a lot of work to confirm, and the link could probably go anywhere and who would know it was supposed to go to our web site? Not unless we told them, if they managed to make it there.

The level of compliance can be indicated where it counts, directly in the UI for the given feature, based on the programmatically ascertained level of support. This is the only mark that we need, anything more is perhaps make-work.

Supporting compliant hosts

Supporting non-compliant hosts

Trust isn’t just the binary evaluation obtained from an algorithm. The burden of meeting ElectrumSV’s ideal level of compliance is untenable at this point in time, and even moving forward into the future it may not even be worth it. I lean towards indicating all compliance factors in our initial Paymail user interface, but it has to be done in a user-friendly way. There is no value in showing red flags on everything saying DANGER DANGER! This would only result in users disabling all warnings and becoming inured to the warnings, probably quickly as they fatigue the user’s tolerance and they just want to get on with making payments. That would be doing it badly, and it is not approachable and usable.

To this end, we might consider tracking what we consider to be trustable hosts, and while we indicate non-compliance for them — we do so in a way that highlights that these are known non-anonymous businesses with good reputation. This might be Money Button, Centbee, RelayX, HandCash and so on.

So this gives us nuances to non-compliance, one might be the difference between known entity and unknown entity. While we still point out the same problems, we do so in a different way accounting for an evaluated level of trust.

Final thoughts

A few of the many things left unresolved

  • How does the user obtain the identity packet of a contact, in order to add it to their wallet so that they can use it for communication with the identity’s Paymail host?
  • How does the wallet obtain updates for identities, should we need to know if the public key or even bundled data in the identity packet for a given identity has changed? Or in the event of a public key conflict, source the latest version of that packet.

Perhaps the “how” is less important than the “where”, maybe there can be multiple “hows”, each with their own “wheres”. In this way, Paymail can perhaps become an extension of one or more on-chain identity systems, adding a level of usability that they might not be able to otherwise achieve. The need to obtain a external confirmation of a hosted identity, does seem a little cumbersome to achieve.

The Paymail host can allocate shared secrets on an identities behalf, generate verifiable payment destinations for them, and even receive payments on their behalf. And it can either serve these to the user via the messaging service, or through some API. It can also serve as a distancing layer, while IPv4 is still the only mechanism for direct connectivity and wonderful dreams like cryptographically generated addresses remain out of reach.

Paymail — acceptable beats idealistic

One thing that this article highlights, is that not all hosts can be trusted equally. We cannot support Paymail without taking that into account. This is going to be a problem for third party hosts that are not owned and run by a reputable business. I can recommend our user’s use nChain’s Paymail hosting service, even if it does not implement any of our eventual extensions, and can accord it a high level of trust. But our users are going to have to choose to silence the warnings about their mate Chad’s host, he saved a few bob on by hosting on the dodgy Bittorrent seed VM he pays for over in Elbonia.

Moving forward

Maybe you have some ideas and thoughts on this? Please let me know, just somewhere other than Twitter please 😅

— rt12

ElectrumSV developer