Explore human-readable payment addresses

[GBKS]

There's a new proposal for human-readable payment addresses that sparked new conversation around a topic that has been around for a long time. It would be fantastic if we could explore this as a community/ecosystem from a UX perspective and come up with recommendations. See this thread on Discord.

A primary topic of discussion here is the format of these payment addresses. Is it best to go with the established email format that is globally recognized and people know how to read, write, and use? Or is it confusing, the link to email problematic, and better to go with a different solution? What's best for quick adoption vs a desired end state? Let's come up with a good way forward.

[moneyball]

https://github.com/bitcoin/bips/pull/1551#issuecomment-1947357643

[matbalez]

I am a big fan of human-readable addresses for bitcoin. Dramatic improvement to usability and mass-market appeal.

On the surface, email addresses are appealing (as they have achieved pervasive use & recognizability) but I feel there are two problems with this approach that I'm not sure can be overcome:

(1) Email and money-receiving are decidedly different use cases, and thus carry with them different degrees of user expectation with how comfortable one would be with sharing an address publicly, i.e. spam is a consideration for email (I don't want to invite random people to send me garbage communications) whereas spam is not a concern for money-receiving (I would be happy to have anyone send my money, there is no downside) and as such people will be more comfortable sharing a money address more publicly than they would an email address.

(2) Until the time where all email addresses can receive money (a long, long time from now) we suffer a cold start problem that adds friction and confusion to the user experience. For instance, I happen to know the email addresses of my N friends but I do not know if their provider / host has configured their address to receive money. So I either have to speculatively try to send and/or ask them outright if I can send them money, which is an annoying hurdle that will result in failures, confusion and friction to adopt.

For both these reasons, I think it is better to have a slightly different address scheme that makes it very clear the address is designed for receiving money and will work 100% of the time. I think the UMA protocol that prefaces the address with a "$" is a reasonably good alternative. I'd be curious what other options folks can think of?

[matbalez]

A couple of further thoughts:

• one thing I don't like about the UMA design that prefaces the address with a "$" is that it's (i) anachronistic (specific to this moment in history, the symbol becomes meaningless in a bitcoin future) and (ii) geographically coded (only meaningful even in present day to America/western world). So I think that's suboptimal. Instead, I think we should really be thinking about using the ₿ symbol in the address scheme. It is immediately obvious, future-proof and globally relevant. It sucks that keyboards don't generally include the symbol present day, but there are work arounds (copy/paste, the UX in various wallets could facilitate it) and eventually if bitcoin succeeds (in the inevitability of time) all keyboards will support it.

• with that, I could see ₿username@domain.com working or maybe even username₿domain.com. IMO the latter is preferable as it is clearly something new & distinct from email. The former kind of looks like an email address, and so maybe still be confounded by the lay user as an address for emailing text rather than sending value. The latter also has the benefit of having only 1 symbol rather than 2. Simpler is usually better.

[GBKS]

We've been throwing around some UI mock-ups for different scenarios in the ux channel in Discord. I'm thinking it might be helpful if we add a page about human-readable addresses in the guide, possibly under contacts. Might help simplify implementation if there are already some well thought-out patterns. This page could cover a general approach to this problem that includes the proposal discussed here, Lightning Address, and others.

[GBKS]

As for the format, I like @matbalez reasoning. username₿domain.com is unique and recognizable. The email format is getting really overloaded already across Lightning and Nostr.

[tnull]

As for the format, I like @matbalez reasoning. username₿domain.com is unique and recognizable. The email format is getting really overloaded already across Lightning and Nostr.

I'd argue that one benefit of having user-readable names is that they can be remembered and then typed out from memory when needed. If the address introduces characters not available on any ANSI or phone keyboard, this would not be possible.

[GBKS]

Totally. Some of the mock-ups above try to address this, like letting users just hit Space to type a ₿.

By the way, I mapped bbb to type ₿ on my Mac. Works pretty well (only in default apps). Totally unrelated to this discussion though.

[tnull]

Totally. Some of the mock-ups above try to address this, like letting users just hit Space to type a ₿.

Yeah, although such split fields can be pretty annoying, especially if they end up breaking copy/pasting etc. (Which they usually do in some way, even if devs try to work around it). IMO, ANSI-keyboard compatible delimiters are much preferable to requiring such workarounds which might work completely differently in each app or website.

[GBKS]

As a European, I prefer ISO-compatible keyboards 😉. Just kidding, I get your point about easy typing.

Here's a CodePen to test this interaction (Space -> ₿). Just a few lines of code and feels very smooth (at least on my devices).

Copy/paste should not really be a thing here due to privacy (not copying this address in the first place) and automated clipboard detection (and automatically suggesting appropriate options).

One of the ideas I threw out in Discord was to avoid the @ then as well and just go for user.bitcoin.domain.com. Easy to say and type the word bitcoin, and you have to use a dot anyway in the domain. Could also just be an alternative/fallback.

[tnull]

As a European, I prefer ISO-compatible keyboards 😉. Just kidding, I get your point about easy typing.

It's not only about easy typing but also about working the same expected way everywhere. Btw, I'm European, too, but deliberately gave ANSI as an example as it is the most common subset of characters available.

Here's a CodePen to test this interaction (Space -> ₿). Just a few lines of code and feels very smooth (at least on my devices).

Sure, but how would I type it in my shell? Or in an email not implementing this custom code? Or literally anywhere else?

Copy/paste should not really be a thing here due to privacy (not copying this address in the first place) and automated clipboard detection (and automatically suggesting appropriate options).

Yes, it is. Please don't make such assumptions. Password managers use copy/paste or form filling all day long and breaking such automated input methods is a pain.

One of the ideas I threw out in Discord was to avoid the @ then as well and just go for user.bitcoin.domain.com. Easy to say and type the word bitcoin, and you have to use a dot anyway in the domain. Could also just be an alternative/fallback.

How would that discern the address from just another subdomain? Also, it would limit usernames to be single words only, i.e., dots would be disallowed? Not sure if that would be the right way to go, but If you're looking for a URI-like scheme, you might want to use/ as a delimeter, i.e., something like btc://domain/user?

[TheBlueMatt]

Copy/paste should not really be a thing here due to privacy (not copying this address in the first place) and automated clipboard detection (and automatically suggesting appropriate options). Yes, it is. Please don't make such assumptions. Password managers use copy/paste or form filling all day long and breaking such automated input methods is a pain.

I believe this was a reference to the discussion in the UX channel describing copy of human-readable names should actually copy the underlying bitcoin: URI. One of the major drawbacks of human-readable addresses is the fact that they move noncustodial wallets distinctly into custodial territory. Thus, non-custodial wallets may want to display a human-readable address, but when the user hits copy it should actually copy the noncustodial version of it. I agree with you on the paste side of things, however.

[GBKS]

Sure, but how would I type it in my shell? Or in an email not implementing this custom code? Or literally anywhere else?

Yes, of course, the idea here was for strongly optimizing for in-person communication, likely someone typing into a mobile wallet. If we don't want this to be used otherwise as much because of privacy and security, it might even be good if it's hard to type into a shell or email. Maybe the resolved payment information is more appropriate in those contexts...?

I'd also say that everything we do here is forward-looking. Why not speculate a bit on a future where ₿ is easily accessible on keyboards, like other currency symbols? For example, holding down the $ symbol on my iPhone keyboard, I have quick access to 6 additional currency symbols, including the South Korean Won (₩). Not really useful. Maybe ₿ could sneak in there? Maybe having a standard that uses it could help make it happen? It has to start somewhere after all...

Password managers use copy/paste or form filling all day long and breaking such automated input methods is a pain.

Password managers should not be affected by this. They can work as they always do.

Also, it would limit usernames to be single words only, i.e., dots would be disallowed? Not sure if that would be the right way to go, but If you're looking for a URI-like scheme, you might want to use/ as a delimeter, i.e., something like btc://domain/user?

Couldn't you just look for the first occurrence of .bitcoin. and use what's before as username and what's after as domain (including sub)? That's what my totally naive approach to that would be 😀, but I'm sure there are a million cases to consider.

If we forget about all the technical compatibilities that things like URLs and email addresses require, and just think about what works well for verbal communication/memorization, maybe we have more options? Maybe we do, maybe we don't, I'm just trying to see what's in that direction. Thanks for entertaining the train of thought.

[mouxdesign]

Such an interesting thread to read, and then even another thread on another Github page.

Read through some of the comments and made a summary of the main ideas:

• user.bitcoin.domain.com
• Username₿domain.com Problems mentioned: The ₿ is not accessible on the keyboard

The people who we build bitcoin products for if we want them to trust bitcoin as a solution then this provides a higher level of trust regardless of which approach is adopted.

Reading the other thread there are behind the scenes technical discussions that are had around implementation. I appreciate that those are very real challenges.

The main question I would ask is: What problem is having a Human readable address going to solve for users?

• Trust: Which would come from seeing something that is more familiar to them
• Ease of use: The address if simplified sufficiently it would allow a user to simply verbally say their address and the other person in the convo could type it in easily.

The human part of this comes into mind the most. I'd imagine two people having a convo and one would say send me some bitcoin. Sure what's your address?

The address of the person is: alicejohn₿walletx.com Alice says: "Alice John (then use the bitcoin symbol) at walletx.com"

That feels fairly simple to remember and with the addition of adding that to contacts it would be a simple search and send to pay that person a second time. The more symbols we add in there the more difficult it will be for someone to remember.

Challenge: This one also comes up from a convo with the silent payments dev is: What if there are two or 3 Alice Johns in he world? There would need to be some verification that Alice John 1 provides to ensure that its sent to the correct Alice.

No real strong opinion on this topic, being the researcher I'd throw out a poll to the ecosystem and ask the people to vote on what they feel would work best. This also put the power back into the hands of the people.

Suggest 2 or 3 options to them and have them present us with their fears + questions around both approaches.

Their fears + questions would lead to them not adopting the solution based on reasons xyz and would show the mostly likely solution that would be adopted.

At the same time the Bitcoin Design Guide is forward thinking and many of the solutions in there are not seen in the wild "yet". And so if the guide did create a solution it could always be modified based on when wallets start adopting it, the real challenges and solutions would emerge.

[GBKS]

I've iterated on the Google Doc, with the idea that this turns into a page on the design guide that lays out the general problem to solve, how to think about it, basic technical ideas, proposed options, UX considerations and mocks, etc. I also recorded a video to go over the current draft status and would love to get your feedback on everything.

Here's the document and the video.

[GBKS]

I just created a pull request for a new page in the guide on this topic. Would love it if you could take a look and share all your fantastic ideas for improvements.