Add BIP 353: DNS Payment Instructions

[TheBlueMatt]

User behavior has clearly indicated a strong demand for the resolution of human-readable names into payment instructions. This BIP defines a protocol to do so using only the DNS, providing for the ability to query such resolutions privately, while utilizing DNSSEC to provide compact and simple to verify proofs of mappings.

I'd like to hereby request a BIP number assignment. What is the current approach to do so - since the mailing list has died, is a post on delving bitcoin the appropriate place to publish BIP drafts?

[casey]

I like this! It's implicit in the example, but maybe say explicitly that the combination of USER + DOMAIN should be rendered as an email address, i.e., USER@DOMAIN.

[sr-gi]

What is the current approach to do so - since the mailing list has died, is a post on delving bitcoin the appropriate place to publish BIP drafts?

This was just announced yesterday, but looks like https://groups.google.com/group/bitcoindev will be the new mailing list hosting (?)

[kristapsk]

This example contradicts statement above that "This BIP proposes a standard format for encoding BIP 21 URI schemes in DNS TXT records", as according to BIP21 onchain address in URI is required not optional component.

[TheBlueMatt]

Ha good catch. We should change BIP 21 lol

[kristapsk]

Or this spec could be altered, that it could be not just BIP21, but also plain BOLT12, for example. Wtih BIP21 there is currently two problems - address reuse (which could be solved with silent addresses in the future) and unability to do micropayments (which are possible onchain only with payjoin, if payer is ok paying more in tx fees than actual amount).

[TheBlueMatt]

In practice BIP 21 URIs in the wild sometimes don't have an on-chain address. The spec shouldn't mandate it given it's not required to function.

[alexgleason]

IMO a .well-known path would be better. Among things that use internet identifiers, Mastodon, Nostr, and Lightning all use .well-known paths. Only email and Bluesky use DNS records. Resolving DNS records has a higher barrier in most environments, and is nearly impossible to resolve in client-side JS without relying on a third-party service.

[harding]

IMO a .well-known path would be better. Among things that use internet identifiers, Mastodon, Nostr, and Lightning all use .well-known paths. Only email and Bluesky use DNS records. Resolving DNS records has a higher barrier in most environments, and is nearly impossible to resolve in client-side JS without relying on a third-party service.

@alexgleason the draft BIP addresses this directly with its own concerns in the opposite direction: "(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".

I'm not actually sure I understand (a), but (b) and (c) seem like really strong points to me.

[kristapsk]

