协议演进 / BIP/比特币改进提案 / BIP-134

BIP-134 灵活交易

用交易版本 4 与紧凑消息格式重做交易序列化：字段带名、可增可省，以求修复全部已知可塑性并让交易更易扩展。本 BIP 目前处于已关闭状态。

一、档案卡

二、放在哪一族

交易格式重做与可塑性修复族，而且是其中走硬分叉路线的一支。BIP-134 不满足于给旧格式打补丁，而是要换一套新的交易序列化。

同族对照：

BIP-141：Segregated Witness，同样要解决签名可塑性对 txid 的影响，但走软分叉路线，把见证数据移出 txid 计算。

BIP-140：Normalized TXID，同样以“算 ID 时剔除签名脚本”为核心，走软分叉加新操作码的路线。

BIP-68：相对锁定时间。原文把这类“复用既有字段”的历次软分叉改动列为技术债的例子，认为新格式应把它们收进更好维护、更好解析的体系。

BIP-134 在这一族里的位置是：设想最彻底、改动面最大，因而也最难部署的一个方案。

三、它要解决什么

3.1 老格式用了约八年，字段只能硬塞

原文动机部分说，比特币交易在当时已用了约八年基本相同的版本与布局，教训之一是缺少灵活性。

典型例子是 sequence 字段：先引入、后来又被弃用，但所有交易仍被迫保留这些字段、让区块链跟着变大，哪怕它们全都取默认值。

3.2 可塑性卡住上层协议

交易数据字段重新排序，是为了干净地修复可塑性问题。原文明确说，未来技术如闪电网络将依赖这类修复落地。

同时，重排之后把签名从交易里拿掉变得很容易，且不破坏其 tx-id，这对未来的修剪（pruning）功能有利；原文称测试显示空间占用可降到约 75%。

3.3 想要的能力清单

原文列出的目标包括：

• 修复可塑性；
• 签名检查的线性扩展（linear scaling）；
• 面向未来的高度可扩展性；
• 让交易更小；
• 支持闪电网络。

此外 v4 格式还打算原生支持输入金额证明、scriptBase（输入与输出合并脚本，供硬件钱包确知自己在花什么），以及双花证明——节点发现双花时只发证明，不必发整笔交易。

四、规则本身

4.1 版本 4 与紧凑消息格式（CMF）

方案利用一个事实：交易最前面 4 字节决定版本号，而多数客户端用一条非共识的策略规则，不接受未明确定义的版本号。BIP-134 选用新版本 4，并规定版本之后的数据使用 Compact Message Format（CMF）。

CMF 借鉴 XML “给字段起名”的思想，但不用文本格式：每个令牌（token）是名称、格式、值三元组。有了名称，就可以跳过未用令牌、可以简单地新增令牌，日后软分叉升级会更容易、更干净。原文同时强调标准化数据格式（如整数与字符串编码）以求一致；出现表中未定义的令牌，所在交易无效。

主要令牌包括：TxEnd（交易结束标记，必填）、TxInPrevHash（所花前交易 TxId）、TxPrevIndex、TxInputStackItem 及其续篇、TxOutValue（必填）、TxOutScript（必填）、TxRelativeBlockLock、TxRelativeTimeLock、CoinbaseMessage，以及留作忽略的 NOP_1x 一组备用值。

4.2 签名哈希与序列化顺序

版本 4 交易为单个输入算签名哈希时：哈希类型为 0 或 1 则哈希该交易的 tx-id，其他哈希类型沿用旧有选择性忽略规则，但一个例外贯穿始终——从不序列化任何签名。此外还要纳入所花交易的 TxId、输出索引、所签输入脚本、金额（var-int）与哈希类型（var-int）。

顺序要求很少：只有在可选值会导致歧义处才定序。例如每个新输入必须以 TxInPrevHash 开头，相对锁定令牌必须跟在所属的 TxInPrevHash 之后。

整笔交易分三段：Transaction 段（除签名与 TxEnd 外的全部令牌，用来算 TxId）、Signatures 段（TxInputStackItem 系列）、TxEnd 段。TxId 是对去掉 Signatures 与 TxEnd 的序列化做哈希。

4.3 区块默克尔树的补强

签名不进 TxId，也意味着签名不进默克尔树，改签名将不可检测，会打开攻击面。为此原文要求扩展默克尔树：在全部交易 tx-id 之后，追加 v4 交易的另一种哈希——对“tx-id 加全部签名令牌序列化”取哈希，让签名整体仍然被区块承诺。

4.4 未来扩展位

NOP_1x 实际是 10 个目前规定为 NOP 的值，支持 v4 的实现应忽略它们，如同字段不存在。19 号之后的令牌数量实际上不限，但目前规定不允许出现在交易中，出现即被拒；未来协议升级可再为它们赋义。原文的判断是：概念与格式都不必再变，只加新数据，升级会顺得多。

五、谁必须动

普通持币人：间接影响。若此方案部署，老钱包能不能收发新格式交易取决于软件升级，持币人要跟随钱包更新。

钱包开发者：必须动。SPV 钱包按原文需更新才能接收或创建新交易类型；签名哈希的计算方式、金额与脚本的纳入方式都变了。

全节点与矿工：必须动，而且是硬性要求。完全验证的旧客户端无法理解或验证版本 4 交易，需要更新才能恢复这一能力。

共识层：本 BIP 本身就是共识层硬分叉提案——新交易格式的有效性规则要全网换轨，不是策略层调整可以完成的。

六、现在算不算数，以及一个常见误读

状态为 Closed（已关闭）。原文的部署一节只写了“待定”（To be determined），向后兼容一节也写明旧的完全验证客户端读不懂 v4 交易。它自述“引入新格式而不改动、不废弃既有格式与做法”，所以对既有数据与解析代码兼容；但这不等于它曾在主网上生效——这份提案已经关闭，不再推进，读它应按一份完整的替代格式设计稿来读。

它留下的可比照价值在于问题清单本身：可塑性、字段僵化、技术债、签名与 txid 的纠缠，后来的方案都要回答，只是选了不同的部署路线。

原文的参考实现一节还有一句很能说明作者立场的话：Bitcoin Classic 包含一个遵循本规范的实现，但作者拒绝“参考实现”这一概念。

在其表述中，规范永远是权威，实现不是。

这与它已关闭的状态并不矛盾：作为设计稿，它的格式定义、令牌表与序列化规则都完整留档，后人评估硬分叉换格式这条路线时，仍要回到这份文本本身，而不是某个客户端的行为。

常见误读：

“BIP-134 是 SegWit 的另一个名字。”

不对。两者都想解决签名可塑性，但 BIP-134 是另起 v4 交易格式与 CMF 序列化的硬分叉方案，BIP-141 是把见证移出交易默克尔树的软分叉方案，格式、操作码与兼容方式都不同，不能混为一谈。

七、延伸

• 阅读版：https://bips.dev/134
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki
• 相关：BIP-140 规范化 TXID、BIP-141 隔离见证（共识层）、BIP-68 相对锁定时间
• 仓库总目录：https://github.com/bitcoin/bips

本页内容整理自 bitcoin/bips 仓库与 bips.dev，事实已与仓库核对；解读仅供学习参考。