bips
bips copied to clipboard
bitcoin
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.
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?
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.
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 (?)
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.
IMO a
.well-knownpath would be better. Among things that use internet identifiers, Mastodon, Nostr, and Lightning all use.well-knownpaths. 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.
(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.
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.
@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.
(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!
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
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.
Which is a manual task.
Indeed, which seems perfectly reasonable for something you do once and never have to touch again!
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.
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.
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.
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.
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?
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.
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.
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.
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.
Wrong. DoH exists and is encouraged.
What would be the benefit if DoH has to be used? You could just do LNURL-pay then.
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).
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.
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.
Another thought: the parsing of USER@DOMAIN is pretty trivial, but how to do it should be mentioned.
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 https://github.com/bitcoin/bips/pull/1551#issuecomment-1937438951 - I'd like to discuss whether we want specifically USER@DOMAIN for a bit first. Do you have any opinion on that?
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)?
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.
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.
