一串像 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 的地址，抄错一个字符就可能把钱送进黑洞，念给电话那头的人更是灾难。地址不可记，是比特币早期最刺眼的体验问题之一。BIP-70 那条支付协议路线（BIP70 支付协议兴衰史：比特币收款账单为什么没能标准化 讲过它的兴衰）想用另一种结构绕开它，而在更早的 2011 年 12 月，BIP-15 直接正面提出了”别名”这个话题——用一个好记的名字换到一个能收钱的地址。这份提案最终状态是 Closed，但它值钱的地方在于它没有只给一个方案，而是把当时能想到的四条技术路线摆在一起逐个批判。
FirstBits：从已有地址里抠出唯一前缀
最省事的办法是根本不建新系统，直接拿真实地址的开头若干字符当名字。规则是把地址转小写，再截到能唯一区分的前几位。提案举的例子是布拉格一个黑客空间，地址 1BRMLAB7nryYgFGrG8x9SYaokb8r2ZwAsX 化成了别名 1brmlab。只要给到这一段，软件就能在链上已存在的地址里找到唯一匹配。它的软肋也写在提案里：一，能生成什么样的名字受制于算力和 vanitygen 撞地址的成本，往往只能凑出近似而非精确的心仪词；二，扩展性极差——每个查询节点都得保存有史以来所有比特币地址来做前缀匹配，地址数量随网络增长，节点负担指数级膨胀；三，轻客户端没法自己查，必须信任一个第三方替它做别名到地址的解析。
DNS TXT：把映射塞进域名记录
第二条路借用现成的域名系统，把”名字到地址”的映射写进域名的 TXT 记录里，客户端查询取回。好处是不用另建网络，坏处一分为二：使用侧，想登记映射的人得会配 DNS、懂那套工具；安全侧，DNS 本身在设计上不安全，同一网络里可以伪造记录，即便有 DNSSEC 等修补也不是为比特币这种直接关系钱款的场景量身定做。
约定端口服务与 HTTPS 服务
再往下两条是变体：一种用 DNS 解析出主机 IP 后，连一个约定端口的小服务，报上用户名拿回地址；另一种把这件事搬到 HTTPS Web 服务上，用一个统一的 URL 格式取地址。它们的共同优点是接口简单、由服务方负责维护映射的更新，共同缺点是把信任从”链或协议”挪到了”那台服务器”——服务器返回的地址对不对、它会不会变卦，用户没法脱离对服务方的信任去独立验证。
Namecoin：用另一条链存映射
提案里评价最高的一条路线是 Namecoin：把别名和比特币地址的关联写进 Namecoin 区块链，查询时读那条链。因为是个去中心化的”域名系统”，它不像前面几种那样必须信任某个服务器，可用性高、登记也没有门槛。提案给了形如 id/某名字 的查询，返回一个 JSON，里面能放默认地址，也能按用途列出多个地址（比如 donate 一个、default 一个），甚至允许带一个 url 加 signedWith，让钱包用签名校验返回的地址有没有被偷换。它的隐患在于把安全性绑定在另一条链的运行状况上。
为什么别名没成，但它仍在
BIP-15 通篇是”比较与吐槽”而非拍板，最后没有哪条方案被比特币协议采纳，提案停在 Closed。名字到地址这件事，后来交给了一层层外部系统去做：交易所充值地址、收款方给的二维码、以及各类替人保管地址簿的第三方命名服务，而不是共识层本身。今天你给钱包起的账户标签、交易所里的提现地址簿，本质上都是 BIP-15 想在链上解决、最终却在应用层解决的同一个问题的不同化身。读懂它，能帮你在一句「直接付我 foo@bar.net 就好」（BIP-15 服务端方案里的原样例）面前，先问一句：这个名字到底由谁来保证不被换掉。
风险提示：本文描述历史提案与命名机制，不构成投资建议；任何把名字映射到地址的系统，安全边界都在”谁有权改这条映射”，付款前请以地址原文核对为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。