Human readable addresses
Bitcoin addresses and payment requests are long and cryptic, practically impossible to read, memorize, pronounce, understand, or type. We are used to being able to communicate our social media handles and email addresses easily. That expectation has also extended to transacting value with neo-banking and payment applications. There have been multiple attempts at making human-readable addresses a reality in bitcoin.
The benefits to the user experience include:
- Familiarity: A format that feels more human and familiar to users
- Ease of sharing: A format that is easier to remember and recall and share in a social setting
Ideally human-readable addresses should only be used for direct communication. Whenever payment information is communicated digitally (copy & paste, links, QR codes, messaging, etc), cryptographic formats should be used for the best security and privacy.
On this page, we focus primarily on the BIP353 for DNS Payment Instructions, with some information about Lightning Addresses. They pursue similar goals, but in very different ways.
The basic idea
Bitcoin transactions always rely on long and cryptic addresses and payment formats, consisting of numbers and letters. Human-readable addresses are a means for wallets to retrieve these regular addresses. In other words they act as pointers.
There are various technical approaches to resolve addresses. We’ll learn more about the different benefits and drawbacks below.
Security & privacy
Every approach requires at least one intermediary that is being contacted to serve the payment information.
This brings up important questions around privacy and security. Intermediaries can potentially serve up different payment information than a user specified. Or they can track requests and metadata to build profiles of users and user behavior. If these intermediate hops are not controlled by the user, the address should be considered custodial. To be clear, intermediaries cannot move funds at the user-provided address. They can only re-route incoming funds or prevent payment information retrieval.
Address format basics
From email and social media, we are familiar with addresses consisting of a local and a global part. The local part is typically a username, and the global part identifies a domain or service.
- “My email is alice@domain.com.”
- “I am alice on [social media service].”
- “Pay me at ₿alice@domain.com.”
For social media, users know to navigate to the respective website or app and look up the username there. Applications rely on domains (via the Domain Name System, or DNS) to resolve the global part. In physical addresses, we have more hierarchical parts - country, state, city, street, house number and apartment. It is a familiar system.
BIP353: DNS Payment Instructions
This proposal only relies on the Domain Name System (DNS) to retrieve payment information. It is a decentralized hierarchical naming system used to translate human-friendly domain names (like www.example.com) into IP addresses (like 192.0.2.1) that computers use to identify each other on the network. Anytime we type in a domain into a browser, we rely on this system.
Note
This is a new proposal. It is still being discussed, and not widely implemented.
Address format
This proposal uses the formats “username@domain.com” and “₿username@domain.com”. This is similar to the email address format, which makes it familiar and easy to use. The ₿ prefix is an important addition for display purposes, to make it distinctly a bitcoin payment address. This provides clarity and trust to users, which is important when it comes to financial transactions.
How it works
Users create DNS entries with payment information, which can be one or more addresses of different formats, combined to a BIP 21 URI. Since address reuse is best avoided for privacy reasons, the included addresses should only be static payment codes (like silent payment codes and BOLT12 offers). Single-use addresses can be used if needed, but a mechanism to rotate them should be in place.
Wallets look up the payment information when first exposed to a human-readable address. Then they rely on the retrieved information to initiate transactions.
Trust
Setting this up requires a user to own a domain, and trust the domain provider and DNS system to truthfully communicate their payment information. If the user does not own the domain but uses a third-party service instead, then another intermediary is in play.
Design patterns
Educating users
Framing the correct use of the address should be done right away and as early in the user flow as possible. This allows them to make informed decisions as to how and when to use it. Users should be informed that:
- The purpose of the address is for verbally sharing their bitcoin address in a social setting.
- That the address is public, which carries a clear directional understanding about privacy.
Setup
Hosting human-readable addresses carries a responsibility, and non-custodial wallets that don’t provide additional services outside of the software may not want to offer this feature. However, they should still make it easy to copy payment information for setting up addresses on domains owned by the user or a third party of the user’s choice.
It is important to provide users with a simple setup experience for human-readable addresses. They are likely to use them for a long time, and need to be able to trust that everything is set up correctly.
Scenarios to consider:
- The user owns a domain they would like to use with the payment information the wallet provides
- The user does not have a domain, but the wallet developer offers DNS entries to users at a given domain
There may also be a situation where the user wants to bundle payment information from several wallets. The best candidates for address types to use are BOLT12 offers and silent payment addresses. Those are not broadly established, so a user may rely on different wallets for each type.
Below is a conceptual setup flow for setting up a DNS-based payment address both with a user-owned domain and a wallet-provided domain.
Expand image
Wallets should also verify resolved payment information. For example, a user who tries to use a regular onchain address can be informed that is a bad practice due to the privacy implications.
Sharing
Users should have quick access to their payment addresses. However, since they should not be shared electronically, there should not be options to copy or share them. Instead, users should be able to directly share the payment information that is connected to their public addresses.
Entering
Input fields for addresses typically need to accommodate various address types. Whenever possible, addresses should be pre-filled from the clipboard, contacts, or previously clicked links. This is more convenient for users and reduces manual input errors.
While it is unlikely that users will type in the more complex address types, an address input field should not be restricted to only accepting a single address type. In this example, a single input field is capable of accepting a variety of different formats, and it provides feedback to the user about what they have entered.
Keeping users informed
The payment information associated with addresses in contacts may change or even become invalid. Wallets should ensure to inform the user of updates to review or act on. This is best done at the time the user wants to initiate a payment to a contact.
Lightning Address
Compared to DNS Payment Instructions, Lightning Addresses are focused on the lightning network only. They bring another intermediary into play, and allow for much more dynamic functionality.
How it works
Lightning addresses look like traditional emails. Under the hood, a wallet that uses a lightning address reformats it to a URL. It then looks for information about a LNURL web-server at that location (more on that here). That server handles the communication with the lightning node and passes messages back and forth. This allows for complex interactions (like authentication and withdrawals), but also requires trusting the web server.
In a similar vein, UMA is based on LNURL and Lightning Address, with modified functionality and the ”$alice@domain.com” address format. The $ prefix was chosen to represent both fiat and crypto currencies.
Paynyms
This approach relies on a single directory provider, which maps a human readable name with a BIP-47 payment code. Having a single provider allows for the omission of the global part, in this case “my.paynym.is/username” and users can simply be referred to by their usernames. The directory code is not open-source.
Next, we will learn about the different private key schemes used to secure your bitcoin.