两种协议相遇时的缝隙
静默支付（BIP-352）让收款方公开一个长期地址，每笔收款却在链上生成互不关联的一次性地址：付款方用收方的扫描公钥、支出公钥与自己的一次性私钥算出那个地址。协作签名格式 PSBTv2（BIP-370）则负责把一笔交易在多个 signer、输出描述符与协调者之间传递。两条规范各自完整，拼在一起却缺一块拼图——PSBT 的输出字段假设”收币地址是明摆着的脚本”，而静默支付输出的真实身份分散在收方的两把公钥和一笔输入的临时数据里。BIP-375 的任务就是补上这块：给 PSBTv2 定义专门的字段，把静默支付所需的信息放进标准容器。它在 2025 年初提出，依赖 BIP-352、BIP-370 与 BIP-374（用于地址推导的 DLP 机制），状态 Draft。
字段长什么样
草案把信息分成两级。输入级字段记录本次支付借用的那笔输入的公钥与内部密钥信息：静默支付的临时密钥是从被花费输入推导的，参与签名的各方需要知道这笔输入是否被用于静默支付、以哪种协议版本使用。输出级字段则携带收方两个公钥（扫描钥与支出钥）加上可选前缀信息，供能执行静默地址推导的角色计算真正落链的输出脚本。两个字段的定位很克制：能理解 BIP-352 的实现读取它们并算出一次性地址；读不懂的设备按 PSBT 的未知字段规则忽略即可，兼容性不破。规范同时给各角色划了新边界——添加者负责写入正确的静默字段，签名者若不能验证静默输出就必须拒绝，而不是照签一个自己看不懂的脚本。
为什么混合器与硬件设备特别需要它
静默支付最初是为”公开一个收款码、每笔自动分叉”设计的，但在 CoinJoin 与双花防护场景里，静默地址必须由多方共同构造成同一笔交易的一部分。没有标准字段时，钱包厂商用私有扩展传这些信息，不同实现互不认识。PSBTv2 自带多轮字段（earliest UTXO、next global serializer 等）就是为协作场景铺的路，BIP-375 在这条路上补协议语义：硬件签名器看不到明文地址不代表不能安全参与——它检查描述符、检查静默字段与输入的一致性，确认这是一枚合法推导即可签字。对审计者，这些字段还带来一个新义务：交易审查工具若不支持静默支付，应显式提示存在”你看不懂但可能藏地址”的输出，而非静默展示一个空脚本。
边界与误读
这个 BIP 不改变静默支付的密码学，只改变它在协作容器里的表示法——理解这一点能过滤掉一半误读：它不新增隐私保证、不改变链上形态、也不要求全网节点支持。另一个易错点：支持字段的钱包若把静默输出当作普通脚本输出直接展示或修改，会直接破坏隐私性甚至丢币，因此各实现的支持列表与降级行为值得逐一核对。草案阶段的字段编号与版本字段都可能随讨论调整，落笔写集成方案前先读仓库最新版。
快速问答
问：BIP-375 和 BIP-352 什么关系？ 答：352 定义协议与推导算法，375 定义这些协议数据在 PSBTv2 中怎么传，一个管机制，一个管信封。
问：现在主流钱包支持吗？ 答：以各家文档为准；草案仍在演进，支持集中在少数专注隐私与 PSBT 深度的实现中。
问：交易在链上能被认出是静默支付吗？ 答：静默支付的设计目标正是链上不可标记——链上只看到普通的 P2WPKH 类输出，区分靠的是收付双方掌握推导信息。
风险提示：本文为协议草案科普；向不认识的交易发起方提供签名授权存在资产风险，任何 PSBT 建议经完整审计工具核验后再签；不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。