作者：SHINOBI

来源：https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-payments

Matt Corallo 在几周前提出了一项用于协调比特币支付的 BIP。出于许多原因，不论是链上支付还是链下支付（比如使用闪电网络这样的协议），发起比特币支付在协调上始终有一些难点。在使用电子系统，比如电子邮件和 Paypal、Cashapp 这样的支付系统时，人们非常习惯于有一个静态的标识符。如果你想要给 John 发送一封 email，你只需要给 “john@【邮箱域名】” 发送即可。或者，如果你想在 Cashapp 上给 John 转一些钱，你只需在 Cashapp 中找到 John 的账户，然后发送支付就可以了。

这就是人们熟悉的用户体验，而且，在涉及这样根深蒂固的用户行为和期待的时候，要让他们立即改变行为会更加困难。如果你给他们的工具要求他们的行为有实质上的变化，它会产生大量的摩擦，而且很有可能直接劝退了大部分人。

链上支付与这种期待相悖，不是因为无法拥有一个静态的标识符（比如地址），而是因为只使用一个链上地址、让跟你有关系的每个人都使用它会带来严重的隐私问题。这会让你的所有支付记录和资金所有权都暴露给跟你交互过的人。如果你只是偶尔收款，比如用比特币来接收工资或收账，这就不是什么问题，你只要打开钱包软件，生成一个新地址就好。但如果你要频繁收款，尤其是在你不会直接请求支付的时候，这会变成一个沉重的负担。

这就是 BTCPay Server 这样的工具诞生的原因：为了降低人们搭建所需的基础设施来自动化收款的门槛，同时保证不犯低级错误，例如给每个要支付给你的人出示同一个地址。然而，这还是需要用户运行一个持续联网的服务端。虽然 BTCPay Server 已经极大地降低了理解的门槛，这对只是希望能够被动收款的用户来说依然是很大的负担。

闪电网络也是一样的（只会更糟）。一张闪电发票只能用在一次收款中。链上地址是可以复用的，只不过复用是个糟糕的习惯；而闪电发票直接是不能复用的。一旦发票被支付过了，或者过期了，签发这张发票的闪电节点会直接拒绝凭此发票发起的支付尝试。这个机理导致了 LNURL 规范（以及在它基础上的 Lightning Address）的建立。LNURL 是一套通过一个静态 IP 来连接一个 HTTP 服务端的协议；这个静态的 IP 只需分享一次，就可以从目标服务器拉取一张真实的闪电发票，然后就可以按发票发起支付了。在此基础上，Lightning Address（“闪电地址”）是一套命名方案，结构上类似于邮件地址：John@【LNURL 服务端域名】。

所有这些解决方案都有缺点。除了运行你的比特币钱包软件和闪电节点，你还需要运行额外的软件（一个 HTTP 服务端）、保证它全时在线；向接收方的 BTCPay/LNURL 服务端请求支付也会泄露支付方的 IP 地址；此外，还需依赖于 TLS 证书权威。

直接使用 DNS

像 LNURL 这样的 HTTP 服务端工具，在解析闪电地址时，会使用域名（domains）来解析连接到 HTTP 服务端的连接。类似地，BTCPay Server 也全部配置呈使用域名，而不是使用裸的 IP 地址。Matt 的洞见是，为什么我们不减少对 HTTP 的依赖，而直接使用“动态域名系统（DNS）” 本身呢？

DNS 允许你将一段 TXT 记录跟一个给定的域名关联起来，因此可以从 DNS 服务器请求小体积的、人类（或者机器）可读的记录。再结合 “动态域名系统安全插件（DNSSEC）”，DNS TXT 记录提供了一项机制，可以用来查询支付信息，而无需运行一个 HTTP 服务端，同时也提供了多一些灵活性和开放性。DNSSEC 为密码学签名的 DNS 条目提供了许多工具，包括 TXT 记录，同时 DNS 的层级式架构中还内置了 DNS 公钥。这保证了你查到的 TXT 记录就是被 根服务器/公钥 签名过的、分发到低层级 DNS 服务器的记录。

这就是使用 SND 作为一种拉取支付数据的手段的真正好处：跟运行一个 HTTP 服务端的要求说再见。TXT 记录可以编码一个链上的比特币地址（虽然该 BIP 明确反对这样做，如果你不能定期轮换新地址以避免地址复用的话），但更重要的是，它还可以包含一个 BOLT12 闪电要约。

这些记录可以从任何 DNS 服务器、你自己的本地服务器、你的互联网服务商、甚至是谷歌和 Cloudflare 这样的公开服务器上拉取得到。从这个基本角度看，基于 HTTP 的解决方案的一个缺点就已经解决了；你不会再向自己尝试支付的人泄露自己的 IP 地址。现在，在使用你的互联网服务商的 DNS 或者谷歌、Cloudflare 的公开服务器时，如果你不使用虚拟私人网络或者 Tor，你就会向它们泄露你的 IP 地址；也正因此，该 BIP 建议支持通过一个虚拟私人网络或者 Tor 来运行 DNS 解析。

将这个提议与 BOLT12 相结合，你就不再需要运行附属软件了（这些软件对于业余用户来说是非常真实的安全性问题），并且仅凭域名的所有权就获得用户所需的一切：用一段简单的、肉眼可读的标识符来定位支付信息。BOLT12 不要求 HTTP 服务端，它在直接通过闪电网络的洋葱路由连接中发放真正的发票；而且，它支持 “要约（Offer）”，这种静态的标识符可以用来找出通达这个闪电节点的洋葱路径。问题在于要约是被编码成大量看起来随机的字符串的，就跟发票一样，所以它不是一个易读的标识符，而只适合于扫码或者 复制-粘贴。

通过在一个 DNS TXT 记录里存储一个要约，要向该用户支付的人只需将 TA 的域名输入自己的钱包软件，然后钱包软件就可以拉取 TXT 记录、拉取 BOLT12 要约，然后发起支付。除了闪电节点，不需要运行任何服务端、任何额外的软件，DNS 系统会为用户处理好一切，只需托管一个想要给该用户支付的人能找到的 BOLT12 腰围。

这是一个完美的免信任的系统嘛？不是。但它是不是比基于 HTTP 的系统更好？显然。这些问题的根结在于，大部分人对周围的电子系统有一个印象，这使他们对用户体验和可行操作产生了特定的期待。如果不复制这样的用户体验，大部分人都会直接使用能够满足这种用户体验期待的方案（而不是适应原生的体验）。给定这个现实，要把比特币塞进这个用户体验期待的框框内，设计目标就应该是以最少的信任因素、最小的用户负担、最少的潜在隐私性损失，满足用户的需要。我认为，与现有的解决方案相比，Matt 的 BIP 最贴合这个框框。

（完）