每一个 Taproot 地址背后都藏着一次“公钥加哈希”：输出密钥等于内部公钥加上一个由脚本承诺推出的标量再乘生成元。这个加法发生在钱包创建地址的那一刻，由钱包软件完成，脚本自己对它既看不见也做不了。BIP-449 提议把这条曲线加法下放到合约内部——新操作码 OP_TWEAKADD，栈上给一把 x-only 公钥和一个 32 字节标量，脚本当场算出调整后的公钥推回栈，随后照常验签。作者 Jeremy Rubin，2026 年 3 月 5 日立项，Draft，操作码暂挂在成功位 0xBE，注明理想落点是“未来大概率不会改作他用的空闲成功位”。
先补一把直觉钥匙：椭圆曲线公钥可以做算术，而且结果仍是合法公钥——给定 P 和标量 t，Q 等于 P 加 t 乘 G，知道 t 的人就等于在 P 代表的“钥匙底座”上叠加了一层只属于自己的控制：想让 Q 花掉这笔钱，必须同时持有 P 的私钥和 t。Taproot 的地址构造正是这套算术的产品；BIP-449 做的事是让脚本能在运行时亲手做一遍，而不是只能信任创建期留下的成品。
栈语义逐条读。输入两样：pubkey32 是 32 字节的 x-only 公钥坐标，tweak32 是大端整数 t。任何一步不满足就失败：两样必须各占 32 字节；t 大于等于曲线阶就失败；把 x 坐标按 BIP-340 的偶数 Y 规则抬升成曲线点，若根本不存在这样的点则失败；算出的 Q 若是无穷远点则失败；全部通过，把 Q 的 x 坐标作为 32 字节推回栈。只在 tapscript（见证版本 1、叶子版本 0xc0）里生效，放进旧脚本语境它被禁用并直接报错。注意规范里那个小注：t 等于零时仍然可能因公钥不合法而失败——零调整不豁免合法性检查。
它能长出什么合约？文档给了四条谱系。密钥揭示型：合约先承诺一个基础钥匙，Witness 里才揭示标量，揭示的标量加公开验算构成对“我知道这个钥匙关系”的证明。签名顺序证明：先签的人在签名里承诺了“后签的人将使用哪把钥匙”，后签者调整钥匙再签，顺序信息被曲线算术钉死，这在没有该原语时要么靠额外轮次要么靠信任。委托与再委托：一个参与者在不看到另一参与者私钥的前提下，把对方的签名权合法地“平移”一把钥匙。以及目标 tweak 契约：对两个 tweak 关系做匹配，等价于证明掌握了某个离散对数。谱系共同的底色是同一句话——把“钥匙与钥匙之间的代数关系”变成链上可验证的谓词，替代过去用多把完整公钥平铺进脚本的笨办法。
边界同样明确：它只暴露曲线加法这一个原语，不做哈希、不做 taproot 式的标签 tweak 构造，也不管协议层的逻辑组合；与栈上验签的 BIP-348 和读取内部密钥的 BIP-349 搭配才构成完整工具箱，三者都被它在动机里点名。
常见误区。一，把 tweak 当成加密层——它是公开的算术，任何观察者都能验算，不泄露任何秘密，前提是不把标量当秘密长期复用。二，把它与 BIP-346 的字段检视混为同一功能：一个算钥匙，一个算交易哈希。三，看到“密钥可推导”就联想到 HD 派生：硬化派生发生在钱包内部用私钥参与的哈希链上，与此处纯公钥的曲线加法是两回事。
快速问答。问：会稀释地址隐私吗？答：调整关系在链上是可重算的公开事实，脚本设计者需要自己评估哪些分量放承诺、哪些放 witness。问：为什么必须 x-only？答：与 BIP-340 的签名与抬升规则对齐，省一个奇偶字节。问：现在链上能用吗？答：不能，今天 tapscript 对 0xBE 按成功位处理，直接放行。
用一把尺收尾：过去验证“钥匙 B 比钥匙 A 多一个可控增量”这件事，脚本要靠把 A、B 两把钥匙都写全再靠人相信它们的关系；OP_TWEAKADD 之后，脚本自己拿 A 加增量算出 B 再验签，链上少写一整把公钥，多出一段可验证的推导。
风险提示：本文讨论未激活提案，不构成投资建议；涉及密钥结构与签名方案的任何变更前，请以已激活规则与专业审计为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。