(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

You could allow HTTP .well-known with .onion / .i2p, then these two problems disappear (but other problems arises, of course, for example, Tor is often not reliable on phones, etc).

Probably both DNS TXT and HTTP(S) .well-known methods could be standardized.

[alexgleason]

I'm not actually sure I understand (a), but (b) and (c) seem like really strong points to me.

It means that just because you can upload a file to a .well-known path, doesn't mean you actually own the domain.

As for (c), the "bloated TLS stack" is pretty convenient to deal with in most languages. You are likely doing HTTP stuff anyway, but for DNS you'll need to add a new library and learn how to use it. It's less developer friendly.

The privacy concern of (b) is understandable. But IMO it's the wrong trade-off, because it's inconvenient while not even being fool-proof. You can track requests either way if you run a DNS server.

Also, importantly, if you're building a system to expose many addresses (not just one-offs), it becomes impractical to update DNS records for every new user. You HAVE to use a .well-known path. Any custodial service would need to do it like that.

[harding]

@alexgleason

for DNS you'll need to add a new library and learn how to use it. It's less developer friendly.

Sure. I think it's a tradeoff between that and the other disadvantages listed in the BIP. I think it'd be nice to have better privacy (at least in some cases) and not to tie Bitcoin standards to TLS.

if you're building a system to expose many addresses (not just one-offs), it becomes impractical to update DNS records for every new user. You HAVE to use a .well-known path. Any custodial service would need to do it like that.

Or they could just run their own DNS server connected to their database.

[TheBlueMatt]

(a) lacking succinct proofs of namespace to public key mappings

This one is quite important. If you want to have a hardware wallet (which is not online and does not have a TCP stack in it), you really want to be able to hand it a succinct cryptographic proof that the given name matches the given address. You cannot do this with TLS, but DNSSEC makes this trivial (I implemented a validation library http://http-dns-prover.as397444.net/)

Regarding HTTP "being simpler", I strongly disagree, actually. If you have a domain, adding a single TXT record to your DNS is generally incredibly simple. Sure, if you already have an HTTP server adding a file to it isn't that much work, but even then it's probably as much or more work than just going to your DNS control panel and adding a single record.

You could allow HTTP .well-known with .onion / .i2p, then these two problems disappear

Not at all, that's a lot of work for everyone trying to implement this. DNS you get this for free! You don't have to do a ton of work to integrate Tor everywhere (which has spotty success at best), you have a proxy already pre-configured on ~every internet-connected machine on the planet!

[TheBlueMatt]

Also, importantly, if you're building a system to expose many addresses (not just one-offs), it becomes impractical to update DNS records for every new user.

I believe you missed Bastien's original ML post or lightning/blips#32 - a custodial provider only needs to add one wildcard record for all users in the lightning context!

for DNS you'll need to add a new library and learn how to use it. It's less developer friendly.

Is probably worth pointing out that I went ahead and implemented all the required work, with a nice little library with only a few functions exposed. It's really not a lot of work to call one function, I promise :p

[knocte]

than just going to your DNS control panel and adding a single record.

Which is a manual task. Sure you could automate it somehow via a deployment, but it would involve using an orchestration tool (e.g. terraform) that works with the cloud provider you use to host your DNS records, which then would involve some kind of secret token use in your CI pipeline in case you use that as a deployment (and in this case, a CI pipeline would need to normally be triggered by a git push of a tag or some sort of manual trigger, like workflow_dispatch in GitHubActions).

However, pushing/updating a file in your server (or the server being used for your website) is usually a task that is so much easier to automate. For example, if you're using github pages, just do a git push (not even a git tag push), and done.

[TheBlueMatt]

Which is a manual task.

Indeed, which seems perfectly reasonable for something you do once and never have to touch again!

[TheBlueMatt]

I like this! It's implicit in the example, but maybe say explicitly that the combination of USER + DOMAIN should be rendered as an email address, i.e., USER@DOMAIN.

I'm actually kind of torn on this. I'm no UX expert, but I've seen some legitimate points raised around how this is a bit confusing given users actually confuse them for email addresses. Other systems have gone another way (eg mastodon with @user@domain or bluesky with just user.domain) seemingly for this reason.

The nice thing about USER@DOMAIN is that its compatible with existing LNURL (senders can just query DNS and fall back to LNURL when it fails and recipients can thus upgrade as they see fit), but we could also do other things which are subtly compatible but provide UX distinction, eg $user@domain (which is still compatible with LNURL though the $ is very US-centric).

This was just announced yesterday, but looks like https://groups.google.com/group/bitcoindev will be the new mailing list hosting (?)

Indeed, just seems like given the lack of subscribers there that may or may not meet the BIP criteria of posting to the bitcoin-dev ML as a formal part of the BIP proposal process.

[Nuhvi]

DNS is great, but its "censorship resistance" can be improved upon (reach the highest possible level) with minimal overhead, by using Mainline DHT as the Root server, and public keys as the TLDs, all of which is already implemented and stress tested to a degree.

If this bip gains traction, it wouldn't be too much extra work to ask clients to recognize these sovereign TLDs.

[fluffypony]

Why not just use OpenAlias, which is already supported in Electrum?

[riccardobl]

From a logical stand point DNS should be preferable, it was invented for this after all, however there are some reasons for which i believe .well-known in reality is a much superior choice:

• DNS cannot be queried from webapps or extensions: this would force webapps to proxy resolutions to a server
• DNS doesn't give you the absolute control on record caching: you can hint a TTL, but it is not guaranteed to be respected (the infamous up to 24 hours for propagation...)
• HTTPS is supported by virtually every device that needs to connect to the internet, encrypted DNS is not or not always enabled by default. If encrypted DNS is not enabled, your isp can know your payment intentions, contrary to only the ip hosting the .well-known path.

If this needs to be a standard that is future proof and flexible, the .well-known approach can be integrated in all existing environments in a secure and decentralized manner and it can update in realtime.

[Nuhvi]

DNS cannot be queried from webapps or extensions: this would force webapps to proxy resolutions to a server

Wrong. DoH exists and is encouraged.

DNS doesn't give you the absolute control on record caching: you can hint a TTL, but it is not guaranteed to be respected (the infamous up to 24 hours for propagation...)

You can't control HTTP caching either if you want the same distributed nature of DNS caching. If you want strong consistency, clients can always choose to query the Authoritative DNS server directly disregarding caching. This is not a valid point.

HTTPS is supported by virtually every device that needs to connect to the internet, encrypted DNS is not or not always enabled by default. If encrypted DNS is not enabled, your resolver can know your payment intentions, contrary to only the ip hosting the .well-known path.

See DoH

If this needs to be a standard that is future proof and flexible, the .well-known approach can be integrated in all existing environments in a secure and decentralized manner and it can update in realtime.

DNS will outlast every adhoc protocol/format you build on top of .well-known. DNS is natively supported in every OS, DoH is just as supported in browsers as .well-known, and DNS is distributed by nature unlike web servers, and realtime updates (consistency) is possible through ignoring caching and querying the authoritative server directly.

[riccardobl]

Wrong. DoH exists and is encouraged.

this would force webapps to proxy resolutions to a server

The DoH provider is your proxy server. If you don't use the ISP/locally provided dns resolver, it means you need to hardcode a resolver in your webapp (dns over http standard or anything else, doesn't make a difference), actually you need a resolver that exports cors headers, meaning probably cloudflare or google and few others... not so decentralized i'd say

You can't control HTTP caching either if you want the same distributed nature of DNS caching.

This is false, you actually can tell the client how long the cache should be considered valid and check for changes, using the access control headers and etag, you can also cache until a new version is available. The key point here is that you can instruct the client to adapt to your use case, this is not possible with DNS.

choose to query the Authoritative DNS server directly disregarding caching

The authoritative DNS servers that support DoH?

[TheBlueMatt]

Why not just use OpenAlias, which is already supported in Electrum?

First of all i wasn't aware of it until today :). However, while it seems to be conceptually similar in many ways (as far as I can tell the only concrete difference is it's looking up a different name?), this is a more concrete and extensible format for bitcoin payment instructions for wallets which already support and have logic for handling BIP 21 URIs (basically all wallets). AFAICT you could define "Bitcoin payment instructions" as encoding bitcoin: URIs in the openalias names specifically and thus "use OpenAlias", but (a) you'd still need a BIP like this defining the format and (b) the OpenAlias names clutter the existing domain records, which is undesirable compared to using a clearly Bitcoin-specific name. For example, getting someone to "add TXT record "random gibberish" to their domain is fairly normal to verify a domain name for some service, but one which includes "_bitcoin-payment" in the name less so :). Ultimately I'm not sure what difference "supporting OpenAlias" would bring here, aside from an extra "oa1:" in the TXT record itself and a slightly less descriptive query name.

