Add BIP 353: DNS Payment Instructions #1551

TheBlueMatt commented at 10:49 PM on February 10, 2024: contributor

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 commented at 12:38 AM on February 11, 2024: none

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 commented at 12:41 AM on February 11, 2024: member

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 (?)

in bip-XXXX.mediawiki:78 in d46a29ff4b outdated

  73 | +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]]
  74 | +
  75 | +== Examples ==
  76 | +
  77 | +`matt@mattcorallo.com` resolves to
  78 | +`matt.user._bitcoin-payment.mattcorallo.com. 3600 IN TXT	"bitcoin:?b12=lno1qsgqmqvgm96frzdg8m0gc6nzeqffvzsqzrxqy32afmr3jn9ggkwg3egfwch2hy0l6jut6vfd8vpsc3h89l6u3dm4q2d6nuamav3w27xvdmv3lpgklhg7l5teypqz9l53hj7zvuaenh34xqsz2sa967yzqkylfu9xtcd5ymcmfp32h083e805y7jfd236w9afhavqqvl8uyma7x77yun4ehe9pnhu2gekjguexmxpqjcr2j822xr7q34p078gzslf9wpwz5y57alxu99s0z2ql0kfqvwhzycqq45ehh58xnfpuek80hw6spvwrvttjrrq9pphh0dpydh06qqspp5uq4gpyt6n9mwexde44qv7lstzzq60nr40ff38u27un6y53aypmx0p4qruk2tf9mjwqlhxak4znvna5y"`

kristapsk commented at 12:41 AM on February 11, 2024:

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 commented at 5:00 AM on February 11, 2024:

Ha good catch. We should change BIP 21 lol

kristapsk commented at 1:59 PM on February 11, 2024:

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 commented at 5:55 PM on February 11, 2024:

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 commented at 12:55 AM on February 11, 2024: none

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 commented at 1:26 AM on February 11, 2024: contributor

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 commented at 1:32 AM on February 11, 2024: none

(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 commented at 2:36 AM on February 11, 2024: none

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 commented at 3:57 AM on February 11, 2024: contributor

@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 commented at 5:06 AM on February 11, 2024: contributor

(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 commented at 5:11 AM on February 11, 2024: contributor

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 https://github.com/lightning/blips/pull/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 commented at 5:21 AM on February 11, 2024: none

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 commented at 5:24 AM on February 11, 2024: contributor

Which is a manual task.

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

TheBlueMatt commented at 5:51 AM on February 11, 2024: contributor

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 commented at 6:32 AM on February 11, 2024: none

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 commented at 7:20 AM on February 11, 2024: none

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

riccardobl commented at 9:03 AM on February 11, 2024: none

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 commented at 9:13 AM on February 11, 2024: none

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 commented at 9:50 AM on February 11, 2024: none

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 commented at 9:55 AM on February 11, 2024: contributor

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 commented at 10:04 AM on February 11, 2024: contributor

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 commented at 10:10 AM on February 11, 2024: none

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:

It is extensible enough to support BTC L2s, LN, Ark, etc.
XKCD standards comic🤭
It already has wallet support in Electrum, which is good groundwork
OpenAlias has some fundamental support for DNSCrypt lookups, which are good from a privacy perspective
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 commented at 10:23 AM on February 11, 2024: contributor

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.

in bip-XXXX.mediawiki:43 in d46a29ff4b outdated

  36 | +
  37 | +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]].
  38 | +
  39 | +=== Resolution ===
  40 | +
  41 | +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.

dipunm commented at 11:56 AM on February 11, 2024:

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 commented at 5:15 PM on February 11, 2024:

Two TXT records.

jojkaart commented at 7:47 AM on February 12, 2024:

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 commented at 6:19 PM on February 12, 2024:

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 commented at 1:19 PM on February 11, 2024: none

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 commented at 3:38 PM on February 11, 2024: contributor

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 commented at 3:59 PM on February 11, 2024: none

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 commented at 5:14 PM on February 11, 2024: contributor

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.

in bip-XXXX.mediawiki:52 in d46a29ff4b outdated

  47 | +Clients resolving Bitcoin payment instructions MUST support resolving through CNAME or DNAME records.
  48 | +
  49 | +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.
  50 | +
  51 | +=== Address Reuse ===
  52 | +Payment instructions with on-chain addresses SHOULD be rotated as regularly as possible to reduce address reuse. In cases where this is not practical, payment instructions SHOULD NOT contain on-chain addresses (i.e. the URI path SHOULD be empty).

benthecarman commented at 5:24 PM on February 11, 2024:

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

TheBlueMatt commented at 5:53 PM on February 11, 2024:

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

