BitcoinDesign
Rename DNS payment instructions to Human Bitcoin Address
The idea behind this small change is that we need a clear name for BIP 353: DNS payment instructions. It’s important to keep the word “address” in the naming, since users are already familiar with it, but the naming and branding should also signal that it is distinct from an email address, a Lightning address, and a Bitcoin address.
This doesn’t prevent people from continuing to use the term “human-readable name” in technical discussions or descriptive contexts.
I also replaced references to BIP 21 with BIP 321, as the latter is a more polished version of the former and includes additional functionality—for example, a proof-of-payment callback.
Deploy Preview for bitcoin-design-site ready!
| Name | Link |
|---|---|
| Latest commit | 3b9047ab293b3d429d9675993c777562419dacb1 |
| Latest deploy log | https://app.netlify.com/projects/bitcoin-design-site/deploys/69398a0fe1604a0008207475 |
| Deploy Preview | https://deploy-preview-1203--bitcoin-design-site.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify project configuration.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
as long as there's consensus that BIP321 is ready to be communicated as a replacement for BIP21.
They're functionally identical. There's one additional optional extension in 321, but mostly it just updates 21 to allow for things like segwit addresses (ha!) and describes how people already include lighting invoices/offers.
Hm, I don't fully agree with this change. The title of the page itself is already "Human readable address". It's weird then to have a sub-section called "Human Bitcoin Address". Lightning Address and Paynyms have the same goal of being human-readable, so it's not clear why BIP-353 should have this unique title. The current title of "DNS Payment Instructions" is simply the name of the BIP. Technical, of course, but it is a technical document.
Why not change the title of the page instead?
We want to call it "Human Bitcoin Address" for the same reason we don't call "Lightning Address" LNURL-pay or "Paynyms" BIP 47.
@GBKS it seems to me the proposed naming & architecture of this page makes sense:
"Human Readable Addresses" is the generic/parent concept that is meaningful
- "Human Bitcoin Address" is a type of HRA (and the preferred alternative to LNA going forward)
- "Lighting Address" is another type of HRA (served its purpose, but has some bad compromises)
- "Paynyms" is another type of HRA
"Human Bitcoin Address" can be best thought of as the lightly-branded name that we give to the BIP-353 DNS payments-instructions-based solution that is an alternative to "Lightning Address"
I supposed it depends who the audience for that light branding for BIP-353? Feels more like something for the bitcoin builder ecosystem than end-users? I see roughly four audiences/areas:
- Technical audience: BIP-353 DNS Payment Instructions
- Builder audience: Human Bitcoin Address ⬅️
- User-facing UI: Simple bitcoin address, [Company name] bitcoin address, bitcoin address
- Casual end-user usage: [Company name] bitcoin address, bitcoin address, bitcoin email
Just thinking about Arké, having recently worked through the contacts and send flows, where lots of addresses appear. I don't think I would surface the term "Human bitcoin address" in the UI. But I am trying to see if we can get to a point where everything is just a "bitcoin address", and there's always on option to get more detail with a click (which then shows benefits/features and not technical stuff).
Go for it if you feel strongly about it.
[Company name] bitcoin address
This seems like a recipe for confusion. It signals clearly to end-consumers that these are somehow not interoperable, even though they are.
bitcoin email
This seems even worse. The whole point of the B in front of the BIP 353 is to avoid people thinking that these and email are the same namespace. They are not, and highlighting that they're similar is gonna cause a lot of confusion.
[Company name] bitcoin address
This seems like a recipe for confusion. It signals clearly to end-consumers that these are somehow not interoperable, even though they are.
For email, people are OK with having Yahoo email addresses and Google/Gmail email addresses) and don't worry about interoperability. Why would it be problematic here? The page itself also describes this approach.
bitcoin email
This seems even worse. The whole point of the B in front of the BIP 353 is to avoid people thinking that these and email are the same namespace. They are not, and highlighting that they're similar is gonna cause a lot of confusion.
This was a speculative comment on what people might use colloquially. Like people will say iWatch, despite there never having been a product with that name (only Apple Watch, but if you search for iWatch on apple.com it will show Apple Watch results). IRL language is full of shortcuts that make sense in context, and I think there's a chance some people will just call this "bitcoin email" as a mental shortcut due to the similar format (independent of whether this is ever used in a UI).
For email, people are OK with having Yahoo email addresses and Google/Gmail email addresses) and don't worry about interoperability. Why would it be problematic here? The page itself also describes this approach.
Sure, but in the early days of email people didn't (to my knowlege) call them "their gmail email" or "their yahoo email", at least not until it was cemented as a general-purpose thing that ~everyone knew well.
This was a speculative comment on what people might use colloquially. Like people will say iWatch, despite there never having been a product with that name (only Apple Watch, but if you search for iWatch on apple.com it will show Apple Watch results). IRL language is full of shortcuts that make sense in context, and I think there's a chance some people will just call this "bitcoin email" as a mental shortcut due to the similar format (independent of whether this is ever used in a UI).
Sure, but we should strongly discourage this :)
I agree with Matt that
[Company name] bitcoin address
is a recipe for confusion, as it will create an impression of many different types of addresses (in a situation of already having many types of addresses) when the whole point is for this to be universal, and thus works to counter purposes. I think we should avoid this outcome and certainly not advocate for it.
Are you proposing for UIs that “Simple Bitcoin Address” is better? We also considered “Easy Bitcoin Address” and many others. We didn’t like those because “simple” and “easy” seem tremendously over used in marketing language (as you pointed out recently almost every bitcoin wallet describes itself as simple). We landed on Human Bitcoin Address in part because “human-readable” has always been part of the value proposition and because it sets up the stark contrast of standard bitcoin addresses.
In terms of audience, immediately the primary audience is educating & convincing the bitcoin ecosystem (eg the audience consuming this Design Guide) of what BIP-353 is, why it is important and why adoption should be prioritized. We will undertake an advocacy & outreach campaign in this regard and will be publishing a blog post today or tomorrow (in which we hope to use this HBA language).
But I think this label could/should find an appropriately subtle & contextual way of appearing in product UIs as well, and for good reason. First, given the desired universality of the technology, it should also be universal in how everyone describes the thing—simply to create common understanding between users, apps, builders. But also, practically. Until there is ubiquity in understanding and availability, when a user asks another “for their bitcoin address” and they get sent a bc1p38geu839uiwjnr string they can go back and say no not that, send me your Human Bitcoin Address, and a UI may show such an annotation as appropriate (it doesn’t need to be screamed super prominently in the UI, just available when needed to disambiguate). For instance in Phoenix, when they need to refer to it they call it a BIP-353 DNS Address. I think HBA is strictly better! Yet in the long term, as such addresses become (hopefully!) ubiquitous the need for calling them anything in particular will go away and this will just be the way everyone comes to know addressing in bitcoin. We like making the technology disappear and that should the goal eventually.
But as a tactical matter for the foreseeable future we live in a world of Bitcoin products with many addressing schemes where this one, which hopefully can integrate and subsume them all, needs to be well-understood as new and distinct and garner adoption. I think the proposed changes to the Guide with this HBA naming help move the ecosystem in that direction.
On Wed, Dec 10, 2025 at 4:49 AM Matt Corallo @.***> wrote:
TheBlueMatt left a comment (BitcoinDesign/Guide#1203) https://github.com/BitcoinDesign/Guide/pull/1203#issuecomment-3636946601
[Company name] bitcoin address
This seems like a recipe for confusion. It signals clearly to end-consumers that these are somehow not interoperable, even though they are.
— Reply to this email directly, view it on GitHub https://github.com/BitcoinDesign/Guide/pull/1203#issuecomment-3636946601, or unsubscribe https://github.com/notifications/unsubscribe-auth/AORAHD2W2HHBCVT24OKKYKL4BAJGBAVCNFSM6AAAAACOOMNCFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMZWHE2DMNRQGE . You are receiving this because you commented.Message ID: @.***>
Email is not a good analogy because when email emerged there was not N competing address types that could receive email. It was a singular technology that gained widespread adoption and cultural relevance and so if we have ended up in a world of “Gmail” and “Yahoo mail” being well-understood it’s only due to the obviousness, uniqueness and ubiquity of the technology.
That is not the world we are in with receiving Bitcoin today.
On Wed, Dec 10, 2025 at 5:11 AM Matt Corallo @.***> wrote:
TheBlueMatt left a comment (BitcoinDesign/Guide#1203) https://github.com/BitcoinDesign/Guide/pull/1203#issuecomment-3637028079
For email, people are OK with having Yahoo email addresses and Google/Gmail email addresses) and don't worry about interoperability. Why would it be problematic here? The page itself also describes this approach.
Sure, but in the early days of email people didn't (to my knowlege) call them "their gmail email" or "their yahoo email", at least not until it was cemented as a general-purpose thing that ~everyone knew well.
This was a speculative comment on what people might use colloquially. Like people will say iWatch, despite there never having been a product with that name (only Apple Watch, but if you search for iWatch on apple.com it will show Apple Watch results). IRL language is full of shortcuts that make sense in context, and I think there's a chance some people will just call this "bitcoin email" as a mental shortcut due to the similar format (independent of whether this is ever used in a UI).
Sure, but we should strongly discourage this :)
— Reply to this email directly, view it on GitHub https://github.com/BitcoinDesign/Guide/pull/1203#issuecomment-3637028079, or unsubscribe https://github.com/notifications/unsubscribe-auth/AORAHD5Z6PV6ID2MAFTG56D4BALZRAVCNFSM6AAAAACOOMNCFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMZXGAZDQMBXHE . You are receiving this because you commented.Message ID: @.***>
Is "Oh, it's like an email for bitcoin" such a bad thing? Isn't the idea here that we make bitcoin more intuitive, specifically by tapping into these existing and established patterns that people already know? Can we use something that looks almost identical to email, without dragging in all the other associations?
Either way, maybe it's good to re-focus conversation on the purpose of this PR, which is the light branding of the feature for the builder ecosystem, as Mat pointed out. If there are concerns about how the page content (specifically the design patterns further down, which does recommend the company name thing) present the feature in UI, maybe that needs to be a separate PR? Happy to merge the former part if everyone is happy with that change.
Okay @GBKS will open a separate discussion PR about branding. I've added a little piece about contextual use in product UIs as well.