协议演进 / BIP/比特币改进提案 / BIP-448
BIP-448
一份打包部署提案：同时为 Tapscript 部署 OP_TEMPLATEHASH、OP_CHECKSIGFROMSTACK 与 OP_INTERNALKEY 三个操作，以最小的组合支撑可重绑定签名与 LN-Symmetry 等二层协议。本 BIP 目前处于草案状态。
一、档案卡
| 编号 | BIP-448 |
|---|---|
| 标题 | Taproot-native (Re)bindable Transactions |
| 作者 | Gregory Sanders <[email protected]>, Antoine Poinsot <[email protected]>, Steven Roose <[email protected]> |
| 指定日期 | 2026-03-11 |
| 层级 | Consensus (soft fork)（共识（软分叉）） |
| 类型 | Specification（规范类） |
| 状态 | Draft（草案） |
| 阅读版 | https://bips.dev/448 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0448.md |
二、放在哪一族
部署打包（bundle）一族：它自己不发明新操作码，而是把三份各自独立的操作码提案绑成一个软分叉包，论证“这三个一起上，能解锁什么、风险为什么可控”。
包内三件：
BIP-446：OP_TEMPLATEHASH，承诺花费交易模板
BIP-348：OP_CHECKSIGFROMSTACK，对任意消息验 Schnorr 签名
BIP-349：OP_INTERNALKEY，把 Taproot 内部公钥压入栈
原文致谢一节说明，这一组合与 Brandon Black 此前以 LNHance 之名提出的组合相似。本 BIP 与三份单项 BIP 的分工是：单项 BIP 写清各自的精确语义，本 BIP 负责组合的动机、取舍与部署。
三、它要解决什么
三个操作单独看都很小：一个承诺交易模板，一个对栈上消息验签，一个取内部公钥。原文的主张是，正是这三个模块化能力的组合，能改善一批已研究充分的二层协议，并使一些新协议在合理的交互要求下成为可能：
- OP_TEMPLATEHASH 让 Tapscript 承诺“必须由这笔确切的交易来花”。今天这件事靠所有参与方签名模拟；换成脚本承诺后，交互更少，协议更简单、更安全，有时还显著更高效；
- OP_CHECKSIGFROMSTACK 引入对任意消息的 BIP-340 Schnorr 验签，支撑委托（delegation）与预言机证明（oracle attestations）；
- 两者结合，得到可重绑定签名（rebindable transaction signatures）：签名可按规则重新绑定到新的交易模板上，由此使一种新型支付通道 LN-Symmetry（即 eltoo 思路）成为可能。原文称其简单性让多方通道变得实际可行，让 Daric 这类两方通道得以简化，并能显著改善 statechains；
- 可重绑定签名还能进一步减少二层协议的交互，例如 Ark 的变体 Erk，以及把今天的闪电网络升级到 PTLC（Point Time Locked Contracts）时带来的大幅简化；
- OP_INTERNALKEY 把内部公钥压上栈，原文称之为对可重绑定签名“自然且极其简单”的优化。
换言之，要解决的不是某个单点功能，而是“二层协议为了模拟‘承诺下一笔交易’与‘可重绑定签名’，长期付出高交互成本”这一类问题。
四、规则本身
4.1 三个操作，各占一个 OP_SUCCESS 位
在 BIP-342 Tapscript 中，三个操作分别重新定义一个 OP_SUCCESS 操作码，精确语义各自以单项 BIP 为准：
- OP_TEMPLATEHASH 重新定义 OP_SUCCESS206（0xce），按 BIP-446；
- OP_CHECKSIGFROMSTACK 重新定义 OP_SUCCESS204（0xcc），按 BIP-348；
- OP_INTERNALKEY 重新定义 OP_SUCCESS203（0xcb），按 BIP-349。
本 BIP 本身不改写这三份规范的任何一条语义；读规则细节，应回到三份单项 BIP。
4.2 为什么是“最小组合”
原文的取舍逻辑是克制：三个操作都被形容为简单、易懂、可组合，建立在既有操作之上，给验证与实现增加的复杂度成本最小，且不太可能被未来扩展淘汰；它们又只落在较现代、研究较充分的 Tapscript 环境里，意外行为与非预期用途的风险较低。
两个被明确比较并放下的替代路线：
- 更模块化的方案如 BIP-346（OP_TXHASH）：也能实现这些能力甚至更多，但实现复杂度等风险面更大；而其额外能力尚未被证明能启用重要的新用例、或大幅改善既有用例，故本 BIP 选择最小路线；
- 用 BIP-119 的 OP_CHECKTEMPLATEVERIFY 替代 BIP-446：本 BIP 倾向后者的最小做法——不改 legacy 脚本环境、复用既有 Taproot 签名哈希，具体理由见 BIP-446 的 Rationale。
4.3 部署
原文把具体的激活方式留待日后确定（left to be determined at a later date）：没有给出激活时间、信号期或版本位安排。向后兼容性上，给三个 OP_SUCCESS 操作码赋予含义只是收紧区块验证规则，不存在“新规则下有效、旧规则下无效”的区块，故与未升级节点软件向后兼容；但作者强烈建议节点运营者升级，以完整验证全部共识规则。
五、谁必须动
普通持币人：现在不必做任何事。本 BIP 仍是草案，激活方式未定；它也不改变普通 Taproot 收付款的形式。
钱包开发者：现在不必动。将来若激活，首先受益并需要适配的是闪电、Ark、statechains 等二层协议的软件，普通钱包的收付款路径无变化。
二层协议开发者：这是主要受众。评估 LN-Symmetry、多方通道、PTLC 升级等设计时，应以本 BIP 的组合为单位做可行性判断，同时逐条核对 BIP-446、BIP-348、BIP-349 三份单项规范——组合提案不替代单项规范。
全节点与矿工：若将来激活，需同时实现三个操作的新语义才能完整验证。只实现其中一两个，不算实现了 BIP-448。
共识层：改动只落在 Tapscript 的三个 OP_SUCCESS 操作码上，不动 legacy 脚本；三者是作为一个包提出的，取舍论证也是针对整包做的。
六、现在算不算数，以及一个常见误读
状态为 Draft（草案），且部署一节明确写着激活方式待定。今天的主网上这三个位置仍是 OP_SUCCESS：执行到即成功。把 BIP-446、BIP-348、BIP-349 各自的草案状态，与本 BIP 的草案状态分开看——四份都是草案，任何一份的进展都不自动等于整包已部署。
常见误读：
“BIP-448 又提出了一个叫‘可重绑定交易’的新操作码。”
不对。它没有定义任何新操作码的语义：三个操作的规范分别在 BIP-446、BIP-348、BIP-349 里。“可重绑定”是这三个操作组合后涌现的能力，也是这份部署提案的标题主题，而不是一个操作码的名字。只读本 BIP 就动手实现，必然落空——实现依据始终是三份单项 BIP。
七、延伸
- 阅读版：https://bips.dev/448
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0448.md
- 相关：BIP-446 OP_TEMPLATEHASH、BIP-348 OP_CHECKSIGFROMSTACK、BIP-349 OP_INTERNALKEY、BIP-342 Tapscript
- 仓库总目录：https://github.com/bitcoin/bips