DanGould commented at 5:58 PM on February 11, 2024:

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 commented at 6:13 PM on February 11, 2024:

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 commented at 6:15 PM on February 11, 2024:

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 commented at 6:25 PM on February 11, 2024:

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 commented at 7:00 PM on February 11, 2024:

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 commented at 12:25 PM on February 12, 2024:

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 commented at 6:50 PM on February 12, 2024:

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 commented at 6:37 PM on June 8, 2024:

The change looks good to me.

casey commented at 6:13 PM on February 11, 2024: none

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

TheBlueMatt commented at 6:26 PM on February 11, 2024: contributor

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?

alexgleason commented at 6:35 PM on February 11, 2024: none

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!

I've been trying very hard to understand this. How could a wildcard record solve the problem? Where would names be stored so they can be associated with keys, and how can a wildcard record get us there (eg what would its value be)?

TheBlueMatt commented at 7:24 PM on February 11, 2024: contributor

I've been trying very hard to understand this. How could a wildcard record solve the problem? Where would names be stored so they can be associated with keys, and how can a wildcard record get us there (eg what would its value be)?

Lets take this discussion to https://github.com/lightning/blips/pull/32 since its lightning- (or other payment protocols) specific. The doc there explains how it works for LN, but other payment protocols that want to support this will need some mechanism to flag a payment as for a given user inline as a part of the payment.

corviato1 commented at 8:52 PM on February 11, 2024: none

Maybe look into Namecoin and Raven for code inspiration, then close this pull request, then make a new pull request with code examples from the before mentioned platforms that can be migrated to Bitcoin?

From there, devs can review and help turn what you want into a reality.

That being said, implementation would probably be best done at a layer two due to security and efficiency concerns.

in bip-XXXX.mediawiki:95 in d46a29ff4b outdated

  68 | +
  69 | +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.
  70 | +
  71 | +However, for the best privacy, payers are encouraged to perform DNS resolution over Tor or another VPN technology.
  72 | +
  73 | +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]]

jonasnick commented at 8:53 AM on February 12, 2024:

File not found

t-bast commented at 12:08 PM on February 12, 2024:

I guess that's because Matt used the link that will work once that bLIP is merged, since we expect bLIPs to be merged more quickly than BIPs :)

dzdidi commented at 12:09 PM on February 12, 2024:

Not merged yet https://github.com/lightning/blips/pull/32/files

murchandamus commented at 7:40 PM on May 21, 2024:

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

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]]

TheBlueMatt commented at 7:54 PM on May 28, 2024:

I'll make sure it gets merged before this does :)

in bip-XXXX.mediawiki:35 in d46a29ff4b outdated

  30 | +=== Records ===
  31 | +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.
  32 | +
  33 | +All payment instructions MUST be DNSSEC-signed.
  34 | +
  35 | +Payment instructions MAY resolve through CNAME or DNAME records as long as all relevant records are DNSSEC signed.

t-bast commented at 11:50 AM on February 12, 2024:

It would be useful to link to an RFC detailing what additional data should be signed and verified in those cases, does that exist?

TheBlueMatt commented at 6:15 PM on February 12, 2024:

Hmm, certainly not at a high level, I can add a few words just saying that all the CNAME/DNAME records as well as the records they point to must be signed.

in bip-XXXX.mediawiki:37 in d46a29ff4b outdated

  32 | +
  33 | +All payment instructions MUST be DNSSEC-signed.
  34 | +
  35 | +Payment instructions MAY resolve through CNAME or DNAME records as long as all relevant records are DNSSEC signed.
  36 | +
  37 | +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]].

t-bast commented at 11:51 AM on February 12, 2024:

Is this really worth supporting (instead of restricting to ASCII characters)? This forces all clients to potentially support those encodings, which is a likely source of issues...

TheBlueMatt commented at 6:18 PM on February 12, 2024:

Maybe not, I mean punycode itself is pretty easy, but dealing with homograph attacks is...quite nontrivial. So, indeed, I'm down to just remove all the non-ASCII support.

in bip-XXXX.mediawiki:31 in d46a29ff4b outdated

  26 | +
  27 | +=== General rules for handling ===
  28 | +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.
  29 | +
  30 | +=== Records ===
  31 | +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.

t-bast commented at 12:06 PM on February 12, 2024:

Out of curiosity, why the leading underscore (_bitcoin-payment), is that a best practice?

TheBlueMatt commented at 6:11 PM on February 12, 2024:

Yea, just makes it less likely to collide with any existing actual domain names that exist in the wild.

