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 metanet.icu’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
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.
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.
- 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
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.
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
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.
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
firstname.lastname@example.org. It in a high level sense relies on
example.com 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
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.
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
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.
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
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.
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.
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.
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
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.
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.
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.
Maybe you have some ideas and thoughts on this? Please let me know, just somewhere other than Twitter please 😅