OP_CHECKSIG的一堵墙
比特币脚本里 OP_CHECKSIG 的语义是焊死的：拿脚本中的公钥，对当前交易按摘要规则重算，再比对签名。脚本永远回答不了”这个人是否签过某段任意数据”。想让验签对象变成栈上的哈希、某个承诺、某段脚本的分支，就得把数据挤进交易结构本身，尺寸与费用都变样。2024 年 11 月获得编号的 BIP-348 提交 OP_CHECKSIGFROMSTACK（圈内简称 CSFS），把签名算法与被签内容解耦：签名仍按 BIP-340 的 Schnorr 规则验，消息却改从栈上取。
规则本身只有五条
在 Tapscript（叶子版本 0xc0，即 BIP-342 定义的环境）验证时，CSFS 从栈顶弹出三样东西：公钥、消息、签名。规则紧凑：栈上不足三个元素立即失败；公钥长度为零立即失败；公钥恰为 32 字节则按 BIP-340 直接验签（消息不做预哈希，BIP-340 本身兼容任意长度输入），非空签名验失败即终止脚本；公钥长度既非零也非 32 字节时视为未知密钥类型——不验签、按成功处理，与 BIP-342 给未知密钥类型留的扩展接口同一哲学；活到最后的脚本，若签名是空向量则推一个空值（表达”未签”的多方原语），否则计一次 sigops 并推 1。每条 CSFS 计入区块的签名操作预算，约束方式与所有验签类操作码相同，不给后门。
占用OP_SUCCESS204的软分叉
部署手法比机制更值得细看。Tapscript 里保留了一批 OP_SUCCESS 操作码，遇到即通过，未来再逐个收紧。BIP-348 选中 OP_SUCCESS204（字节 0xcc），把”见到就过”改写成”按规则验签”。旧规则下靠 0xcc 蒙混过关的支出，在新规则下会被拒绝——一次教科书式的软分叉收紧。谁曾依赖 0xcc 的通过语义，谁的支出会失效，这正是它必须走完完整部署流程、而不能随软件升级悄悄上线的原因。参考实现挂在 Bitcoin Core 的 29270 号 PR，状态 Draft，激活方式在文本里仍标注待定。
它撬动的两类构造
提案给了两个动机。第一类是闪电对称通道：OP_CHECKTEMPLATEVERIFY <pubkey> OP_CHECKSIGFROMSTACK 配上含 CTV 哈希与其签名的支出栈，在效果上等价于带 ANYPREVOUT 语义的 <pubkey> OP_CHECKSIG——双方更新通道状态时不必再互签对方的旧状态，闪电最初设计的对称性得以复活。提案自己对比了路线：CTV+CSFS 是实现对称性的最小功能集但要靠 OP_RETURN 补数据可用性，APO 用 taproot annex 更省，LNHANCE 类组合最顺但积木更多。第二类是委托与时间化授权：像 <pubkey> SWAP IF 2 PICK SWAP CSFS VERIFY ENDIF CHECKSIG 这样的脚本，同一输出既能直接验签也能接受”委托密钥”的签名；再与时间锁或 OP_CAT/PAIRCOMMIT 拼接，能表达”到期后交给另一个密钥代付”。两类拼起来看，CSFS 的定位不是新功能，而是把”签的是什么”从协议固定项变成脚本可自由定义的数据这一层地基。
一条自查线
普通读者怎么消化这类脚本提案？给一条三步自查线。第一步看层：BIP-348 属于共识软分叉层，改变的是”什么脚本算合法支出”，因此升级顺序必须旧规则兼容新规则，部署走版本位投票那一套；第二步看面：受影响的是编写复杂脚本的协议方（通道实现、合约服务），对普通钱包的收款、发送零影响；第三步看钱：它不产生新资产也不解锁新资金形态，任何”CSFS 已激活、支持 CSFS 的理财”之类说辞在 Draft 阶段出现，基本都是营销话术。三步走完，你对任何脚本升级提案都有了免疫框架——先分层、再画面、最后核对与钱包的接触面，谣言与误读大多在第一、二步就散架。
快速问答
问：它会不会改变普通比特币地址？ 答：不会。CSFS 只作用于 Tapscript 分支内部，日常单签与收款地址的生成、格式都不受影响。
问：Draft 阶段写了这个操作码会怎样？ 答：在主网会被当普通成功码处理（旧节点透明、新节点未激活前也按 OP_SUCCESS 语义），激活后同一脚本含义反转，这类迁移风险正是先冻 OP_SUCCESS 编号的用意。
问：和 CTV（BIP-119）是竞品吗？ 答：是拼图关系。CTV 锁”下一跳长什么样”，CSFS 验”谁认可了栈上的承诺”，两者合用才构成对称通道；单独立项是为了让每块积木可独立审查。
风险提示：本文讨论尚未激活的脚本提案，不构成投资建议，也不构成对任何钱包支持时间或协议激活时间的预测。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。