in bip-XXXX.mediawiki:6 in d46a29ff4b outdated

   0 | @@ -0,0 +1,84 @@
   1 | +<pre>
   2 | +  BIP: XXXX
   3 | +  Layer: Applications
   4 | +  Title: DNS Payment Instructions
   5 | +  Author: Matt Corallo <bipxxx@bluematt.me>
   6 | +          Bastien (once I confirm he wants to be listed here, but its his idea)

t-bast commented at 12:07 PM on February 12, 2024:

You can use the following here, thanks!

          Bastien Teinturier <bastien@acinq.fr>

t-bast commented at 12:08 PM on February 12, 2024: contributor

Concept ACK :rocket: , thanks for going through the effort of writing this down in BLIP format!

niftynei commented at 2:13 PM on February 12, 2024: none

Great idea. @alexgleason asks:

a custodial provider only needs to add one wildcard record for all users in the lightning context!

How could a wildcard record solve the problem?

I had the same question. If I understand correctly, wildcard resolutions return the same record for any subdomain, for a central service this would point to the general centralized service's node. You're correct in that you'd then need a secondary lookup mechanism.

If you look through the proposed BLIP/BOLTs that are linked in this document, @TheBlueMatt has further defined an onion message protocol that allows you to request a custom offer for a specified user using onion messages.

The BLIP proposal states the following:

Alternatively, for recipients which do not wish to publish a unique offer for all possible payees,
a wildcard record may be provisioned as *.user._bitcoin-payment.`domain` with the contents
`bitcoin:?omlookup=hex_encoded_blinded_path`. The node receiving onion messages at the given
blinded path is then expected to respond to `offer_request`-containing onion messages with
`offer_response`-containing onion messages.

The BOLT proposal for adding an offer_request and offer_response can currently be found here:

https://github.com/lightning/bolts/pull/1136/commits/5809dfd1fce7fe1233812acb25bd37b908318968

Correct me if I'm wrong but it may be useful for responding apps to provide any-amount BOLT12s as a response, such that wallets/requesting apps can cache these for future payments?

in bip-XXXX.mediawiki:16 in d46a29ff4b outdated

  11 | +</pre>
  12 | +
  13 | +==Abstract==
  14 | +This BIP proposes a standard format for encoding [[bip-0021.mediawiki|BIP 21]] URI schemes in DNS TXT records.
  15 | +
  16 | +==Motivation==

benma commented at 2:47 PM on February 12, 2024:

It would be very helpful if this section was extended with a number of concrete use cases and also mention which use cases are not covered or not a good fit.

At first this seems like an interesting solution to display domain names instead of addresses on hardware wallets for improved security, but for exchanges/brokers/merchants, they'd need a unique address per user and per deposit. For this use-case this does not seem to be a good fit. Downsides / blockers could be:

if it is generated on the fly during e.g. a deposit action on an exchange or a shop checkout of a merchant, the TXT record might not propagate quickly enough for the lookup to succeed
publishing a new address after the previous one has been used also might not propagate in time to prevent re-using an address
bad privacy for the merchant/exchange
not quite sure if it is practical to have a lot of txt records for services that serve a lot of users

TheBlueMatt commented at 8:05 PM on February 12, 2024:

if it is generated on the fly during e.g. a deposit action on an exchange or a shop checkout of a merchant, the TXT record might not propagate quickly enough for the lookup to succeed

This would violate Bitcoin wallets MUST NOT prefer to use DNS-based resolving when methods with explicit public keys are available.

publishing a new address after the previous one has been used also might not propagate in time to prevent re-using an address

That's okay. Address reuse prevention is probabilistic anyway.

bad privacy for the merchant/exchange

Hmm? If you're a merchant or exchange, you're probably already using a domain anyway :).

not quite sure if it is practical to have a lot of txt records for services that serve a lot of users

Yes, please see https://github.com/lightning/blips/pull/32 and its discussion of wildcard records :)

starius commented at 11:36 PM on February 13, 2024:

That's okay. Address reuse prevention is probabilistic anyway.

.well-known approach can prevent address reuse completely, if HTTP server generates new address for every request.

bumi commented at 11:30 PM on February 12, 2024: none

I love this push forward. <3 though I am in favor of openalias and what @fluffypony says. OpenAlias has been around for years. It works. It is extendable and apps just have to agree on a bunch of key/value pairs. I am wondering if a bitcoin specific spec is helpful here. For example OpenAlias can also be used for a Nostr identifier along with resolving payment information. So to me this problem is somewhat unrelated to the underlaying payment protocol.

hernanmarino commented at 5:07 AM on February 13, 2024: none

LGTM :)

droark commented at 9:25 PM on February 13, 2024: contributor

Hi! Just FYI, I helped with a similar document ~10 years ago. It was an IETF draft. It's here if you think it could be useful. A second draft was worked on with a lot more detail, including integrating BIP 32-style functionality, was written but not published for various reasons.

