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

BIP-131 “Coalescing Transaction”规范（通配输入）

提出通配输入的合并交易：一笔交易只写一个输入和一次签名，就花掉链上所有同 scriptPubKey 的未花费输出。本 BIP 目前处于已关闭状态。

一、档案卡

二、放在哪一族

共识层硬分叉提案族，而且是其中改动验证模型的一类：它不新增操作码或脚本功能，而是要改“一个输入到底指什么”——从指向某一个具体的在先输出，改成指向一整类输出。

它补充（supplement）而非取代普通“非合并（non-coalescing）”交易：两种交易按设计并存，靠交易版本字段里的类型位区分。因此它与 BIP-11 那种只改节点策略、不动共识的标准交易文档完全不同：本 BIP 一旦实施，全节点验证普通交易的代码也必须跟着改（见 4.3），这正是它被标为 Consensus (hard fork) 的原因。

它针对的问题——小额 UTXO 太贵花不动、UTXO 集合膨胀——是长期议题；但解决路线是本 BIP 独有的，并未成为后来实际采用的方案，读时须以它 Closed 的状态为准。

三、它要解决什么

原文指出的低效是这样的：当你想花费多个 scriptPubKey 完全相同的输入时，普通交易必须把每个输入逐一列出，并把表达同一信息的签名重复多遍。这让交易体积膨胀，花小额输入变得很贵。

后果有两层：

• 小额输入因为不划算而花不出去，长期留在 UTXO 池里，而 UTXO 池是全节点必须保存维护的；
• 原文推演：如果最大区块体积的增速慢于用户实际发送的交易量，这问题会更严重——换言之，手续费上升时，一个 UTXO 值得被花费的最低经济金额也随之上升，更多小额输出会被卡住。

原文认为 UTXO 集合的长期增长会对网络产生负面的扩展性后果。合并交易就是为压低“同类小额输出”的花费成本而设计的。

四、规则本身

4.1 重新定义交易版本字段

本 BIP 首先重定义交易的 version 字段：前四个字节定义为版本号，后四个字节定义为交易类型。类型 “0000” 表示普通交易，类型 “0001” 表示合并交易。原文给的例子是：

version 1 的普通输入交易：        version: 10000000
version 2 的普通输入交易：        version: 20000000
version 2 的合并输入交易：        version: 20000001

实质是把 version 字段的最后一个比特置 1，为这笔交易的全部输入启用通配（wildcard）语义。

4.2 通配输入：一笔顶一类

合并交易的构造方式与 version 1 交易完全相同，唯一例外是：每个输入都被当作“通配输入”处理。

一个通配输入的金额，定义为：所有 scriptPubKey 与它完全相同、且所在区块高度小于或等于该通配输入被确认进的区块的那些输入（UTXO）的总价值。

换句话说，签名者只需写一个输入、签一次名，就等于宣告花费截至该区块为止、链上全部同 scriptPubKey 的未花费输出——不必逐个列出，更不必逐个签名。

4.3 实现需要改的三处

原文说，比特币代码要在三处修改才能处理合并交易：

1. 全节点的合并交易验证：节点收到合并交易时，必须汇总区块链中比该输入更早、scriptPubKey 相同的全部 UTXO 的金额；若汇总值大于或等于该交易全部输出之和，这笔合并交易才有效、可以传播。
2. 全节点的非合并交易验证：普通交易到来时，代码要多查一步——每个输入是否已被某笔合并交易花掉。若区块链中存在一笔同 scriptPubKey 的合并交易、位于该输入所在区块之后，这个 UTXO 就已被花费，该普通交易无效。
3. 钱包：参考客户端面向用户的钱包部分，应在用户钱包里有许多符合条件的 UTXO 时提示用户，让其知道可以受益于合并交易；但钱包不应在所有场合都把普通交易简单换成合并交易。

4.4 关于地址复用，原文的自辩

原文专设一节回应“这会不会鼓励地址复用”。它把复用分成两种：

发送方复用（把找零发回同一地址）会让旁观者摸清你的交易关系、损害隐私，本 BIP 对它没有任何影响。接收方复用（公布一个地址、让多人往里打款）过去被视为坏习惯，原因是反复使用同一私钥签名，攻击者可能通过对多份签名做统计分析反推出私钥。本 BIP 恰好让花费多个输入时不必再复用私钥签名——原文因此主张，它反而修好了接收方复用的问题，实施部署之后，接收方复用地址将不再算坏习惯。

这一论证是作者的立场陈述，本页如实转述，不代表社区结论——这份提案最终是 Closed。

五、谁必须动

普通持币人：若此案曾实施，手握大量同地址小额 UTXO 的人才直接相关：钱包会提示可用合并交易一次清走。现状下无任何动作可做，也不需要做。

钱包开发者：按原文设想，钱包要能识别可受益的 UTXO 集合、提示用户，并克制使用——不是见输入多就自动合并。

全节点与矿工：改动最重。要新增合并交易的汇总验证，还要在验证每一笔普通交易时额外检查它是否已被在后的合并交易花掉。验证一笔交易的成本从“查几个 UTXO”变成“按 scriptPubKey 扫一类 UTXO”，这正是硬分叉级共识改动的分量所在。

共识层：本 BIP 本身就是共识改动（层级标注为 Consensus (hard fork)）。旧节点不升级就无法正确验证合并交易，更无法判断普通交易的输入是否已被合并交易花费。

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

状态为 Closed（已关闭）。按仓库状态解释：这份硬分叉提案的进程已经结束，没有被激活，比特币现行共识规则里不存在通配输入，也不存在合并交易这一交易类型。今天任何节点收到把 version 末位置 1 的交易，都不会按本 BIP 的语义去汇总同 scriptPubKey 的 UTXO。它只是一份保留在仓库里的历史设计，供理解 UTXO 模型与验证成本的讨论时参考。

常见误读：“BIP-131 就是把多个输入合并成一笔普通批量交易，和钱包的自动归集是一回事。”

不对。钱包归集仍是普通交易：每个输入逐个列出、逐个签名，节点逐个验证。本 BIP 的通配输入改变了输入的语义本身——一个输入代表一整类 UTXO，且普通交易的验证规则都要连带修改。那不是钱包技巧，而是需要硬分叉的共识重构；把它当作已有的归集功能，会完全误判它的改动量级。

七、延伸

• 阅读版：https://bips.dev/131
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0131.mediawiki
• 相关：BIP-11 M-of-N 标准交易（同为早期交易构造文档，但只动策略、不动共识）
• 仓库总目录：https://github.com/bitcoin/bips

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