Rename DNS payment instructions to Human Bitcoin Address (#1203)

* Rename DNS payment instructions to human bitcoin address

* Encourage use in UI where appropriate

Author: ConorOkus

guide/daily-spending-wallet/contacts.md

@@ -213,7 +213,7 @@ Whether we’re sending emails, physical mail, or following someone on social me
 
 Addresses, invoices, node IDs and other transaction endpoints in bitcoin are highly unintuitive. Abstracting them via a contact list can create a much smoother user experience. There are many [payment request formats]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }}), each with unique properties and varying levels of maturity and adoption, requiring unique design solutions. This page will use a more approachable "address" as an umbrella term for various types of payment information.
 
-Some payment request formats such as [silent payments (BIP-352)]({{ '/guide/how-it-works/silent-payments' | relative_url }}), [lightning offers (BOLT 12)]({{ '/guide/how-it-works/payment-request-formats/#offers' | relative_url }}) and [DNS payment instructions (BIP-353)]({{ '/guide/how-it-works/human-readable-addresses/#bip-353-dns-payment-instructions' | relative_url }}) are designed to be safely reused. This property makes them ideal for abstraction through contacts.
+Some payment request formats such as [silent payments (BIP-352)]({{ '/guide/how-it-works/silent-payments' | relative_url }}), [lightning offers (BOLT 12)]({{ '/guide/how-it-works/payment-request-formats/#offers' | relative_url }}) and [DNS payment instructions (BIP-353)]({{ '/guide/how-it-works/human-readable-addresses/#human-bitcoin-address-bip-353' | relative_url }}) are designed to be safely reused. This property makes them ideal for abstraction through contacts.
 
 Let's go over common user interactions around managing contacts. This will illustrate how such a feature could work, and helps explain the underlying design problems and decisions.
 

guide/designing-products/common-user-flows.md

@@ -394,7 +394,7 @@ For the simplest form of base layer requests, the receiver only needs to share o
 
 While it is possible to re-use the same receiving address repeatedly, this practice is highly discouraged for privacy reasons.
 
-For more information-rich base layer requests, [BIP 21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) describes a URI scheme to turn requests into links that can be shared like any other link. On click, wallets that support this scheme can immediately show the send screen with the correct information pre-filled. Links can also be encoded and transmitted via QR code. Since the scheme also allows for the inclusion of an address label and transaction description, it allows both sender and recipient to stay organized.
+For more information-rich base layer requests, [BIP 321](https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki) describes a URI scheme to turn requests into links that can be shared like any other link. On click, wallets that support this scheme can immediately show the send screen with the correct information pre-filled. Links can also be encoded and transmitted via QR code. Since the scheme also allows for the inclusion of an address label and transaction description, it allows both sender and recipient to stay organized.
 
 For requests on the lightning network, the receiver needs to create a lightning invoice that includes the amount, and then share the invoice with the sender.
 

guide/designing-products/interoperability.md

@@ -59,13 +59,13 @@ You should ensure your application is interoperable with the various techniques
 
 Supporting, generating, and reading as many [payment request formats]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }}) as possible in your application will make it more interoperable with others.
 