joedavison commented at 1:21 AM on February 14, 2024: none

MUST take precautions to prevent homograph attacks

This clause is vague. The specific precautions that must be taken should be specified, or this should be changed to MAY to allow for different interpretations of this clause.

casey commented at 9:20 PM on February 15, 2024: none

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?

Whoops, missed that!

I think I'd need to understand the potential issues with USER@DOMAIN better. Just off the top of my head:

A user might post a payment address, USER@DOMAIN, and then someone sees it and sends mail to it.
A user might post an email address, USER@DOMAIN, and then someone sees it and tries to send bitcoin to it.
A user posts a payment address, USER@DOMAIN, and people don't realize they can send bitcoin to it, because it looks like an email address.
A domain supports both mail and payments, but the mail usernames aren't the same as the payment usernames, so the recipients of mail and bitcoin sent to USER@DOMAIN are different.

4 seems pretty crazy. If a domain supports both but with different mapping of usernames to users, they should probably just not do that.

Assuming 4 isn't happening, than 1 and 2 don't seem like big issues. Mail to a non-existent address will be answered with a bounce messages, and making a payment to USER@DOMAIN, where USER either doesn't exist or DOMAIN doesn't support payment looks should also generate a good error message.

3 seems like not a huge problem. Users will probably be saying something like "please send me bitcoin at USER@DOMAIN", and there will probably be other contextual cues for whether it's a payment address or a mail address.

I personally like USER@DOMAIN much better than USER.DOMAIN or other weird formats, like @USER@DOMAIN.

A couple random thoughts:

When trying to get payment instructions for USER@DOMAIN, it would probably be good if the client could distinguish between USER being misspelled and DOMAIN not being configured to accept payments at all, so it can show the user a better error message.

Thus, those wishing to avoid such enumeration should carefully ensure all DNS names return valid payment instructions.

It should probably be noted that this is super dangerous, since this could lead to bitcoin not going to the intended recipient if you misspell the username.

TheBlueMatt commented at 9:49 PM on February 15, 2024: contributor

4, sadly, is happening currently on getalby.com :(. There's some further discussion on display at https://discord.com/channels/903125802726596648/1083667569355014144 and on https://github.com/BitcoinDesign/Meta/issues/638

moneyball commented at 11:03 PM on February 15, 2024: contributor

As pointed out here (https://github.com/BitcoinDesign/Meta/issues/638#issuecomment-1947454275), spam is a very different beast for email vs. money. No one wants spam email. Anyone would be happy to receive money from random people. By combining the two, users will be hesitant to publicize their email thus limiting their ability to publicize their money address.

casey commented at 11:06 PM on February 15, 2024: none

As pointed out here (BitcoinDesign/Meta#638 (comment)), spam is a very different beast for email vs. money. No one wants spam email. Anyone would be happy to receive money from random people. By combining the two, users will be hesitant to publicize their email thus limiting their ability to publicize their money address.

In that case, they could have a payment address at a different domain, so if their email address is foo@bar.com, their payment address could be foo@baz.com, and they can share their payment address freely without worrying about spam. I don't think how things are formatted makes a difference, since if they have the username foo and domain bar.com for both mail and payments, you could still guess the email address from the payment address, regardless of how the payment address is formatted.

cbergqvist commented at 10:03 PM on February 16, 2024: none

Related: Lightspark recently introduced Universal Money Address - $USER@DOMAIN (USER$DOMAIN might be tempting, but apparently used by XRP Paystrings). (How aboutUSER₿DOMAIN? - gotta milk that ₿ Unicode symbol and avoid $! :) )

joedavison commented at 10:58 PM on February 16, 2024: none

(How aboutUSER₿DOMAIN? - gotta milk that ₿ Unicode symbol and avoid $! :) )

Choosing a symbol that is not present on most keyboards would be a mistake, IMO.

knocte commented at 4:39 AM on February 17, 2024: none

Related: Lightspark recently introduced Universal Money Address - $USER@DOMAIN

Is there any chance that we can have either OpenAlias or UMA end up being BIPs themselves?

pinheadmz commented at 10:48 PM on February 17, 2024: member

I think this a reasonable proposal but also the authors should consider what OpenAlias has to offer as existing groundwork. As someone who has worked on a blockchain based naming system with succinct namespace proof, I definitely appreciate the awareness of hardware wallets, and being able to offer tiny proofs to limited systems.

My biggest concerns are:

Centralization of DNSSEC: ICANN (root), companies like Verisign (.com) and CentralNic (hosts TLDs and does all their DNSSEC signing) are central points of failure or address-swapping. That being said, posting your bitcoin address on a HTTPS website has exactly the same risks, plus more. BIP70 comes to mind...
Developers are afraid of DNS. Joe Average App Developer certainly knows how to make https requests, but retrieving and validating a DNSSEC chain might be out of their scope.
Address reuse. I'd love to see this protocol restricted to BOLT12 / LN keysend and Silent Payments (BIP352). That might be unreasonable. Recommending a short TTL is good, but only if you are running a nameserver with an xpub or table of static addresses (which I have sortof implemented before, and would happy to write a BIP-xxxx nameserver)

All this being said, I agree there is a clear demand and despite my concerns, this proposal is probably the quickest way to get something useful deployed. Be sure you answer my 10-year-old stack exchange question too :-)

