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.
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.
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’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:
0The 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.
0The 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.
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>
Fix markup: use literal <character-string> instead of html entities <…>