From eeaf21d882df2cda2b0434918f2f15a62db79590 Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Sun, 28 Jul 2024 17:30:57 +0000 Subject: Consistently refer to them as "human-readable names", not addresses It seems confusing to call BIP 353 names "addresses", and most of the BIP refers to them as "names", but a few "human-readable addresses" snuck in in a recent change, which are fixed here. --- bip-0353.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0353.mediawiki b/bip-0353.mediawiki index 9deba50..43e424f 100644 --- a/bip-0353.mediawiki +++ b/bip-0353.mediawiki @@ -70,9 +70,9 @@ Payment instructions which do contain on-chain addresses which will be re-used S === Display === -When displaying a verified human-readable address, wallets SHOULD prefix it with ₿, i.e. ₿`user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and ₿`user`@`domain` forms and resolve such entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved. +When displaying a verified human-readable name, wallets SHOULD prefix it with ₿, i.e. ₿`user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and ₿`user`@`domain` forms and resolve such an entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved. -Wallets providing the ability for users to "copy" their address information SHOULD copy the underlying URI directly, rather than the human-readable address. This avoids an additional DNS lookup by the application in which it is pasted. Wallets that nevertheless provide users the ability to copy their human-readable address, MUST include the ₿ prefix (i.e. copy it in the form ₿`user`@`domain`). +Wallets providing the ability for users to "copy" their address information SHOULD copy the underlying URI directly, rather than the human-readable name. This avoids an additional DNS lookup by the application in which it is pasted. Wallets that nevertheless provide users the ability to copy their human-readable name, MUST include the ₿ prefix (i.e. copy it in the form ₿`user`@`domain`). Wallets accepting payment information from external devices (e.g. hardware wallets) SHOULD accept RFC 9102-formatted proofs (as a series of unsorted `AuthenticationChain` records) and, if verification succeeds, SHOULD display the recipient in the form ₿`user`@`domain`. -- cgit v1.2.3 From b0d5a0794333bfcf103c3642b168c4338320c48e Mon Sep 17 00:00:00 2001 From: Matt Corallo Date: Sun, 28 Jul 2024 18:34:22 +0000 Subject: Add a PSBT per-output field for BIP 353 DNSSEC Proofs When using BIP 353 for on-chain addresses (incl silent payments), it is useful to be able to include DNSSEC proof information in outputs of a PSBT, which we enable here by defining a standard field for it. --- bip-0174.mediawiki | 12 ++++++++++++ bip-0353.mediawiki | 27 +++++++++++++++++++++++++++ 2 files changed, 39 insertions(+) diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 8509f97..5aeba56 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -659,6 +659,18 @@ required for aggregation. If sorting was done, then the keys must be in the sort | 0, 2 | [[bip-0373.mediawiki|373]] |- +| BIP 353 DNSSEC proof +| PSBT_OUT_DNSSEC_PROOF = 0x35 +| None +| No key data +| <1-byte-length-prefixed BIP 353 human-readable name> +| A BIP 353 human-readable name (without the ₿ prefix), prefixed by a 1-byte length. +Followed by an [[https://www.rfc-editor.org/rfc/rfc9102.html#name-dnssec-authentication-chain|RFC 9102 DNSSEC AuthenticationChain]] (i.e. a series of DNS Resource Records in no particular order) providing a DNSSEC proof to a BIP 353 DNS TXT record. +| +| +| 0, 2 +| [[bip-0353.mediawiki|353]] +|- | Proprietary Use Type | PSBT_OUT_PROPRIETARY = 0xFC | diff --git a/bip-0353.mediawiki b/bip-0353.mediawiki index 43e424f..9c48f91 100644 --- a/bip-0353.mediawiki +++ b/bip-0353.mediawiki @@ -76,6 +76,33 @@ Wallets providing the ability for users to "copy" their address information SHOU Wallets accepting payment information from external devices (e.g. hardware wallets) SHOULD accept RFC 9102-formatted proofs (as a series of unsorted `AuthenticationChain` records) and, if verification succeeds, SHOULD display the recipient in the form ₿`user`@`domain`. +=== PSBT types === + +Wallets accepting payment information from external devices (e.g. hardware wallets) MAY examine the following per-output PSBT fields to fetch RFC 9102-formatted proofs. Wallets creating PSBTs with recipient information derived from human-readable names SHOULD include the following fields. + +When validating the contained proof, clients MUST enforce the inception on all contained RRSigs is no later than the current time and that the expiry of all RRSigs is no earlier than an hour in the past. Clients MAY allow for an expiry up to an hour in the past to allow for delays between PSBT construction and signing only if such a delay is likely to occur in their intended usecase. + +{| +! Name +! +! +! +! Description +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +|- +| BIP 353 DNSSEC proof +| PSBT_OUT_DNSSEC_PROOF = 0x35 +| None +| <1-byte-length-prefixed BIP 353 human-readable name without the ₿ prefix> +| A BIP 353 human-readable name (without the ₿ prefix), prefixed by a 1-byte length. +Followed by an [[https://www.rfc-editor.org/rfc/rfc9102.html#name-dnssec-authentication-chain|RFC 9102 DNSSEC AuthenticationChain]] (i.e. a series of DNS Resource Records in no particular order) providing a DNSSEC proof to a BIP 353 DNS TXT record. +| +| +| 0, 2 +|} + == Rationale == === Display === -- cgit v1.2.3