https://bitcoin.stackexchange.com/questions/11390/is-anyone-developing-a-dns-like-system-for-bitcoin-addresses

TheBlueMatt commented at 2:44 AM on February 18, 2024: contributor

Centralization of DNSSEC: ICANN (root), companies like Verisign (.com) and CentralNic (hosts TLDs and does all their DNSSEC signing) are central points of failure or address-swapping. That being said, posting your bitcoin address on a HTTPS website has exactly the same risks, plus more. BIP70 comes to mind...

Indeed, ultimately any human-readable-name -> bitcoin payment instructions protocol is going to either (a) require some blockchain-based solution (which is a reasonable candidate, but the BIP addresses this in a general sense, noting that the lack of adoption of these solutions outside their vertical, and that requiring bitcoin wallets rely on these protocols is not yet, IMO, a reasonable candidate).

Luckily there's lots of diversity in terms of TLD operators to choose from, and while the root centralization is concerning, resolvers can AXFR the root zone manually (in fact most recursive resolvers have built-in support for this now!) and do it only infrequently if they wish.

Developers are afraid of DNS. Joe Average App Developer certainly knows how to make https requests, but retrieving and validating a DNSSEC chain might be out of their scope.

Sure, kinda. In terms of automating writing contents to the DNS that is largely true (though, frankly, IMO an indictment of Joe Average App Developer, since the DNS is genuinely an incredibly straightforward and simple system), but this spec addresses that in a few ways:

(a) on the receiving payments end, for average users its intended that users can simply add their own entry to their own zone. This is a one-time thing that is well-supported in most registrar/DNS host GUIs. (b) on the receiving end, for larger providers, at least on the lightning end, you can use BOLT12 to add a single record and receive payments for all users, seeing the user being paid via the invoice-request (linked the bLIP draft above). (c) on the receiving end, for larger providers not using lightning, I dunno, grow up, you're a large custodian, learn to take advantage of the technologies that exist or you shouldn't be a large custodian :shrug:.

On the sending end, I spent the time to implement a multi-tool to handle the querying/proof generation/validation, linked in the BIP. For lightning nodes, I wrote up a spec to allow fetching a proof from an arbitrary lightning node over onion messages, so the whole process never has to leave the lightning network! For others, the library linked handles querying against a DoH or TCP/53 server, and can run and do so from WASM or native code. If folks can't figure out how to make DNS requests with that much provided, not sure what to say :)

Address reuse. I'd love to see this protocol restricted to BOLT12 / LN keysend and Silent Payments (BIP352). That might be unreasonable. Recommending a short TTL is good, but only if you are running a nameserver with an xpub or table of static addresses (which I have sortof implemented before, and would happy to write a BIP-xxxx nameserver)

Yea, don't disagree, @rustyrussell pointed out that we should suggest rotation whenever a payment is received, which I think is sensible and may be somewhat doable for larger providers. For individuals adding their own records, sadly, I'm afraid address reuse would be somewhat common. That said, if we get BOLT12 and SP to be common-enough, even if a static address is in the record, most payments wont use it :)

in bip-XXXX.mediawiki:31 in 83c1343a03 outdated

  26 | +
  27 | +=== General rules for handling ===
  28 | +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.
  29 | +
  30 | +=== Records ===
  31 | +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.

pinheadmz commented at 12:51 PM on February 18, 2024:

I don't quite understand the scheme here. What is the purpose of the "user" label? (Future protocol expansions where something besides "users" can be identified?). Also why not order the labels with the underscores more like existing schemes for example, TLSA:

_443._tcp.mailhardener.com TLSA ...

So I'd expect something like:

_bitcoin-payment.matt.mattcorallo.com TXT ...

pinheadmz commented at 12:54 PM on February 18, 2024:

harding commented at 10:30 AM on February 19, 2024:

@pinheadmz

I'd expect something like:

_bitcoin-payment.matt.mattcorallo.com TXT ...

