* [bitcoindev] Mapping Human-Readable Names to Payment Instructions
[not found] <3452d0b7-2d46-46bd-a59d-5b1206d882d0@mattcorallo.com>
@ 2024-02-13 19:56 ` Matt Corallo
0 siblings, 0 replies; only message in thread
From: Matt Corallo @ 2024-02-13 19:56 UTC (permalink / raw)
To: bitcoindev
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 ==
`matt@mattcorallo•com` 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/34eaef2a-b53f-4622-a620-a3bc5161cbf7%40mattcorallo.com.
^ permalink raw reply [flat|nested] only message in thread