Clarifies existing intent without changing the on‑wire format.
• Publishers: one TXT RR whose RDATA may contain multiple <character-string>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.
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.
cc: @TheBlueMatt
35 | @@ -36,7 +36,9 @@ Thus, using TXT records to store Bitcoin payment instructions allows for human-r 36 | Bitcoin wallets MUST NOT prefer to use DNS-based resolving when methods with explicit public keys or addresses are available. In other words, if a standard Bitcoin address or direct BIP 21 URI is available or would suffice, Bitcoin wallets MUST prefer to use that instead. 37 | 38 | === Records === 39 | -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. 40 | +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. 41 | + 42 | +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.
I mean sure, but this is also the definition of a TXT RR :)
Might be nice for readers not to need to look it up separately.
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: <img width="747" height="64" alt="image" src="https://github.com/user-attachments/assets/4984058d-11c4-49be-aea0-dc7e3a8ccc3b" />
I think one of the following would have the intended outcome:
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.
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.
53 | @@ -52,7 +54,9 @@ For payment instructions that have a built-in expiry time (e.g. Lightning BOLT 1 54 | 55 | 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. 56 | 57 | -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> 58 | +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>
Same as above: <img width="758" height="93" alt="image" src="https://github.com/user-attachments/assets/3e01fd56-c823-42d7-8374-dc9a688198e3" />
Fixed - my bad.
Looks like conceptually the change is fine, but could you check out the formatting?
Fix markup: use literal <character-string> instead of html entities <…>
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.