I'm not DNS expert, but the Wikipedia article about wildcard DNS entries says, "A wildcard DNS record is specified by using a * as the leftmost label (part) of a domain name, e.g. *.example.com." I think @TheBlueMatt wants to allow wildcards for the username portion for LN (see the proposed BIP21 parameter omlookup (onion message lookup) in this commit). If only the leftmost label can be a wildcard, then _bitcoin-payment.*.mattcorallo.com wouldn't be allowed.

in bip-XXXX.mediawiki:28 in 83c1343a03 outdated

  23 | +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.
  24 | +
  25 | +==Specification==
  26 | +
  27 | +=== General rules for handling ===
  28 | +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.

sbddesign commented at 6:26 PM on February 19, 2024:

Does this mean that a wallet should store the bitcoin payment instructions locally? e.g. fetch DNS record for matt@mattcorallo.com, receive BOLT 12 offer, and then store that offer locally so no further DNS lookup is required (unless one day payment to the offer fails)?

TheBlueMatt commented at 6:16 PM on February 20, 2024:

Its more a reference to wallets potentially using the DNS lookup mechanism when they have a QR code containing an offer, or otherwise build a UX around the DNS lookup mechanism when the UX would be equally compelling using offers/addresses directly. Wallets MUST NOT do that as it introduces additional trust that is simply not required.

in bip-XXXX.mediawiki:45 in 83c1343a03 outdated

  38 | +
  39 | +=== Resolution ===
  40 | +
  41 | +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.
  42 | +
  43 | +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.

azuchi commented at 8:24 AM on February 23, 2024:

Recently, a vulnerability related to DNSSEC design, KeyTrap (CVE-2023-50387), was disclosed.

https://www.athene-center.de/en/keytrap

Is this requirement not affected by this vulnerability? Isn't it necessary to consider mitigation measures that existing resolvers take?

TheBlueMatt commented at 7:00 PM on February 26, 2024:

KeyTrap observed that validation of DNSSEC signatures can be superlinear in the number of signatures/keys. The mitigations that ~all validators have deployed addresses that, and should be used here. However, "be up to date with the latest security fixes" is a general thing and doesn't really need to be specified here :)

TheBlueMatt force-pushed on Mar 5, 2024

TheBlueMatt commented at 9:31 PM on March 5, 2024: contributor

Pushed a few small updates, plus changed the display format to ₿user@domain (that's a bitcoin symbol if you are missing good fonts). This makes a tradeoff between compatibility with lnurl (user@domain) and getting confused with email (by adding an explicit prefix). I consider this ~final at this point, absent some substantial issues or minor clerical mistakes.

cbergqvist commented at 9:44 PM on March 5, 2024: none

Happy you're giving the optional ₿-prefix a chance! Typing out and risking misspelling the receiving address is not something one wants to encourage anyway, but you still allow dropping the prefix for those who insist on typing. (And one still has to have a valid DNS record, so misspelling only becomes an issue for domains with many users).

in bip-XXXX.mediawiki:75 in 09db33a98a outdated

  70 | +
  71 | +There are several ways in which human-readable payment instructions could be displayed in wallets. In order to ensure compatibility with existing human-readable names schemes, @ is used as the separator between the `user` and `domain` parts. However, simply using the @ separator can lead to confusion between emails on a given domain and payment instructions on a domain. In order to somewhat reduce the incidence of such confusion, a ₿ prefix is used.
  72 | +
  73 | +=== Rotation ===
  74 | +
  75 | +On-chain addresses which are re-used (i.e. not including schemes like Silent Payments) need to be rotating to avoid contributing substantially to address reuse. However, rotating them on a timer or any time a transaction enters the mempool could lead to substantial overhead from excess address generation. Instead, rotating addresses any time a transaction is confirmed on-chain ensures address rotation happens often while bounding the maximum number of addresses needed to one per block, which grows very slowly and will not generate an address set too large to handle while scanning the chain going forward.

t-bast commented at 8:41 AM on March 6, 2024:

nit:

On-chain addresses which are re-used (i.e. not including schemes like Silent Payments) need to be rotated to avoid contributing substantially to address reuse. However, rotating them on a timer or any time a transaction enters the mempool could lead to substantial overhead from excess address generation. Instead, rotating addresses any time a transaction is confirmed on-chain ensures address rotation happens often while bounding the maximum number of addresses needed to one per block, which grows very slowly and will not generate an address set too large to handle while scanning the chain going forward.

in bip-XXXX.mediawiki:89 in 09db33a98a outdated

  84 | +
  85 | +==== DNS Rather than HTTP-based solutions ====
  86 | +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.
  87 | +
  88 | +==== Private DNS Querying ====
  89 | +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.

t-bast commented at 8:45 AM on March 6, 2024:

Resolving payment instructions recursively locally would instead introduce drawback (b) directly to the recipient, which may well be worse.

I don't understand what you mean here, can you detail?

TheBlueMatt commented at 3:23 PM on March 6, 2024:

Drawback (b) is "revealing sender IP addresses to recipients or other intermediaries as a side-effect of payment". I added a few additional words here, let me know if that clarified it.

t-bast commented at 3:32 PM on March 6, 2024:

This is much clearer, thanks!

in bip-XXXX.mediawiki:114 in 09db33a98a outdated

 109 | +* A lightning-specific name to payment instruction resolver can be found at https://git.bitcoin.ninja/index.cgi?p=lightning-resolver;a=summary
 110 | +* Reference implementations for parsing the URI contents can be found in [[bip-0021.mediawiki|BIP 21]].
 111 | +
 112 | +== Acknowledgements ==
 113 | +
 114 | +Thanks to Rusty Russel for suggesting the concrete address rotation suggestions.

t-bast commented at 8:46 AM on March 6, 2024:

Thanks to Rusty Russell for the concrete address rotation suggestions.

t-bast commented at 8:46 AM on March 6, 2024: contributor

Looks mostly good to me, a couple nits/questions.

t-bast approved

t-bast commented at 3:33 PM on March 6, 2024: contributor

ACK https://github.com/bitcoin/bips/pull/1551/commits/d618202ed00b1481d4938bcbcd0d6b27753df6f5

in bip-XXXX.mediawiki:57 in d618202ed0 outdated

  52 | +
  53 | +While clients MAY cache the payment instructions they receive from the DNS, clients MUST NOT cache the payment instructions received from the DNS for longer than the TTL provided by their DNS resolver, and further MUST NOT cache the payment instructions for longer than the lowest initial TTL (which is signed as a part of DNSSEC signatures) received in the full DNSSEC chain leading from the DNS root to the resolved TXT record.
  54 | +
  55 | +=== Address Reuse ===
  56 | +
  57 | +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).

