协议演进 / BIP/比特币改进提案 / BIP-353
BIP-353
把 BIP-21 支付 URI 写进带 DNSSEC 签名的 DNS TXT 记录，让 ₿user@domain 这样的人类可读名字能安全、私密地解析为收款指令。本 BIP 目前处于已完成状态。
一、档案卡
| 编号 | BIP-353 |
|---|---|
| 标题 | DNS Payment Instructions |
| 作者 | Matt Corallo <[email protected]>, Bastien Teinturier <[email protected]> |
| 指定日期 | 2024-02-10 |
| 讨论日期 | 2024-02-13 |
| 层级 | Applications（应用） |
| 类型 | Specification（规范类） |
| 状态 | Complete（已完成） |
| 阅读版 | https://bips.dev/353 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki |
二、放在哪一族
人类可读收款名字族。它寄生在两个既有标准之上：
BIP-21：bitcoin: URI 方案，本 BIP 放进 DNS 的就是它
BIP-352：静默支付，是 DNS 记录里最理想的链上收款内容之一——静态公开也不会因地址复用丢隐私
它意在延伸并收编既有的 Lightning Address 方案：后者用同样的 user@domain 式名字、经 HTTPS 服务器解析到闪电网络 BOLT 11 发票。原文说，实现本方案的钱包在 DNS 解析失败时可以暂时回退到 Lightning Address 逻辑，但等本方案足够普及后就不应再回退，以免泄漏发送方 IP。
与基于区块链的命名方案、基于 HTTP 的解析方案相比，原文选择 DNS 的理由是：有简洁的“命名空间到公钥映射”密码学证明（DNSSEC）、查询通常经解析器代理而不直接暴露查询者 IP、不依赖臃肿的 TLS 证书机构体系、且任何人都能注册域名建立映射。
三、它要解决什么
用户想要的是像邮箱地址一样好记、好口述、好印在名片上的收款名字。比特币地址与各类支付 URI 又长又易错，手抄、口述、粘贴都容易出错，更谈不上让对方在付款前核对“这个名字到底指向谁的收款指令”。
DNS 恰好是现成的全球分层命名空间：把标签映射到各类记录。配合 DNSSEC，它能用一套顺着 DNS 层级走的、直截了当的 PKI 提供密码学保证，让记录可以无状态地、甚至离线地从单一可信根验证。再加上 DNS 查询通常经由运营商或其他解析器代理，一般不直接暴露查询者 IP；开放解析器遍地都是，找代理很容易。
于是本 BIP 的做法是：把支付指令存进 DNS TXT 记录，得到人类可读、可在硬件钱包上直接核验、解析过程相对私密的收款目的地。
四、规则本身
4.1 记录放在哪、长什么样
user 与 domain 共同索引一条记录，存放在 user.user._bitcoin-payment.domain 的一条 TXT 记录里。
- TXT 记录的数据由一个或多个 character-string 组成，每段最长 255 字节；
- 全部内容拼起来就是一条 BIP-21 URI，以
bitcoin:开头（忽略大小写）。长 URI 就切成多段存放，原文例子里一条 BOLT 12 offer 的 URI 被切成两段； - 所有支付指令记录必须有 DNSSEC 签名；经 CNAME 或 DNAME 跳转也可以，但沿途与最终记录都必须有 DNSSEC 签名；
- 非纯 ASCII 的用户名与域名必须用 punycode（IDN）编码。原文还提醒：解析器不一定支持非 ASCII 标识，钱包应避免使用；支持非 ASCII 的钱包必须防同形字攻击，否则只能显示原始 punycode。
还有一条总原则：有现成的、带明确公钥或地址的收款方式可用时，钱包不得优先用 DNS 解析——能直接用标准地址或 BIP-21 URI 的场合，必须优先用它们。
4.2 解析方必须自己验签
这是本 BIP 最硬的一节：
- 只认以
bitcoin:开头的 TXT 记录，其余同名记录忽略； - 同一标签下若出现多条以
bitcoin:匹配的 TXT 记录，整组作废，一条都不得用； - 拼接 URI 时只能在同一条 TXT 记录内部按 RDATA 顺序无间隔拼接，不得跨多条 TXT 记录拼接；
- 必须把 DNSSEC 签名一路完整验证到根（含 CNAME/DNAME 沿途记录），不得信任远程解析器代为验签；不得接受使用 SHA-1 的签名，也不得接受短于 1024 位的 RSA 密钥（DS 记录用 SHA-1 可接受）；
- 必须支持经 CNAME 或 DNAME 解析；
- 缓存不得超过解析器给的 TTL，也不得超过整条 DNSSEC 链中最低的初始 TTL。
带过期时间的支付指令（如 BOLT 12 offer）要特别小心：DNS 记录必须先于指令本身过期，否则发送方缓存里的可能已是过期指令，付款会失败。
4.3 地址复用与轮换
DNS 里的静态记录天然指向同一个目的地，若里面放的是会被复用的链上地址，就必须尽量勤轮换：用较短的 TTL 让轮换快速生效；一旦某地址收到一笔已确认交易，就应轮换。做不到勤轮换时，干脆不要在 URI 里放链上地址（URI 路径留空）。像静默支付这类静态标识本身不构成链上复用的方案，不受此限。
4.4 显示与复制
验证通过的人类可读名字，钱包显示时应加 ₿ 前缀，形如 ₿user@domain；输入时 user@domain 与 ₿user@domain 两种写法都要能解析。用 @ 作分隔是为了兼容既有名字方案，加 ₿ 前缀是为了减少与同域名邮箱地址的混淆。注意：₿ 只是显示符号，不属于要解析的 DNS 标签。
钱包让用户“复制”收款信息时，应复制底层 URI 而不是人类可读名字，避免粘贴方再做一次 DNS 查询；若确实提供复制名字的功能，复制结果必须带 ₿ 前缀。
4.5 给硬件钱包的 PSBT 证明字段
收款信息可能来自外部设备（如硬件钱包），发送方钱包无法当场上网验 DNS。本 BIP 为此定义了按输出的 PSBT 字段 PSBT_OUT_DNSSEC_PROOF = 0x35：值是 1 字节长度前缀的人类可读名字（不带 ₿），后跟 RFC 9102 格式的 DNSSEC AuthenticationChain 证明。接收设备可离线验证整条签名链；验证时必须检查链中所有 RRSig 的生效时间不晚于当前时间、过期时间不早于一小时之前（为构造与签名之间的延迟留的容差）。原文附了多组有效与无效的证明样例，包括“两条 bitcoin: 记录导致整体失效”这类反例。
五、谁必须动
普通持币人：想用名字的收款方，需要有一个开了 DNSSEC 的域名，并按格式维护 TXT 记录（勤轮换其中的链上地址）；付款方只需在支持本 BIP 的钱包里输入 ₿user@domain 式名字。
钱包开发者：实现 DNS 查询、完整的本地 DNSSEC 验证、CNAME/DNAME 跟随、TTL 缓存规则、₿ 前缀显示与防同形字处理；可选实现 PSBT 中的 DNSSEC 证明字段。原文反复强调：验签必须自己做，不能把信任交给解析器。
域名与 DNS 服务商：无需为比特币改协议，但记录能否用取决于该域名是否部署 DNSSEC。
全节点与矿工、共识层：完全不涉及。本 BIP 不碰链上规则。
六、现在算不算数，以及一个常见误读
状态为 Complete（已完成）：规范已定稿，可供钱包实现。它不是共识规则，不需要激活；是否“算数”取决于域名持有者是否按格式发布记录、钱包是否实现解析与验签。原文没有给出采用统计，本页不臆测。
常见误读：“DNS 解析就是查一下域名，解析器返回什么就信什么——跟打开网页差不多。”不对。本 BIP 的核心恰恰是不能信解析器：钱包必须自己把 DNSSEC 签名从根一路验到底，签名算法太弱（SHA-1、短 RSA）要拒绝，同名出现多条 bitcoin: 记录要整组作废。它借的是 DNS 的命名空间与 DNSSEC 的信任链，而不是“DNS 说什么就是什么”。
七、延伸
- 阅读版：https://bips.dev/353
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki
- 相关：BIP-21 URI 方案、BIP-352 静默支付
- 仓库总目录：https://github.com/bitcoin/bips