-It also matters how these formats are generated. Your applications should be able to read, and generate, [BIP 21](https://bips.xyz/21) encoded payment requests.
+It also matters how these formats are generated. Your applications should be able to read, and generate, [BIP 321](https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki) encoded payment requests.
 
-An evolving standard that improves payment usability between on-chain and lightning is being able to read and generate [unified bitcoin payment requests](https://bitcoinqr.dev/) that contain an on-chain address and lightning invoice inside a BIP 21 URI.
+An evolving standard that improves payment usability between on-chain and lightning is being able to read and generate [unified bitcoin payment requests](https://bitcoinqr.dev/) that contain an on-chain address and lightning invoice inside a BIP 321 URI.
 
 When dealing with lightning invoice [amounts]({{ '/guide/daily-spending-wallet/requesting/#entering-an-amount' | relative_url }}), your application should be able to read and generate zero amount invoices.
 
-Payment links, often using BIP 21, should be readable by your application. Forms should be automatically opened and filled when a user clicks a payment link or button.
+Payment links, often using BIP 321, should be readable by your application. Forms should be automatically opened and filled when a user clicks a payment link or button.
 
 [Near-field communication](https://en.wikipedia.org/wiki/Near-field_communication) (NFC) should be supported for paying and sharing payment requests.
 

guide/how-it-works/human-readable-addresses.md

@@ -123,23 +123,18 @@ From email and social media, we are familiar with addresses consisting of a <spa
 
 For social media, users know to navigate to the respective website or app and look up the username there. Applications rely on domains (via the [Domain Name System](https://en.wikipedia.org/wiki/Domain_Name_System), or DNS) to resolve the global part. In physical addresses, we have more hierarchical parts - country, state, city, street, house number and apartment. It is a familiar system.
 
-## BIP-353: DNS Payment Instructions
+## Human Bitcoin Address (BIP 353)
 
 This [proposal](https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki) only relies on the Domain Name System (DNS) to retrieve payment information. DNS is a decentralized hierarchical naming system used to translate human-friendly domain names (like *www.example.com*) into IP addresses (like *192.0.2.1*) that computers use to identify each other on the network. Anytime we type in a domain into a browser, we rely on this system. This use case is very similar to what human-readable addresses try to achieve, making DNS a good fit.
 
-{% include tip/open.html color="blue" label="Note" icon="info" %}
-
-This is a new proposal. It is still being discussed, and not widely implemented.
-
-{% include tip/close.html %}
 
 ### Address format
 
 This proposal uses the formats *“<span class="-green">username</span>@<span class="-blue">domain.com</span>”* and *“₿<span class="-green">username</span>@<span class="-blue">domain.com</span>”*. It is similar to the email address format, which makes it familiar and easy to use. The *₿* prefix is an important addition for display purposes, to make it distinctly a bitcoin payment address. This provides clarity and trust to users, which is important when it comes to financial transactions.
 
 ### How it works
 
-Users create DNS entries with payment information, which can be one or more addresses of different formats, combined to a [BIP 21 URI](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki). Since address reuse is best avoided for privacy reasons, the included addresses should be reusable (like [silent payments]({{ '/guide/how-it-works/silent-payments/' | relative_url }}) and [BOLT12](https://bolt12.org/) offers). Single-use addresses can be used if needed, but a mechanism to rotate them should be in place.
+Users create DNS entries with payment information, which can be one or more addresses of different formats, combined to a [BIP 321 URI](https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki). Since address reuse is best avoided for privacy reasons, the included addresses should be reusable (like [silent payments]({{ '/guide/how-it-works/silent-payments/' | relative_url }}) and [BOLT12](https://bolt12.org/) offers). Single-use addresses can be used if needed, but a mechanism to rotate them should be in place.
 
 {% include picture.html
    image = "/assets/images/guide/how-it-works/human-readable-addresses/dns-payment-instructions-mapping.png"
@@ -200,9 +195,9 @@ Framing the correct use of the address should be done right away and as early in
 
 {% include tip/open.html label="Bubble Wallet" %}
 
-The mock-ups below show an imaginary application called "Bubble Wallet". Its naming conventions are based on the idea that _Human-readable address_ is an appropriate descriptive term for technical proposal and discussion, but not necessarily practical for end-users. Due to the similarities to the familiar email format and social media practices, it borrows from those standards.
+The mock-ups below show an imaginary application called "Bubble Wallet". Its naming conventions are based on the idea that _Human Bitcoin address_ is an appropriate descriptive term for technical proposals and discussions, and can also be used contextually and subtly in product UI where appropriate—for example, in titles, labels, and input-field placeholders. Due to the similarities to the familiar email format and social media practices, it borrows from those standards.
 
-- A human-readable address is referred to generally as (a new type of) _bitcoin address_
+- A human bitcoin address is referred to generally as (a new type of) _bitcoin address_
 - More specifically, it is referred to as _Bubble address_ or _Bubble bitcoin address_, because it is managed by the wallet (provider)
 - The first part of the address is referred to as _username_
 - Other address types are first referred to by their primary properties, and secondly by their technical names

guide/how-it-works/payment-request-formats.md

@@ -45,11 +45,11 @@ If you need to test whether your application supports a payment request type, yo
 
 A [Uniform Resource Identifier](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) (URI) is a web technology that uses unique prefixes to identify anything. This can be real-world objects, websites, information, etc.
 
-Bitcoin uses URIs to help apps identify payment requests. The technical details of this scheme are detailed in [BIP 21](https://bips.xyz/21).
+Bitcoin uses URIs to help apps identify payment requests. The technical details of this scheme are detailed in [BIP 321](https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki).
 
-BIP 21 uses a `bitcoin:` URI scheme to identify and help applications manage bitcoin payment requests. Applications should support this if they want to be [interoperable]({{'/guide/getting-started/principles/#interoperability' | relative_url}}) with other bitcoin products. Some other URI schemes used for bitcoin payment requests include `lightning` and LNURL schemes such as `lnurlp`. Note that a URI scheme can be presented as lowercase or uppercase.
+BIP 321 uses a `bitcoin:` URI scheme to identify and help applications manage bitcoin payment requests. Applications should support this if they want to be [interoperable]({{'/guide/getting-started/principles/#interoperability' | relative_url}}) with other bitcoin products. Some other URI schemes used for bitcoin payment requests include `lightning` and LNURL schemes such as `lnurlp`. Note that a URI scheme can be presented as lowercase or uppercase.
 
-BIP 21 is extensible and allows for the addition of other useful meta data that give more context to a payment request. This includes things like an amount, labels, messages, and other useful data. It also allows [more than one type]({{'/guide/how-it-works/payment-request-formats/#unified-payment-requests' | relative_url}}) of payment request format to be included in a payment request.
+BIP 321 is extensible and allows for the addition of other useful meta data that give more context to a payment request. This includes things like an amount, labels, messages, and other useful data. It also allows [more than one type]({{'/guide/how-it-works/payment-request-formats/#unified-payment-requests' | relative_url}}) of payment request format to be included in a payment request.
 
 A common pattern using URIs for inter-app payments is detailed in the [wallet selector page]({{'/guide/how-it-works/wallet-selector/' | relative_url}}).
 
@@ -236,7 +236,7 @@ Payment codes have been popularised in wallets such as [Samourai](https://samour
 
 A downside to payment codes is that they require an additional on-chain transaction each time two users want to connect and use them. [Silent payments](https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8?permalink_comment_id=4113680) are a new experimental proposal that prevents the need for this additional on-chain transaction at the cost of extra bandwidth for receivers.
 
-Static payment codes are great for use with [DNS-based human readable addresses]({{ '/guide/how-it-works/human-readable-addresses/#bip-353-dns-payment-instructions' | relative_url }}).
+Static payment codes are great for use with [DNS-based human readable addresses]({{ '/guide/how-it-works/human-readable-addresses/#human-bitcoin-address-bip-353' | relative_url }}).
 
 </div>
 
@@ -255,7 +255,7 @@ Static payment codes are great for use with [DNS-based human readable addresses]
 
 A unified payment request combines one or more of the formats listed above. This makes it easier to request a payment when you are unsure what formats the sender supports.
 
-Unified payment requests use the BIP 21 `bitcoin:` URI to add multiple payment request formats to a single payment request. The more formats added, the larger the request becomes which can be an issue for lower end devices that can't scan complex QR codes.
+Unified payment requests use the BIP 321 `bitcoin:` URI to add multiple payment request formats to a single payment request. The more formats added, the larger the request becomes which can be an issue for lower end devices that can't scan complex QR codes.
 
 You can learn more about unified payment requests [here](https://bitcoinqr.dev/).
 

guide/how-it-works/wallet-selector.md

@@ -82,7 +82,7 @@ We’ll outline each of those below.
 
 ### 1. Opening the default wallet
 
-A widely supported standard is [BIP 21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki#Examples) (also see [Payment request formats](/guide/how-it-works/payment-request-formats/#uniform-resource-identifier-uris-schemes)), which defines a URI scheme for passing bitcoin payment information to other applications.
+A widely supported standard is [BIP 321](https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki) (also see [Payment request formats](/guide/how-it-works/payment-request-formats/#uniform-resource-identifier-uris-schemes)), which defines a URI scheme for passing bitcoin payment information to other applications.
 
 For example, clicking a link or button with the following URI is opened in the default bitcoin wallet (if there is one installed):
 `bitcoin:16AgmhoCVSJoGeEkERPdrsdvJG3RWmum6T`

guide/resources/learning-bootcamp.md

@@ -271,7 +271,7 @@ Bitcoin Design Guide:
 **[Payment Request Formats]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }})**
 
 - What are the key differences between a regular Lightning invoice and a Lightning address in terms of user experience and privacy?
-- Why do unified payment requests use the BIP 21 bitcoin: URI scheme? What problem does this solve?
+- Why do unified payment requests use the BIP 321 bitcoin: URI scheme? What problem does this solve?
 - Between LNURL, Offers (BOLT 12), and regular invoices, which would you choose for building a subscription service and why?
 
 **[Lightning Services]({{ '/guide/how-it-works/lightning-services/' | relative_url }})**