BIP‑353: Clarify TXT record structure and concatenation order (single RR; RDATA order; no cross‑RR joins)#2000
Merged
murchandamus merged 3 commits intobitcoin:masterfrom Oct 11, 2025
Merged
Conversation
BIP-353: Clarify TXT record structure and concatenation order (single RR; RDATA order; no cross-RR joins)
removed: “If more than one TXT RR beginning with bitcoin: … treat as invalid.” -- redundant.
Member
|
cc: @TheBlueMatt |
murchandamus
added
Proposed BIP modification
Pending acceptance
TheBlueMatt
reviewed
Oct 9, 2025
Contributor
TheBlueMatt
left a comment
TheBlueMatt
left a comment
There was a problem hiding this comment.
Changes LGTM. I worry we may end up too deep in DNS jargon for bitcoiners who might not know anything about DNS (or even that TXT records are made up of multiple strings rather than one), but its fine either way.
bip-0353.mediawiki
Outdated
| Payment instructions are indexed by both a user and a domain. Instructions for a given <code>user</code> and <code>domain</code> are stored at <code>user</code>.user._bitcoin-payment.<code>domain</code> in a single TXT record. | ||
| Payment instructions are indexed by both a user and a domain. Instructions for a given <code>user</code> and <code>domain</code> are stored at <code>user</code>.user._bitcoin-payment.<code>domain</code> in a single TXT RR. | ||
|
|
||
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <code><character-string></code>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. |
Contributor
There was a problem hiding this comment.
I mean sure, but this is also the definition of a TXT RR :)
Member
There was a problem hiding this comment.
Might be nice for readers not to need to look it up separately.
Member
There was a problem hiding this comment.
I’m not sure what you were exactly going for, but if you wanted to render that as <character-string>, the < and > is done twice to the point it has an unintended outcome:
This is what the rendered file looks like:
I think one of the following would have the intended outcome:
Suggested change
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <code><character-string></code>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. | |
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <code><character-string></code>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. |
Suggested change
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <code><character-string></code>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. | |
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <character-string>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. |
murchandamus
removed
the
Pending acceptance
murchandamus
reviewed
Oct 9, 2025
Member
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Looks like conceptually the change is fine, but could you check out the formatting?
bip-0353.mediawiki
Outdated
| Payment instructions are indexed by both a user and a domain. Instructions for a given <code>user</code> and <code>domain</code> are stored at <code>user</code>.user._bitcoin-payment.<code>domain</code> in a single TXT record. | ||
| Payment instructions are indexed by both a user and a domain. Instructions for a given <code>user</code> and <code>domain</code> are stored at <code>user</code>.user._bitcoin-payment.<code>domain</code> in a single TXT RR. | ||
|
|
||
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <code><character-string></code>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. |
Member
There was a problem hiding this comment.
I’m not sure what you were exactly going for, but if you wanted to render that as <character-string>, the < and > is done twice to the point it has an unintended outcome:
This is what the rendered file looks like:
I think one of the following would have the intended outcome:
Suggested change
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <code><character-string></code>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. | |
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <code><character-string></code>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. |
Suggested change
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <code><character-string></code>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. | |
| The TXT RR’s RDATA <b>MUST</b> consist of one or more DNS <character-string>s (see [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035 §3.3.14]]), each ≤255 bytes. |
bip-0353.mediawiki
Outdated
| Clients resolving Bitcoin payment instructions MUST ignore any TXT records at the same label which do not begin with (ignoring case) "bitcoin:". Resolvers encountering multiple "bitcoin:"-matching TXT records at the same label MUST treat the records as invalid and refuse to use any payment instructions therein. | ||
|
|
||
| Clients resolving Bitcoin payment instructions MUST concatenate all strings in the TXT record before processing the complete URI.<ref>TXT records are defined as "one or more character-strings" in [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035]], and a "character-string" is a single byte (with a max value of 255) followed by that many characters.</ref> | ||
| Clients resolving Bitcoin payment instructions <b>MUST</b> reconstruct the <code>bitcoin:</code> URI by concatenating the TXT RR’s <code><character-string></code> fields in <b>RDATA order</b>, without inserting separators, before parsing.<ref>DNS TXT RDATA consists of one or more length-prefixed strings with a maximum of 255 bytes of content; see RFC 1035 §3.3.14.</ref> |
murchandamus
added
the
PR Author action required
Fix markup: use literal <character-string> instead of html entities <…>
Member
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
New commit just fixed the formatting issue, the text remains otherwise the same as what was previously signed off on by the BIP author. LGTM.
murchandamus
removed
the
PR Author action required
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Clarifies existing intent without changing the on‑wire format.
• Publishers: one TXT RR whose RDATA may contain multiple s (≤255 bytes each, RFC 1035 §3.3.14).
• Clients: concatenate the RR’s strings in RDATA order (no separators) before parsing; do not concatenate across multiple TXT RRs; if multiple bitcoin: TXT RRs exist at the same name, treat as invalid.