公开贴出一个比特币收款地址，等于把这条线上的所有进出账都挂上同一个门牌：链上分析能顺着地址把余额、对手方、收款频率看个大概。天天换地址能缓解问题，钱包与收款流程却要为此多养一套服务器。BIP-351 提出的私密支付（Private Payments）给出第三条路：对外只分享一个静态支付码，真实地址由每对收发双方各自算出来，链上看起来互不相关。需要先说明状态：这份 2022 年 7 月获得编号的提案，在仓库头信息里标为 Closed，属于未成为广泛标准的方案，本文只按文本讲清它的机制与适用边界。
要解决的隐私死角
提案在动机段把常见选项摆了一遍。静态地址适合一次性私聊收款，用于长期收款或捐赠则变成数据收集焦点。直接分享扩展公钥只能服务单一付款方，而且对方可能把钱发到你根本花不出的脚本类型里。自建收款服务器能每次发新地址，但那是企业和极客的负担，服务器还可能被端掉。上一代方案 BIP-47 用通知交易建立配对，问题是通知地址是公开的，付款方稍不留意 Coin 选择，两人的关系就被永久钉在链上。BIP-351 的目标就是修这两个洞：不暴露配对关系，也不给错误脚本留门。
支付码长什么样
规范把一个支付码定义为 35 字节：前两字节是地址类型标志位，后面 33 字节是一个压缩公钥。编码沿用 bech32m，主网前缀是 pay、测试网是 payt，成品是一串像网址路径一样的字符串。地址类型位现在定义了三种：P2PKH、P2WPKH、P2TR，每个占一个比特位。发送方只能从收款方声明支持的类型里挑一种，这就堵住了往对方花不了的脚本里打钱的坑。
双方怎么算出同一个地址
核心是一场单向的密钥协作。发送方有自己的账户扩展密钥，给每个收款对象分配一个私有索引，从这个索引派生出一把子公钥；收款方也公开不了任何东西，全靠通知交易交换必要材料。通知交易是一笔带 40 字节 OP_RETURN 输出的交易：两字节的固定搜索串 PP、四字节的通知码（发送方子私钥与收款方公钥做椭圆曲线乘积后哈希的前四字节）、发送方那把 33 字节子公钥，再加一字节地址类型序号。收款方扫描到匹配自己通知码的输出，就存下这把子公钥，双方各自做 ECDH，算出一套共同的观察地址序列；之后每笔付款用计数递增派生新地址。提案特别写了隐私账：只要发送方管好选币，连通知交易都可能查不到头尾；即便选币不慎暴露了发送方，收款方的收款史依然不被串联。
该记住的边界
这套设计的隐私强度取决于三件事。谁在扫描：收款方要持续扫链寻找通知，钱包实现的成本比 BIP47 略高。通知上链：首次配对仍要花一笔链上交易，OP_RETURN 内容对全网可见，靠的是别人无法反推配对关系，而不是藏住字节本身。发送方的 Coin 控制：提案原文承认，通知交易的选币若与发送方已有资产关联，隐私效果打折。因此它适合的是个人与小商家的长期收款场景，不替代混币类工具，也绝不意味着匿名。
快速问答
问：这份提案能用吗？ 答：仓库头信息标为 Closed，未成为广泛部署的标准，钱包支持以各钱包自己的文档为准，不要按文本假设某家一定支持。 问：收款码泄露了会怎样？ 答：它能公开的初衷就是不怕分享：外人拿不到每对收发双方算出的具体地址序列，但通知码与派生逻辑设计的前提是收款方私钥不泄露。 问：和静默支付 BIP-352 什么关系？ 答：同一类需求的两条路线——352 让一个地址收多次款不留关联，351 用一个支付码派生整套地址，机制与权衡不同。
风险提示：本文是协议文本的科普解读，不构成投资建议；隐私技术也有法律与合规边界，请遵守所在地区法规。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。