Taproot 即将落地的前夜，Chris Belcher 在 2021 年 6 月往比特币开发邮件列表投了一份短提案，随后领到 BIP-326 的号：不改共识、不加操作码，只请求链上钱包在花钱时掷一枚硬币——一半概率照旧用 nLockTime 防费率狙击，另一半概率改用 nSequence 达成同样目的。单看每一笔，两种写法都只是为了别让矿工把旧交易塞进当前块；把它们混在一起，链上观察者就分不清你是在花普通钱包余额，还是在结算一条通道。
被暴露的离场动作
提案的动机段把隐私账算得很细。Taproot 允许可锁契约 PTLC 作为 HTLC 的替代：通道合作关闭时，链上看起来只是一次普通的 Taproot 支出，看不到哈希与原像。但如果合约走超时路径关闭，交易里就会出现 OP_CHECKSEQUENCEVERIFY 或带相对锁定含义的 nSequence——在 2021 年的链上，这两个特征几乎等于举牌宣布自己是闪电结算。想让这类交易不被认出来，最便宜的办法不是改它们，而是让更多普通交易天生带着同样的特征。
钱包该掷的两枚硬币
规范给钱包定了两层随机。第一层选字段：支出 Taproot 保护的 UTXO 时，约一半概率写 nLockTime 等于当前区块高度、沿用比特币核心与 Electrum 的现行做法；另一半概率把它留零，改把某个随机挑选输入的 nSequence 设成该输入的确认数——按 BIP-68 的相对锁定语义，这等于声明该输入已满这些块，顺带完成防狙击。多输入交易随机挑一个输入承担。第二层选倒拨：约十分之一的概率，把写入的数值再往回拨 0 到 99 个块，给签名后迟迟没广播的交易留余地——现行 nLockTime 防狙击里也有同款随机分支，两个世界保持一致。
工程边界写得清楚：nSequence 的相对锁定字段只编码到 65535 块，确认数超过这个数的 UTXO 老老实实继续用 nLockTime。提案还要求版本字段取 2、先把所有 nSequence 初始化为对应替换意愿的标准值，再改动其中一格——防狙击的改写不改变替换信号本身。
防狙击逻辑与钉住解法共用一个字段
背景部分对费率狙击的推演值得慢读：矿工故意重挖去孤立对手的最佳块时，想抢的高费交易有一部分因防狙击字段进不了第一个块、只能等第二个块——低通胀时代，重挖的期望收益因此被压低。这份提案把同一逻辑搬进 nSequence：想钉住交易、把低费对手交易焊死在候选块里的对手也会发现，带一块相对锁定的输入在链上随处可见——提案在交易钉住一节提到，给各条花费路径加上一块的相对时间锁是解法之一，而这个锁本身用 nSequence=1 就能表达，于是普通钱包的掩护支出顺手也成了这类解法的藏身处。
快速问答
问：这是共识规则变化吗？ 答：不是。它是信息类提案，钱包可以单方面逐步采用，不采用也不产生任何分叉。
问：为什么强调趁钱包刚开始支持 taproot 就动手？ 答：掩护流量的价值取决于先入场的正常人群规模。若钱包从第一天就带着这套逻辑，超时结算从诞生起就混在普通支出里，事后补效果大打折扣。
问：这个想法最早是谁提的？ 答：提案致谢写明思路最早由 David Harding 提出，Belcher 把它整理成 BIP 文本。
一条判断线
评估这类协议隐私补丁，问三个问题：它改变验证规则吗？掩护集从哪里来？迟到采用会不会让效果贬值？BIP-326 的三个答案分别是不改、来自普通钱包的自我混入、会——所以它的正文几乎全篇幅在呼吁钱包开发者现在就动手，而不是论证机制可行性。
常见误区
一是把它读成 PTLC 本身，可锁契约的规范在别处，这份只管掩护；二是以为 nSequence 版防狙击可以完全替代 nLockTime，绝对锁定需求与超过 65535 块的存量 UTXO 仍必须走前者；三是忘记它至今是 Draft，从未自动生效于任何钱包。
风险提示：本文解释隐私工程提案的机制与设计动机，不构成投资建议；细节以 BIPs 仓库当期原文为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。