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

@@ -659,6 +659,17 @@ 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><RFC 9102-formatted DNSSEC Proof></tt>
+| An RFC 9102 DNSSEC `Authentication Chain Data` without the `ExtSupportLifetime` field (i.e. a series of RFC 9102 `AuthenticationChain`s) 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

@@ -76,6 +76,28 @@ 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.
+
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><valuedata></tt>
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| BIP 353 DNSSEC proof
+| <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>
+| None
+| <tt><RFC 9102-formatted DNSSEC Proof></tt>
+|
+|
+| 0, 2
+|}
+
 == Rationale ==
 
 === Display ===