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 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, recall, and share
Important: 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 BIP-353 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 creates potential privacy and security risks that users need to understand.
Key considerations:
- Intermediaries can track requests and metadata to build profiles of users and payment patterns
- DNS queries may leak information about payment relationships
- Services can potentially serve different payment information than specified
If the domain (website) where the payment information is stored, is not controlled by the user, we will refer to the address as “managed”. To be clear, intermediaries cannot move funds at the user-provided address. They can only prevent payment information retrieval, or re-route funds by returning different payment information.
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 on [payment service].”
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.
BIP-353: DNS Payment Instructions
This proposal only relies on the Domain Name System (DNS) to retrieve payment information. DNS 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. This use case is very similar to what human-readable addresses try to achieve, making DNS a good fit.
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”. It 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 be reusable (like silent payments 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. To ensure this information is up-to-date, wallets regularly check for updates, based on the expiration provided by the DNS resolver.
Trust
Setting this up in a trust-minimised manner 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 user to make informed decisions as to how and when to use the address. The information should include:
- 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.
Introduction to the feature in an imaginary application called Bubble Wallet.
Naming
Human-readable address is an appropriate descriptive term for this proposal and technical discussion, but not necessarily practical for end-users. Due to the similarities to the familiar email format and social media practices, we can borrow from these standards.
- We can generally refer to a human-readable address as (a new type of) bitcoin address
- If it is provided and managed by a third-party, the product name can be used (.e.g Bubble address or Bubble bitcoin address as in the example above)
- The first part of the address can be referred to as username (see the setup section below)
Managed address setup
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 and working correctly.
Below is a sample flow, in which a user can define their unique username, which is then combined with the wallet providers domain to form their human-readable address.
The user is asked to choose a name unique to this specific service.
Once a unique name is found, the user can finalize it.
The confirmation provides additional tips to keep in mind and access to additional configuration.
Address settings allow users to adjust the payment information associated with the human-readable address.
By default, this address is configured with the wallet’s own BOLT 12 lightning offer.
Here the user has added a silent payments address as a fallback, as well as a personal note.
Wallets should also verify any addresses the user defines. For example, a user who tries to add a regular onchain address can be informed that this is a bad practice due to the privacy implications.
The additional configuration is important, to account for the diversity of features that different wallets offer. There are likely to be situations where the user wants to bundle payment information from several wallets. The best candidates for address types to use (due to their re-usability) are BOLT12 offers and silent payment addresses. Those are not broadly established, so a user may rely on different wallets for each type.
Sharing
Users should have quick access to their payment addresses. However, since they should not be shared electronically, the options to copy or share should directly use the underlying payment information that is connected to the human-readable address.
Address input
Input fields for addresses typically need to accommodate various address types (see the contacts page). 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 entered.
Various interactive states of an address input field.
Wallets that host many addresses may also match entered usernames against their database and highlight matches. For example, if both sender and receiver user the same wallet, it suffices for the sender to enter the receivers username, and the wallet can auto-complete the remainder of the address.
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.
Wallets should gracefully handle various failure modes, and provide clear error messages that help users understand and resolve issues. For example:
- DNS resolution failures
- Invalid or missing payment information
- Expired payment information
- Network connectivity issues
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.