Subject: [bitcoindev] Mapping Human-Readable Names to Payment Instructions

From: Matt Corallo <[email-masked]>
Date: Tue, 13 Feb 2024 11:56:38 -0800

Hey new-list!

I'd like to propose a BIP defining a mechanism to resolve human-readable names to Bitcoin payment 
instructions in a way that supports lightning/on-chain/payjoin/silent addresses/etc/etc. Below you 
can find the full BIP draft for comments, as well as in the BIPs repo at 
https://github.com/bitcoin/bips/pull/1551

Matt

==Abstract==
This BIP proposes a standard format for encoding [[bip-0021.mediawiki|BIP 21]] URI schemes in DNS 
TXT records.

==Motivation==
Various Bitcoin and other cryptocurrency applications have developed human-readable names for 
payment instructions over time, with marketplace adoption signaling strong demand for it from users.

The DNS provides a standard, global, hierarchical namespace mapping human-readable labels to records 
of various forms. Using DNSSEC, the DNS provides cryptographic guarantees using a straightforward 
PKI which follows the hierarchical nature of the DNS, allowing for stateless and even offline 
validation of DNS records from a single trusted root.

Further, because DNS queries are generally proxied through ISP-provided or other resolvers, DNS 
queries usually do not directly expose the queryer's IP address. Further, because of the prevalence 
of open resolvers, the simplicity of the protocol, and broad availability of DNS recursive resolver 
implementations, finding a proxy for DNS records is trivial.

Thus, using TXT records to store Bitcoin payment instructions allows for human-readable Bitcoin 
payment destinations which can be trivially verified on hardware wallets and which can be resolved 
relatively privately.

==Specification==

=== General rules for handling ===
Bitcoin wallets MUST NOT prefer to use DNS-based resolving when methods with explicit public keys 
are available. In other words, if a standard Bitcoin address or direct BIP 21 URI is available or 
would suffice, Bitcoin wallets MUST prefer to use that instead.

=== Records ===
Payment instructions are indexed by both a user and a domain. Instructions for a given `user` and 
`domain` are stored at `user`.user._bitcoin-payment.`domain` in a single TXT record.

All payment instructions MUST be DNSSEC-signed.

Payment instructions MAY resolve through CNAME or DNAME records as long as all such records and the 
ultimate records pointed to by them are DNSSEC signed.

