Delivery-date: Tue, 13 Feb 2024 13:12:47 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99;
Message-ID: <34eaef2a-b53f-4622-a620-a3bc5161cbf7@mattcorallo.com>
Date: Tue, 13 Feb 2024 11:56:38 -0800
MIME-Version: 1.0
From: Matt Corallo <lf-lists@mattcorallo.com>
Subject: [bitcoindev] Mapping Human-Readable Names to Payment Instructions
Content-Language: en-US
References: <3452d0b7-2d46-46bd-a59d-5b1206d882d0@mattcorallo.com>
To: bitcoindev@googlegroups.com
In-Reply-To: <3452d0b7-2d46-46bd-a59d-5b1206d882d0@mattcorallo.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


Hey new-list!

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

Matt


=3D=3DAbstract=3D=3D
This BIP proposes a standard format for encoding [[bip-0021.mediawiki|BIP 2=
1]] URI schemes in DNS=20
TXT records.

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

The DNS provides a standard, global, hierarchical namespace mapping human-r=
eadable labels to records=20
of various forms. Using DNSSEC, the DNS provides cryptographic guarantees u=
sing a straightforward=20
PKI which follows the hierarchical nature of the DNS, allowing for stateles=
s and even offline=20
validation of DNS records from a single trusted root.

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

Thus, using TXT records to store Bitcoin payment instructions allows for hu=
man-readable Bitcoin=20
payment destinations which can be trivially verified on hardware wallets an=
d which can be resolved=20
relatively privately.

=3D=3DSpecification=3D=3D

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

=3D=3D=3D Records =3D=3D=3D
Payment instructions are indexed by both a user and a domain. Instructions =
for a given `user` and=20
`domain` are stored at `user`.user._bitcoin-payment.`domain` in a single TX=
T 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=20
ultimate records pointed to by them are DNSSEC signed.

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

=3D=3D=3D Resolution =3D=3D=3D

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

Clients resolving Bitcoin payment instructions MUST fully validate DNSSEC s=
ignatures leading to the=20
DNS root (including any relevant CNAME or DNAME records) and MUST NOT accep=
t DNSSEC signatures which=20
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 reso=
lver to validate DNSSEC=20
records on their behalf.

Clients resolving Bitcoin payment instructions MUST support resolving throu=
gh CNAME or DNAME records.

Resolvers MAY support resolving non-ASCII user and domain identifiers. Reso=
lvers which do support=20
non-ASCII user and domain identifiers MUST take precautions to prevent homo=
graph attacks and SHOULD=20
consider denying paste functionality when entering non-ASCII identifiers.

=3D=3D=3D Address Reuse =3D=3D=3D

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

=3D=3D=3D Display =3D=3D=3D

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

=3D=3D Rationale =3D=3D

There are many existing schemes to resolve human-readable names to cryptocu=
rrency payment=20
instructions. Sadly, these current schemes suffer from a myriad of drawback=
s, including (a) lacking=20
succinct proofs of namespace to public key mappings, (b) revealing sender I=
P addresses to recipients=20
or other intermediaries as a side-effect of payment, (c) relying on the blo=
ated TLS Certificate=20
Authority infrastructure, or (d) lacking open access, not allowing anyone t=
o create a namespace mapping.

=3D=3D=3D DNS Rather than blockchain-based solutions =3D=3D=3D
There are many blockchain-based alternatives to the DNS which feature bette=
r censorship-resistance=20
and, in many cases, security. However, here we chose to use the standard IC=
ANN-managed DNS namespace=20
as many blockchain-based schemes suffer from (a), above (though in some cas=
es this could be=20
addressed with cryptographic SNARK schemes). Further, because they do not h=
ave simple client-side=20
querying ability, many of these schemes use trusted intermediaries which re=
solve names on behalf of=20
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=20
material adoption outside of their specific silos, and committing Bitcoin w=
allets to rely on a=20
separate system which doesn't see broad adoption may not be sustainable.

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

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

For payers not using VPN or other proxying technologies, they generally tru=
st their ISP for=20
protection against denial of service anyway, so using ISP-provided recursiv=
e DNS resolvers is=20
sufficient.

However, for the best privacy, payers are encouraged to perform DNS resolut=
ion over Tor or another=20
VPN technology.

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

=3D=3D=3D DNS Enumeration =3D=3D=3D

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

=3D=3D Examples =3D=3D

`matt@mattcorallo.com` resolves to
`matt.user._bitcoin-payment.mattcorallo.com. 3600 IN TXT=20
"bitcoin:?b12=3Dlno1qsgqmqvgm96frzdg8m0gc6nzeqffvzsqzrxqy32afmr3jn9ggkwg3eg=
fwch2hy0l6jut6vfd8vpsc3h89l6u3dm4q2d6nuamav3w27xvdmv3lpgklhg7l5teypqz9l53hj=
7zvuaenh34xqsz2sa967yzqkylfu9xtcd5ymcmfp32h083e805y7jfd236w9afhavqqvl8uyma7=
x77yun4ehe9pnhu2gekjguexmxpqjcr2j822xr7q34p078gzslf9wpwz5y57alxu99s0z2ql0kf=
qvwhzycqq45ehh58xnfpuek80hw6spvwrvttjrrq9pphh0dpydh06qqspp5uq4gpyt6n9mwexde=
44qv7lstzzq60nr40ff38u27un6y53aypmx0p4qruk2tf9mjwqlhxak4znvna5y"`
Note that `b12` indicates a value containing a lightning BOLT12 offer.

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

--=20
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 e=
mail 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.