nickfarrow commented at 3:40 AM on April 11, 2024:

By only rotating the onchain address after receiving a payment, anyone with the human readable name can continually poll your address(es) and monitor the onchain transactions you receive.

It requires a more active attack on privacy, but still very easy.

I still think it is worthwhile to include onchain, it's nice to support any BIP21 type. But could discourage onchain in favour of silent payments / BOLT12.

TheBlueMatt commented at 6:03 PM on April 15, 2024:

I still think it is worthwhile to include onchain, it's nice to support any BIP21 type. But could discourage onchain in favour of silent payments / BOLT12.

That's definitely the goal.

murchandamus added the label New BIP on Apr 29, 2024

in bip-XXXX.mediawiki:10 in d618202ed0 outdated

   5 | +  Author: Matt Corallo <bipxxx@bluematt.me>
   6 | +          Bastien Teinturier <bastien@acinq.fr>
   7 | +  Comments-Summary: No comments yet.
   8 | +  Status: Draft
   9 | +  Type: Standards Track
  10 | +  Created: 2024-02-10

murchandamus commented at 1:03 PM on April 29, 2024:

The preamble is missing mandatory headers. Please add Comments-URI and License. If this BIP has meanwhile been posted to the mailing list, it would also be great if you could add a link to that and the delving discussion per the Post-History header.

murchandamus changes_requested

murchandamus commented at 1:07 PM on April 29, 2024: contributor

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.

murchandamus added the label PR Author action required on May 8, 2024

Zavalynech approved

TheBlueMatt commented at 8:03 PM on May 19, 2024: contributor

Done!

in bip-XXXX.mediawiki:74 in 8839a6c6a6 outdated

  69 | +
  70 | +== Rationale ==
  71 | +
  72 | +=== Display ===
  73 | +
  74 | +There are several ways in which human-readable payment instructions could be displayed in wallets. In order to ensure compatibility with existing human-readable names schemes, @ is used as the separator between the `user` and `domain` parts. However, simply using the @ separator can lead to confusion between emails on a given domain and payment instructions on a domain. In order to somewhat reduce the incidence of such confusion, a ₿ prefix is used.

murchandamus commented at 7:22 PM on May 21, 2024:

There are several ways in which human-readable payment instructions could be displayed in wallets. In order to ensure compatibility with existing human-readable names schemes, @ is used as the separator between the `user` and `domain` parts. However, simply using the @ separator can lead to confusion between email addresses on a given domain and payment instructions on a domain. In order to somewhat reduce the incidence of such confusion, a ₿ prefix is used.

