OpenAlias seeks to provide a way to simplify aliasing amidst a rapidly shifting technology climate. Users are trying to cross the bridge to private and cryptographically secure infrastructure and systems, but many of them have just barely started remembering the email addresses of their friends and family.

As part of the ongoing development of the Monero cryptocurrency project, we asked ourselves: how can we simplify payments for users unfamiliar with cryptocurrency? Monero stealth addresses are at least 95 characters long - memorising them is not an option, and asking someone to send a payment to <95-character-string> is only going to lead to confusion.

At its most basic, OpenAlias is a TXT DNS record on a FQDN (fully qualified domain name). By combining this with DNS-related technologies we have created an aliasing standard that is extensible for developers, intuitive and familiar for users, and can interoperate with both centralised and decentralised domain systems.

Typical aliasing systems are simple key-value stores. A cryptocurrency may, for instance, have an aliasing system that lets you (through the process of mining) declare that the alias Bob is equal to <95-character-string>. This has two major pitfalls for end-users. Firstly, it makes it the responsibility of that cryptocurrency to resolve issues or alias disputes. For instance, if a user loses their private keys and want to continue using that alias, there needs to be a mechanism in place for that, otherwise you end up with dead aliases and users have the hassle of having to update everyone that they have a new alias. The second problem is that it doesn't actually solve anything. Once the first few Bob-derived aliases are taken, users end up resorting to things like Bob1979-awesomesauce324, which means that the end-user still has to have that written down in an address book somewhere.

The idea of a DNS-based alias system is not new, and has been suggested on more than one occassion. The groundwork for OpenAlias was initially done by Riccardo "fluffypony" Spagni and Naphex, formerly of btcXchange.ro. Many months after this initial gem of an idea was born Riccardo, along with the rest of the Monero core team, fleshed it out into a practical and extensible standard. A special thanks goes to Tom Winget, who created the first OpenAlias client implementation in Monero Core.

The Monero core team, and other contributors, are actively adding new OpenAlias implementations. To that end, there are currently five implementations:

• Electrum, lightweight Bitcoin wallet (from 2.0 onwards)
• MyMonero, a web-based Monero account/wallet management system
• Monero Core, including the simplewallet and rpcwallet applications
• Coin.Space, a web-based Bitcoin and Litecoin wallet
• openalias.rs, a command-line tool and Rust library for looking up and parsing OpenAliases

OpenAlias can be used for anything, but our primary use-case is to simplify cryptocurrency payments. Users are already familiar with systems like PayPal that let you send a payment to an email address. Thus, to the end user this should be no less intuitive. In order to make the paradigm truly familiar for the end user, OpenAlias allows for the user to enter either just the FQDN (eg. example.openalias.org) or an email-style address that is translated to an FQDN (eg. [email protected])

Workflow:
user wants to send a payment to donate.getmonero.org
user visually confirms the resulting address is as expected
payment is made to the address

Applications should, at a minimum, implement the following workflow.

Workflow:
if the value entered contains an @ character, replace it with a . (period) character to allow for email-style addressing
check that the value entered contains a . (period) character, if not then it is an address and not an FQDN
fetch all of the TXT records for the FQDN, retry at least 3 times on failure, handle an overall failure in the lookup
step through each of the TXT records and make sure we have the oa1 (OpenAlias version 1) prefix followed by the prefix for our application (oa1:xmr in our example), break on the first match (ignoring later matches unless your application specifically supports handling multiple records)
extract the recipient_address from the parsed data
check if we have a valid DNSSEC trust chain (RRSIG, DNSKEY, NSEC3), if not then alert the user that it is potentially untrusted, continue if the user agrees
confirm the validity of the address with the user

In order to ensure that lookups do not betray the user's privacy it is best to implement DNSCrypt from OpenDNS, and force resolution via a DNSCrypt-compatible resolver. Dependent on your use-case, you may choose to bake DNSCrypt into your software, or bundle dnscrypt-proxy along with your application.

There are only a handful of DNSCrypt compatible resolvers worldwide, and fewer still that additionally support DNSSEC validation, support Namecoin resolution, and don't log DNS requests. Additional DNS resolvers that meet these criteria will be launched and operated by OpenAlias and by contributors in the coming months. In order to make your life easier, you can get a list of available resolvers that meet all these criteria by fetching the TXT records from any of the following domains:

• resolvers.openalias.org
• resolvers.openalias.ch
• resolvers.openalias.se
• resolvers.openalias.li

The TXT records consist of host:port=providername=pubkey, allowing you to connect to their DNSCrypt resolver using these details. These resolver records will be maintained, and if a malicious resolver is found it will be removed. It is, therefore, prudent to poll this list regularly within the application, either on-request or at least once every 24 hours.

