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.
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-
TheBlueMatt commented at 6:35 pm on July 28, 2024: contributor
-
jonatack added the label Proposed BIP modification on Jul 28, 2024
-
jonatack requested review from achow101 on Jul 28, 2024
-
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.jonatack added the label Pending acceptance on Jul 28, 2024TheBlueMatt force-pushed on Jul 30, 2024TheBlueMatt commented at 4:53 pm on July 30, 2024: contributorRealized this doesn’t actually work without the name itself, so force-pushed that in.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.
murchandamus commented at 5:48 pm on July 30, 2024: contributorSeems reasonable. @achow101, could you take a look please?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.
TheBlueMatt force-pushed on Jul 31, 2024murchandamus assigned murchandamus on Aug 6, 2024murchandamus unassigned murchandamus on Aug 6, 2024murchandamus assigned achow101 on Aug 6, 2024Freeanjel approvedin 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.
achow101 commented at 8:34 pm on August 19, 2024: memberRealized 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?
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…bitcoin deleted a comment on Aug 19, 2024bigspider commented at 12:36 pm on August 22, 2024: contributorAs 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 maybePSBT_OUT_AUTHENTICATION_PROOF
, and use thekeydata
to label the type of authentication, for example reservingkeydata = 0x00
for the DNSSEC_PROOF as per the rest of the specs, and leaving the meaning undefined for any otherkeydata
. It costs a single additional byte per output, but avoids having to define a newkeytype
if/when other approaches to the authentication of outputs are proposed.TheBlueMatt commented at 1:58 am on August 25, 2024: contributorWouldn’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.
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.
TheBlueMatt force-pushed on Aug 29, 2024achow101 commented at 7:34 pm on August 29, 2024: memberACK b0d5a0794333bfcf103c3642b168c4338320c48emurchandamus approvedmurchandamus commented at 8:15 pm on August 29, 2024: contributorLooks 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.murchandamus merged this on Aug 29, 2024murchandamus closed this on Aug 29, 2024
jonatack commented at 8:25 pm on August 29, 2024: memberPost-merge lgtmjonatack 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