Add a BIP which resolves human readable names into payment info

[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).

[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?

[moneyball]

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.

[casey]

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]

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]

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

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]

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]

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 🤷.

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 :)

[pinheadmz]

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]

(see also https://github.com/james-stevens/wallet-ids-in-dns)

[harding]

@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.

[sbddesign]

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]

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.

[azuchi]

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]

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]

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]

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).

[t-bast]

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

[t-bast]

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]

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]

This is much clearer, thanks!

[t-bast]

ACK d618202

[nickfarrow]

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]

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]

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]

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.