TXT records contain, at a minimum, only two pieces of information: the prefix, and the recipient_address. Let's take a look at a typical OpenAlias TXT record:

oa1:xmr recipient_address=46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em; recipient_name=Monero Development;

The record always starts with "oa1:", which indicates it is an OpenAlias Version 1 record. If we don't have that prefix we ignore the record, as it may be an SPF record or something else that we don't care about. For other applications, Bitcoin for example, that prefix would be oa1:btc or whatever the developers choose. OpenAlias does not maintain a repository of prefixes at this stage, but may do so in future.

At a minimum, the recipient_address key-value must exist. OpenAlias exists to alias FQDNs to an "address" of any type, and this is expressed in this value. Future versions of the OpenAlias standard may implement alternative bare-minimums if use-cases are found besides FQDN->Address use.

Key-value pairs are separated by a semi-colon and, optionally, a space for legibility. The value may or may not be wrapped in double-inverted commas, which should be removed from the value if found at the beginning and end of the value. The value should also always be trimmed of spaces, unless the space is escaped with a backslash. Dependent on the DNS library or implementation you use, you may find that the semi-colon at the end of the pair is escaped with a backslash.

In order to not overcomplicate this, a semi-colon is a forbidden character unless it is in a value that is entirely wrapped in double-inverted commas. Similarly, a double-inverted comma can exist anywhere in the value without needing to be escaped, unless it is both at the beginning and the end of the value, which is not allowed. Keys and values are not limited in size, although it is counter-productive to have exceedingly large key-values, as DNS is not designed as a data transfer mechanism.

The other key-value pair in our example is the recipient_name. This is not necessary, but useful for the purpose of confirming the correct recipient with the user, or for providing the user with the option of adding an entry to an address book.

For a discussion about the additional standard (optional) key-value pairs, please see the Extend section below

This is what the same FQDN has, but for Bitcoin:

oa1:btc recipient_address=1FhnVJi2V1k4MqXm2nHoEbY5LV7FPai7bb; recipient_name=Monero Development;

• tx_description - in addition to the name of the recipient, if you are using OpenAlias for transactions you may choose to define a transaction description. Bear in mind that DNS is typically long-lived data and not always updated at request time, so this should only be used if it does not need to be updated constantly.
• tx_amount - as above, this should only be used where it is semi-permanent and unlikely to change often. The amount is a numeric value, and the exact numeric type and size you choose to enforce is up to you and your application's use-case.
• tx_payment_id - this is particular to Monero, but is standardised as other cryptocurrencies (CryptoNote-based cryptocurrencies in particular) may find it useful. It is typically a hex string of 32 characters, but that is not enforced in the standard.
• address_signature - if you have a standardised way of signing messages based on the address private key, then this can be used to validate the FQDN. The message that is signed should be the entire FQDN (eg. donate.getmonero.org) with nothing else. Validation would be to verify that the signature is valid for the FQDN as a message.
• checksum - checksum is an optional CRC-32. It has to appear as the last item in the TXT record, otherwise the record is open to manipulation. Depending on your use-case, it may serve little or no purpose, although some may choose to include it for additional validation. In order to calculate or verify the checksum, take the entire record up until the checksum key-value pair (ie. excluding the checksum key-value pair). Strip any spaces from either side, and calculate the CRC-32 on that final record.

As this is an open standard that is meant to be extensible, defining additional pairs is up to you. Your client-side application may require certain key-value pairs as a minimum, and you should make that information easily available. If you have a use-case where you feel certain key-value pairs may provide widespread use and benefit, please reach out to us and we can include it in the standard if appropriate.

OpenAlias is a very new standard, and is open to improvement and additions. Please reach out to us via the details at the bottom of this page, and we can continue to expand and improve the OpenAlias standard!

In order to simplify implementation for developers, the Monero Project is writing sample implementations and libraries for various languages. Additionally, OpenAlias will run open and free DNS servers that support Namecoin, DNSSEC, and DNSCrypt. If you are a developer and wish to submit or contribute code, please feel free to do so.

If you would like to support this ongoing effort and help us cover the costs, please consider donating to the Monero Project either via Monero: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em or via Bitcoin: 1FhnVJi2V1k4MqXm2nHoEbY5LV7FPai7bbIf you use an OpenAlias compatible client, both of these donation addresses are available on openalias.org and/or donate.getmonero.org.

OpenAlias is a part of the Monero project, and can thus be discussed in either #monero-dev or #openalias on Freenode. There is also a dedicated OpenAlias section on the Monero forums. If you would like to get hold of us personally, then you can do so via email: [email protected].

Media enquiries can be directed to Riccardo Spagni directly on [email protected].