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

pull TheBlueMatt wants to merge 2 commits into bitcoin:master from TheBlueMatt:2024-07-psbt-dns changing 2 files +41 −2
  1. TheBlueMatt commented at 6:35 pm on July 28, 2024: contributor
    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.
  2. jonatack added the label Proposed BIP modification on Jul 28, 2024
  3. jonatack requested review from achow101 on Jul 28, 2024
  4. in bip-0174.mediawiki:667 in 64185ba458 outdated
    658@@ -659,6 +659,17 @@ required for aggregation. If sorting was done, then the keys must be in the sort
    659 | 0, 2
    660 | [[bip-0373.mediawiki|373]]
    661 |-
    662+| BIP 353 DNSSEC proof
    663+| <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>
    664+| None
    665+| No key data
    666+| <tt><RFC 9102-formatted DNSSEC Proof></tt>
    667+| 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.
    


    jonatack commented at 6:59 pm on July 28, 2024:
    0| An RFC 9102 DNSSEC <tt>Authentication Chain Data</tt> without the <tt>ExtSupportLifetime</tt> field (i.e. a series of RFC 9102 <tt>AuthenticationChain</tt>s) providing a DNSSEC proof to a BIP 353 DNS TXT record.
    

    TheBlueMatt commented at 1:44 pm on July 29, 2024:
    It seems to render fine either way, no? The <> version makes reading the plaintext much more difficult.

    achow101 commented at 8:21 pm on August 19, 2024:
    backticks don’t render as code formatting, if that was what you were trying to do. Otherwise, I’d suggest using single quotes here instead of backticks.
  5. jonatack added the label Pending acceptance on Jul 28, 2024
  6. TheBlueMatt force-pushed on Jul 30, 2024
  7. TheBlueMatt commented at 4:53 pm on July 30, 2024: contributor
    Realized this doesn’t actually work without the name itself, so force-pushed that in.
  8. in bip-0353.mediawiki:73 in 15656d5819 outdated
    69@@ -70,12 +70,37 @@ Payment instructions which do contain on-chain addresses which will be re-used S
    70 
    71 === Display ===
    72 
    73-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.
    74+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 entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved.
    


    murchandamus commented at 5:46 pm on July 30, 2024:
    0When 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.
    
  9. murchandamus commented at 5:48 pm on July 30, 2024: contributor
    Seems reasonable. @achow101, could you take a look please?
  10. 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.
    eeaf21d882
  11. TheBlueMatt force-pushed on Jul 31, 2024
  12. murchandamus assigned murchandamus on Aug 6, 2024
  13. murchandamus unassigned murchandamus on Aug 6, 2024
  14. murchandamus assigned achow101 on Aug 6, 2024
  15. Freeanjel approved
  16. in bip-0353.mediawiki:98 in 42a0e9a195 outdated
    93+| BIP 353 DNSSEC proof
    94+| <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>
    95+| None
    96+| <tt><1-byte-length-prefixed BIP 353 human-readable name without the ₿ prefix><RFC 9102-formatted DNSSEC Proof></tt>
    97+| A BIP 353 human-readable name (without the ₿ prefix), prefixed by a 1-byte length.
    98+Followed by 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.
    


    achow101 commented at 8:24 pm on August 19, 2024:
    A link to the relevant RFC and section would be nice. But I find the RFC to be a bit vague here, so it might be easier to just write out what the serialization is supposed to be?

    achow101 commented at 8:48 pm on August 19, 2024:

    Since a single RRSIG can cover multiple RRs in the response, those RRs would need to be included in order to verify the signature. Does there need to be any specific handling and/or disallowing of such RRSets?

    RRSIG also specifies a validity period for the signature. How should validators deal with those, especially since a PSBT can take a lot of time between updating and signing.


    TheBlueMatt commented at 1:57 am on August 25, 2024:

    A link to the relevant RFC and section would be nice.

    You mean like an HTTP link?

    But I find the RFC to be a bit vague here, so it might be easier to just write out what the serialization is supposed to be?

    Not sure I can be much more accurate. Its basically just “a series of DNS records written out in DNS record format”, but that’s not exactly clear either…

    Since a single RRSIG can cover multiple RRs in the response, those RRs would need to be included in order to verify the signature. Does there need to be any specific handling and/or disallowing of such RRSets?

    Those would need to be included. I believe RFC 9102 is clear here - “In either case, the chain of RRsets MUST be accompanied by the full set of DNS records needed to authenticate the TLSA record set or its denial of existence up the DNS hierarchy to either the root zone or another trust anchor mutually configured by the TLS server and client.”

    RRSIG also specifies a validity period for the signature. How should validators deal with those, especially since a PSBT can take a lot of time between updating and signing.

    That’s deliberately left undefined here. The library I wrote exposes the proof validity start and end time as well as the TTL, but I imagine most users will ignore the TTL, and probably should, only paying attention to the proof validity start and end times.

  17. achow101 commented at 8:34 pm on August 19, 2024: member

    Realized this doesn’t actually work without the name itself, so force-pushed that in.

    Wouldn’t the Authentication Chain already contain the name since it has the record itself?

  18. in bip-0353.mediawiki:96 in 42a0e9a195 outdated
    89+! Versions Requiring Inclusion
    90+! Versions Requiring Exclusion
    91+! Versions Allowing Inclusion
    92+|-
    93+| BIP 353 DNSSEC proof
    94+| <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>
    


    achow101 commented at 8:49 pm on August 19, 2024:
    It’d be nice to just go in order… the next field available is 0x09.

    TheBlueMatt commented at 1:59 am on August 25, 2024:
    I liked the DNS port (53) :) But I can do whatever, it doesn’t matter…
  19. bitcoin deleted a comment on Aug 19, 2024
  20. bigspider commented at 12:36 pm on August 22, 2024: contributor

    As I understand it, the semantic meaning is to provide a form of authentication of the output, in order to establish “this output belongs to a certain identity”.

    Perhaps it would be worth having a generic keytype called maybe PSBT_OUT_AUTHENTICATION_PROOF, and use the keydata to label the type of authentication, for example reserving keydata = 0x00 for the DNSSEC_PROOF as per the rest of the specs, and leaving the meaning undefined for any other keydata. It costs a single additional byte per output, but avoids having to define a new keytype if/when other approaches to the authentication of outputs are proposed.

  21. TheBlueMatt commented at 1:58 am on August 25, 2024: contributor

    Wouldn’t the Authentication Chain already contain the name since it has the record itself?

    Technically yes, but the Authentication Chain is just a list of records “in no particular order”, which makes it somewhat annoying to figure out the name. If you have a wildcard it could even be impossible.

  22. 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.
    b0d5a07943
  23. TheBlueMatt force-pushed on Aug 29, 2024
  24. achow101 commented at 7:34 pm on August 29, 2024: member
    ACK b0d5a0794333bfcf103c3642b168c4338320c48e
  25. murchandamus approved
  26. murchandamus commented at 8:15 pm on August 29, 2024: contributor
    Looks good to me, merging this as it only adds specification for how to handle PSBTs and adjusts “human-readable address” to “human-readable name in the BIP text. Also has sign-off from BIP 174 author.
  27. murchandamus merged this on Aug 29, 2024
  28. murchandamus closed this on Aug 29, 2024

  29. jonatack commented at 8:25 pm on August 29, 2024: member
    Post-merge lgtm
  30. jonatack removed the label Pending acceptance on Aug 29, 2024

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-09 06:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me