Notes on adapting Paymail

An idealised Paymail integration

The first release that ElectrumSV makes for Paymail, will be a simple one — likely using the existing xpub as a key source, or as I find myself defaulting to calling it now, payment destination stream. So the extrapolation I am going to make, will be something we would aim for in the longer term.

Replacing xpubs with shared secrets

You can read about how replacing extended public keys with shared secrets, shared secrets being what whitepaper 42 goes into detail about, should allow us to verify that the payment destinations provided by a Paymail host are correct for a given identity it hosts. But that’s an optional benefit — a specialisation of the larger potential that shared secrets make possible. Forget about verifying payment destinations for now, and let’s look at some of those 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.

Considerations and layered alternatives

When someone lays out a solution and halfway through they reveal that it builds on a technology which is not only available yet, but won’t be usable for some time, they don’t have a present day solution. Let’s frame this nascent technology as unobtainium. So where does there solution fit in? If it’s a good solution and the unobtainium aptly framed, we could keep it in mind or draw inspiration from it. If it’s a good solution and the unobtainium is unobtainable in the general scenario, but obtainable in some privileged scenarios, we might actually use it — but we’d place it as a preferred solution to try first if possible before working our way down a list of possible alternatives in order of decreasing preference. Hopefully as a few years pass, the unobtainium becomes less so, and the preferred solution gets chosen often.

Indicating lack of DNSSEC support

A part of the Paymail standard, is that the DNS should be configured with DNSSEC enabled. We do not expect perfect security, and by no means can any solution give us that. We won’t even ask how secure the registrars which enable DNSSEC, and on whom we are dependent for it to even mean anything, are. But we expect the same general security as the rest of the internet, and the host to make an effort.

Indicating unverifiable payment destinations

If the wallet of a payer is using the ideal IP2IP model, then it connects directly to the payee and can assume it is paying to the correct destination. But we don’t have IP2IP — it’s a longer term ideal reliant on an internet where IPv6 and it’s many promising technologies can be used. We can’t rely on it being available, so instead we layer alternatives that do work and pick the most appealing one from those that can work in a given scenario.

Indicating public key conflicts

We have an identity packet for a contact, and it declares that it is represented as a specific Paymail identity hosted somewhere. The expectation is that the public key in that identity packet, will match the one that the Paymail host is using. If it doesn’t, at best it is likely an indication that the identity has been updated in one place, but not the other. At worst, it is likely an indication that the host has been compromised and the identity subverted by an attacker.

Compliance with our onerous requirements

So we’ve fleshed out a model for how we might provide the best Paymail experience for ElectrumSV users. Let’s look at what compliance with our model means.

The mark of compliance

Is it “heart healthy”? You can read the label, and isn’t it great that you can see that the business who make the product paid a donation to the people who allow their mark to be placed on the label. Maybe it’s not heart healthy, but it meets some standard of donation level.

Supporting compliant hosts

A compliant host will show passes for all preferred methods, implementing support for them all. It might get fails in some cases, but it will not be for anything that implies it has been compromised.

Supporting non-compliant hosts

It should be pointed out that non-compliance is not necessarily a bad thing, and it might be a practical result of the limitations of resource allocations in the businesses whose Paymail hosts we interact with. Or it might just be the price we pay for an identity system that has both the qualities of being approachable and usable in the present.

Final thoughts

The path forward is starting with support for the first Paymail host we can trust. We should be able to include most conceivable visual indications out of the box, even if there is no fully compliant host and they all display failures and incur warnings. A user should have the opportunity to see how secure their payments are. And if we make this an unusable experience, then we have done it badly.

A few of the many things left unresolved

A few of many things?

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

Paymail — acceptable beats idealistic

I acknowledge that Paymail does not provide some devtopian solution, where the security and privacy meet some arbitrarily pure definition. I find the compromises it makes acceptable, and can morally stand behind any decision to support it in ElectrumSV and recommend it to our users. To me, Paymail is an approachable solution for normal people, and for that matter well designed using standard technologies.

Moving forward

Writing this article helped me come up with at least an initial direction for how we can provide the best Paymail experience for our users. I’m not 100% certain about the details of the stuff that will be longer term, but I think many of the ideas have a reasonable chance of being relevant. What I do feel strongly about is the idea of compliance, displaying compliance contextually based on trust, and bringing in shared secrets as a key generation primitive.



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