[TheBlueMatt]

Please don't bother commenting any further here that "this should use HTTP". If that's your take please read the text of the BIP which clearly explains why HTTP is horribly unsuited to this goal, and if you still disagree go quite your own spec instead. That's not changing here.

[fluffypony]

Ultimately I'm not sure what difference "supporting OpenAlias" would bring here, aside from an extra "oa1:" in the TXT record itself and a slightly less descriptive query name.

There's a working group (#openalias on Libera) seeking to define an OA v2 standard to solve some of the points you raise, as well as adding pathing (eg. if you're sending USDT then these are the chain priorities I want for receiving it). I think my only thinking here is that pushing for OpenAlias (via a BIP or otherwise) is beneficial for five reasons:

1. It is extensible enough to support BTC L2s, LN, Ark, etc.
2. XKCD standards comic🤭
3. It already has wallet support in Electrum, which is good groundwork
4. OpenAlias has some fundamental support for DNSCrypt lookups, which are good from a privacy perspective
5. We've done the heavy lifting in terms of figuring out how the UX should react to a DNSSEC failure / unavailability

Either way, I'll support this as a Bitcoin-only mechanism and/or a BIP that aligns with a hypothetical, improved OA v2.

[TheBlueMatt]

It is extensible enough to support BTC L2s, LN, Ark, etc.

So is this, by reusing logic any wallets already have.

XKCD standards comic🤭
It already has wallet support in Electrum, which is good groundwork

Fair, but you're suggesting a to-be-defined v2 spec, which is incompatible anyway, so not sure defining a new one is bad :).

OpenAlias has some fundamental support for DNSCrypt lookups, which are good from a privacy perspective

So does any DNS proposal?

We've done the heavy lifting in terms of figuring out how the UX should react to a DNSSEC failure / unavailability

I mean I'm not sure what heavy lifting there is to do here? The answer is "payment fails" :).

Either way, I'll support this as a Bitcoin-only mechanism and/or a BIP that aligns with a hypothetical, improved OA v2.

Fair enough, and I'm happy to provide input on a OA v2, it'd be cool if it kinda codified basically this, with different URIs for other non-bitcoin protocols. Also happy to tweak the paths here slightly if it makes sense to be compatible and don't introduce other drawbacks, but IMO this should still stand on its own to define bitcoin-specific logic.

[dipunm]

When do you encounter multiple matching TXT records?

Is this due to querying twice and getting different results due to TTL?

Or a malformed TXT record: "bitcoin:........;bitcoin:......"

Or just two independent TXT records with the same key and different values?

[TheBlueMatt]

Two TXT records.

[jojkaart]

If I had to guess at the rationale, this is meant to protect against the particular kind of configuration error where you intend to update the record, but mistakenly end up adding another instead. This protects against bitcoins getting sent to lost or compromised addresses.

