静默支付把收款的惊喜从链上挪进了扫描循环：发送方用双方的共享秘密推导出一个一次性的 Taproot 输出，收款方扫区块时再把这个推导算回来，链上只看到一笔普通的 P2TR 转账。社区随后开始给 PSBT 补静默支付的协作签名支持：BIP-374 与 BIP-375 负责把钱送出去；而把收进来的钱花出去的规范文本，是署名 nymius 的作者提交的 BIP-376——2026 年 2 月 5 日领号，状态 Draft，依赖 352、370、371 三份文件。
为什么花钱不能直接续写 375
提案的脚注回答得很规矩：社区按参与者视角给静默支付分了家，发送侧归 BIP-375，它的标题就写着 Sending Silent Payments with PSBTs；而支出属于收款方的事务，按这个惯例应当另立编号。技术账也不同：375 关心如何从收款公钥与 outpoint 造出锁定的 tweak，把输出做出来；376 关心的是支出时签名方必须拿回当初那个 tweak，才能把扫描时记下的秘密还原成能解锁的私钥。发送与花费需要的字段因此不是同一组。
两个新字段与一条防盗规则
规范新增两个逐输入字段。PSBT_IN_SP_SPEND_BIP32_DERIVATION（键类型 0x1f）以 33 字节支出公钥为索引，值段装主密钥指纹加派生路径；不想暴露派生细节的 Updater 可以填四字节的零指纹冒充。PSBT_IN_SP_TWEAK（0x20）没有键数据，值段是 32 字节裸 tweak——按 BIP-352 的支出规则算出的 BIP0352/SharedSecret 标签哈希，带标签收款时再叠加 BIP0352/Label 项。
签名方的义务被写成一连串 MUST：把支出私钥与 tweak 相加得到签名私钥，若推导点的 Y 坐标为奇就取反，然后核对这个点的 X 坐标是否等于输入脚本里的输出密钥——不等就必须失败。理由很硬：tweak 是 Updater 填的，写错或被恶意改写时，不作核对的签名方会为一把自己并不控制的钥匙签出完全合法的 Schnorr 签名，资金可能被直接搬走。最终化者的职责同样明确：确认带 tweak 的输入都有 key path 签名，按 BIP-341 组装见证，并把两个新字段连同临时签名数据在完成后清除。
三十二字节与四百一十三字节的账
为什么把 tweak 直接塞进 PSBT，而不是让签名方自己重算？附录逐字段拆了一笔账：对一笔有两笔传统输入、一笔 Taproot 输出的交易，要让签名方复算 tweak，就得把前交易的头部、输入、输出、见证全部塞进 PSBT，多花约 413 字节——差不多是裸 tweak 的十倍。而 tweak 在扫描那一刻就算好了，存下来远比重新生成便宜。为什么不借用现有的 PSBT_IN_TAP_MERKLE_ROOT 之类同尺寸字段？提案答：tagged hash 前缀不同，且硬件钱包无法凭字段名判断 tweak 语义，专用字段名最省事；用私有字段区则脆弱且各家不统一。PSBT 的扩展性设计保证旧软件会忽略未知字段，向后兼容由此成立。而参考实现与测试向量在文本里仍是 TODO——这是一份在等实现的规范。
快速问答
问：这会不会在 PSBT 阶段泄露静默支付身份？ 答：新增的都是逐输入数据，派生字段允许把指纹清零；tweak 本身是 32 字节哈希结果，不直接暴露扫描私钥。
问：为什么索引里的公钥是 33 字节而不是 32 字节的 x-only 形式？ 答：BIP-352 的支出密钥带奇偶符号，符号决定解锁私钥取正还是取负，x-only 会丢掉这个信息。
问：它现在可用吗？ 答：状态 Draft，参考实现与测试向量留白，属于文本先行、工具链待跟进。
一条判断线
评估任何给协作签名格式加字段的提案，看三件事：字段是不是只装本角色已知的最小信息、验证方能否本地核对真伪、旧实现忽略字段会不会花错钱。BIP-376 的三个答案分别是逐输入两字段、签名方强制核对推导点、忽略字段的旧软件不会给静默支付输入产出见证——它把风险挡在了格式之外。
常见误区
一是把 376 读成 375 的勘误，两者管的是静默支付生命周期的两端；二是以为 tweak 可以随时重算、不必保存，附录的字节账正说明事后重算要整包携带前交易；三是忘记让最终化者删除临时字段——带着 tweak 的 PSBT 继续流转，等于多送旁观者一组关联线索。
风险提示：本文解释协议草案的字段设计，不构成投资建议；字段定义以 BIPs 仓库当期原文为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。