User and domain names which are not expressible using standard printable ASCII MUST be encoded using 
the punycode IDN encoding defined in [[https://datatracker.ietf.org/doc/html/rfc3492|RFC 3492]] and 
[[https://datatracker.ietf.org/doc/html/rfc5891|RFC 5891]].

=== Resolution ===

Clients resolving Bitcoin payment instructions MUST ignore any TXT records at the same label which 
do not begin with (ignoring case) "bitcoin:". Resolvers encountering multiple "bitcoin:"-matching 
TXT records at the same label MUST treat the records as invalid and refuse to use any payment 
instructions therein.

Clients resolving Bitcoin payment instructions MUST fully validate DNSSEC signatures leading to the 
DNS root (including any relevant CNAME or DNAME records) and MUST NOT accept DNSSEC signatures which 
use SHA-1 or RSA with keys shorter than 1024 bits. Resolvers MAY accept SHA-1 DS records.

Clients resolving Bitcoin payment instructions MUST NOT trust a remote resolver to validate DNSSEC 
records on their behalf.

Clients resolving Bitcoin payment instructions MUST support resolving through CNAME or DNAME records.

Resolvers MAY support resolving non-ASCII user and domain identifiers. Resolvers which do support 
non-ASCII user and domain identifiers MUST take precautions to prevent homograph attacks and SHOULD 
consider denying paste functionality when entering non-ASCII identifiers.

=== Address Reuse ===

Payment instructions with on-chain addresses which will be re-used SHOULD be rotated as regularly as 
possible to reduce address reuse. Such payment instructions SHOULD also use a relatively short DNS 
TTL to ensure regular rotation takes effect quickly. In cases where this is not practical, payment 
instructions SHOULD NOT contain on-chain addresses (i.e. the URI path SHOULD be empty).

=== Display ===

Wallets SHOULD parse recipient information in the form `user`@`domain` and resolve such entry into 
recipient information using the above record. Similarly, wallets accepting payment information from 
external devices (e.g. hardware wallets) SHOULD accept RFC 9102-formatted proofs (as a series of 
unsorted `AuthenticationChain` records) and, if they verify, SHOULD display the recipient in the 
form `user`@`domain`.

== Rationale ==

There are many existing schemes to resolve human-readable names to cryptocurrency payment 
instructions. Sadly, these current schemes suffer from a myriad of drawbacks, including (a) lacking 
succinct proofs of namespace to public key mappings, (b) revealing sender IP addresses to recipients 
or other intermediaries as a side-effect of payment, (c) relying on the bloated TLS Certificate 
Authority infrastructure, or (d) lacking open access, not allowing anyone to create a namespace mapping.

=== DNS Rather than blockchain-based solutions ===
There are many blockchain-based alternatives to the DNS which feature better censorship-resistance 
and, in many cases, security. However, here we chose to use the standard ICANN-managed DNS namespace 
as many blockchain-based schemes suffer from (a), above (though in some cases this could be 
addressed with cryptographic SNARK schemes). Further, because they do not have simple client-side 
querying ability, many of these schemes use trusted intermediaries which resolve names on behalf of 
clients. This reintroduces drawbacks (b) and often (c) as well.

Finally, its worth noting that none of the blockchain-based alternatives to the DNS have had 
material adoption outside of their specific silos, and committing Bitcoin wallets to rely on a 
separate system which doesn't see broad adoption may not be sustainable.

=== DNS Rather than HTTP-based solutions ===
HTTP(s)-based payment instruction resolution protocols suffer from drawbacks (a), (b), and (c), 
above, and generally shouldn't be considered a serious alternative for payment instruction resolution.

=== Private DNS Querying ===
While public recursive DNS resolvers are very common (e.g. 1.1.1.1, 8.8.8.8, and 9.9.9.9), using 
such resolvers directly (even after validating DNSSEC signatures) introduces drawback (b), at least 
in regard to a centralized intermediary. Resolving payment instructions recursively locally would 
instead introduce drawback (b) directly to the recipient, which may well be worse.

For payers not using VPN or other proxying technologies, they generally trust their ISP for 
protection against denial of service anyway, so using ISP-provided recursive DNS resolvers is 
sufficient.

However, for the best privacy, payers are encouraged to perform DNS resolution over Tor or another 
VPN technology.

Lightning payers should consider utilizing DNS resolution over native onion messages, using the 
protocol described in [[BLIP 32|https://github.com/lightning/blips/blob/master/blip-0032.md]]

=== DNS Enumeration ===

In most cases where payments are accepted from any third-party, user enumeration is practical by 
simply attempting to send small value payments to a list of possible user names. However, storing 
all valid users in the DNS directly may make such enumeration marginally more practical. Thus, those 
wishing to avoid such enumeration should carefully ensure all DNS names return valid payment 
instructions. Note when doing so that wildcard records are identified as such by the DNSSEC RRSIG 
labels counter and are differentiable from non-wildcard records.

== Examples ==

[email-masked]` resolves to
`matt.user._bitcoin-payment.mattcorallo.com. 3600 IN TXT 
"bitcoin:?b12=lno1qsgqmqvgm96frzdg8m0gc6nzeqffvzsqzrxqy32afmr3jn9ggkwg3egfwch2hy0l6jut6vfd8vpsc3h89l6u3dm4q2d6nuamav3w27xvdmv3lpgklhg7l5teypqz9l53hj7zvuaenh34xqsz2sa967yzqkylfu9xtcd5ymcmfp32h083e805y7jfd236w9afhavqqvl8uyma7x77yun4ehe9pnhu2gekjguexmxpqjcr2j822xr7q34p078gzslf9wpwz5y57alxu99s0z2ql0kfqvwhzycqq45ehh58xnfpuek80hw6spvwrvttjrrq9pphh0dpydh06qqspp5uq4gpyt6n9mwexde44qv7lstzzq60nr40ff38u27un6y53aypmx0p4qruk2tf9mjwqlhxak4znvna5y"`
Note that `b12` indicates a value containing a lightning BOLT12 offer.

== Reference Implementations ==
* A DNSSEC proof generation and validation implementation can be found at 
https://git.bitcoin.ninja/index.cgi?p=dnssec-prover;a=summary
* A lightning-specific name to payment instruction resolver can be found at 
https://git.bitcoin.ninja/index.cgi?p=lightning-resolver;a=summary
* Reference implementations for parsing the URI contents can be found in [[bip-0021.mediawiki|BIP 21]].

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/34eaef2a-b53f-4622-a620-a3bc5161cbf7%40mattcorallo.com.