[TheBlueMatt]

Honestly I didn't have a specific issue in mind more a general feeling that issues could crop up, this is a good example of one such issue.

[hsjoberg]

Wrong. DoH exists and is encouraged.

What would be the benefit if DoH has to be used? You could just do LNURL-pay then.

[moneyball]

What would be the benefit if DoH has to be used? You could just do LNURL-pay then.

LNURL-pay must be called for every payment. With BOLT 12 offers, DoH is only called once to fetch the offer. All subsequent payments avoid this thus improved censorship resistance and privacy. (and security, as the invoice isn't being served by the LNURL server).

[fluffypony]

Fair enough, and I'm happy to provide input on a OA v2, it'd be cool if it kinda codified basically this, with different URIs for other non-bitcoin protocols. Also happy to tweak the paths here slightly if it makes sense to be compatible and don't introduce other drawbacks, but IMO this should still stand on its own to define bitcoin-specific logic.

I agree with this - if we could come up with a BIP that aligns with OA v2 that would be amazing, then it really harmonizes things for anything built on top of Bitcoin / sidechains / alt-layers, including tokens like USDT.

[TheBlueMatt]

What would be the benefit if DoH has to be used? You could just do LNURL-pay then.

Please read the BIP text, specifically drawbacks (a), (b), and (c). Note that (b) applies as clients can select a DoH provider who commits to not log individual queries but with direct connection that doesn't exist. Further, a DoH provider is substantially less likely to geoblock whereas LNURL-pay providers already do.

[benthecarman]

Could also add a note that you could add payjoin parameters to the URI

[TheBlueMatt]

Do you mean that that would address the address reuse concern? I'm not quite sure how.

[DanGould]

A payjoin receiver can substitute the original request's payment output address with a freshly generated one via output substitution in the happy path. Is this what you mean @benthecarman

[TheBlueMatt]

Right, the spec here is designed to be usable by lightning/fedimint/cashu/payjoin/silent payments/etc/etc. I'm not quite sure I understand why that's relevant to this particular section.

[benthecarman]

Because if you had pay join params with the bitcoin address then you wouldn't reuse the address with people who understand pay join

[TheBlueMatt]

Right, but in that case couldn't you specify bitcoin:?payjoin_info=... and skip the on-chain address entirely? You'd still have the address reuse problem for senders not supporting payjoin.

[DanGould]

A sender requires some address to form a request including the fallback original psbt before the receiver responds with the payjoin psbt including their utxo, that way the sender can sign and complete the payjoin, or the receiver can broadcast the "original" transaction and hasn't revealed their utxo without a cost. This prevents probing attacks where a sender tries to see receiver utxos for free.

[dzdidi]

SHOULD be rotated as regularly as possible to reduce address reuse

There is no mention of caching which may happen on multiple layers. TTLs (label specific) can be leveraged to minimize potential non-desired reuse.

[TheBlueMatt]

Rewrote this a bit, let me know if it covers the payjoin concern sufficiently (I don't want to mention any specific exemptions here).

[DanGould]

The change looks good to me.

[casey]

Another thought: the parsing of USER@DOMAIN is pretty trivial, but how to do it should be mentioned.

[TheBlueMatt]

Another thought: the parsing of USER@DOMAIN is pretty trivial, but how to do it should be mentioned.

Agreed, I'd like to add a section on displaying this info, but not sure if you saw my comment at #1551 (comment) - I'd like to discuss whether we want specifically USER@DOMAIN for a bit first. Do you have any opinion on that?

[murchandamus]

I did a light review.

Beside the missing fields in the preamble, please include a license and add the mandatory Backwards Compatibility section, even if it is just to say that there are no conflicts.

[TheBlueMatt]

Done!

[murchandamus]

Almost ready, I just noticed a few more minor issues:

• Please add the missing Copyright section (via BIP2: BIP Licensing: Specification):

  In all cases, details of the licensing terms must be provided in the Copyright section of the BIP.

and see the individual comments I left.

[murchandamus]

As mentioned above the page is 404, but also in mediawiki format, links are encoded [[url|name]] instead of [[name|url]].

Suggested change

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

[murchandamus]

Changes look good to me. This document now fulfills the BIP formatting requirements.

[murchandamus]

Let’s call this BIP 353.

Please amend your document to use the number 353 and add the corresponding table entry to README.mediawiki.

[TheBlueMatt]

Done

[murchandamus]

LGTM, except that you might want to fix the typo. ;)

[TheBlueMatt]

🤦

[murchandamus]

ACK 4f75edb

[Sjors]

Followup PR to clarify the ₿-prefix instructions: #1645