in bip-XXXX.mediawiki:78 in 8839a6c6a6 outdated

  73 | +
  74 | +There are several ways in which human-readable payment instructions could be displayed in wallets. In order to ensure compatibility with existing human-readable names schemes, @ is used as the separator between the `user` and `domain` parts. However, simply using the @ separator can lead to confusion between emails on a given domain and payment instructions on a domain. In order to somewhat reduce the incidence of such confusion, a ₿ prefix is used.
  75 | +
  76 | +=== Rotation ===
  77 | +
  78 | +On-chain addresses which are re-used (i.e. not including schemes like Silent Payments) need to be rotated to avoid contributing substantially to address reuse. However, rotating them on a timer or any time a transaction enters the mempool could lead to substantial overhead from excess address generation. Instead, rotating addresses any time a transaction is confirmed on-chain ensures address rotation happens often while bounding the maximum number of addresses needed to one per block, which grows very slowly and will not generate an address set too large to handle while scanning the chain going forward.

murchandamus commented at 7:24 PM on May 21, 2024:

Now that BIP352 is merged, you could link to it:

On-chain addresses which are re-used (i.e. not including schemes like [[bip-0352.mediawiki|Silent Payments]])  need to be rotated to avoid contributing substantially to address reuse. However, rotating them on a timer or any time a transaction enters the mempool could lead to substantial overhead from excess address generation. Instead, rotating addresses any time a transaction is confirmed on-chain ensures address rotation happens often while bounding the maximum number of addresses needed to one per block, which grows very slowly and will not generate an address set too large to handle while scanning the chain going forward.

in bip-XXXX.mediawiki:86 in 8839a6c6a6 outdated

  81 | +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.
  82 | +
  83 | +==== DNS Rather than blockchain-based solutions ====
  84 | +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.
  85 | +
  86 | +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.

murchandamus commented at 7:28 PM on May 21, 2024:

Finally, it is 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.

murchandamus changes_requested

murchandamus commented at 7:53 PM on May 21, 2024: contributor

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 approved

murchandamus commented at 5:04 PM on May 30, 2024: contributor

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

murchandamus removed the label PR Author action required on May 30, 2024

murchandamus added the label Needs number assignment on May 30, 2024

murchandamus commented at 7:29 PM on June 3, 2024: contributor

Let’s call this BIP 353.

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

murchandamus removed the label Needs number assignment on Jun 3, 2024

murchandamus renamed this:
~~Add a BIP which resolves human readable names into payment info~~
Add BIP 353: DNS Payment Instructions
on Jun 3, 2024

murchandamus added the label PR Author action required on Jun 3, 2024

TheBlueMatt force-pushed on Jun 3, 2024

TheBlueMatt commented at 9:18 PM on June 3, 2024: contributor

Done

bitcoin deleted a comment on Jun 4, 2024

in README.mediawiki:1092 in 8ca9811c7c outdated

1085 | @@ -1086,6 +1086,13 @@ Those proposing changes should consider that ultimately consent may rest with th
1086 |  | Informational
1087 |  | Draft
1088 |  |-
1089 | +| [[bip-0353.mediawiki|353]]
1090 | +| Applications
1091 | +| DNS Payment Instructions
1092 | +| Matt Corall, Bastien Teinturier

murchandamus commented at 8:36 PM on June 4, 2024:

| Matt Corallo, Bastien Teinturier

murchandamus approved

murchandamus commented at 8:37 PM on June 4, 2024: contributor

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

Add a BIP which resolves human readable names into payment info

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.

4f75edb2b8

TheBlueMatt force-pushed on Jun 4, 2024

TheBlueMatt commented at 8:40 PM on June 4, 2024: contributor

:facepalm:

murchandamus removed the label PR Author action required on Jun 4, 2024

murchandamus approved

murchandamus commented at 3:03 PM on June 10, 2024: contributor

ACK 4f75edb2b85f55f5723e379584e52181f5f44269

murchandamus merged this on Jun 10, 2024

murchandamus closed this on Jun 10, 2024

Sjors commented at 7:26 PM on July 11, 2024: member

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

Amirali0935 approved

bitcoin deleted a comment on Dec 12, 2024

albassort commented at 7:41 AM on April 16, 2025: none

OpenAlias

The difference is not reinventing the wheel. There is no need for such a thing. The other reason, is, OpenAlias being supported and used by other ones means it can standardized. I can point you to donate.albassort.com, and there is an XMR and BTC address. Your solution would require multiple. Ok, heres my BTC subdomain, heres my XMR subdomain. Unless, it can parse OpenAlias, and ignore them, and skip to your thing, which makes no sense to do.

Add BIP 353: DNS Payment Instructions #1551

Add BIP 353: DNS Payment Instructions #1551