Merge pull request bitcoin#1657 from TheBlueMatt/2024-07-psbt-dns

Add a PSBT per-output field for BIP 353 DNSSEC Proofs

Author: murchandamus

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
+| <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>
+| None
+| No key data
+| <tt><1-byte-length-prefixed BIP 353 human-readable name><RFC 9102-formatted AuthenticationChain DNSSEC Proof></tt>
+| 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 <tt>AuthenticationChain</tt>]] (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
 | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
 | <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>

bip-0353.mediawiki

@@ -70,12 +70,39 @@ 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`.
 
+=== 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
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| BIP 353 DNSSEC proof
+| <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>
+| None
+| <tt><1-byte-length-prefixed BIP 353 human-readable name without the ₿ prefix><RFC 9102-formatted DNSSEC Proof></tt>
+| 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 <tt>AuthenticationChain</tt>]] (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 ===