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

BIP-10 多签交易分发

为多签（以及离线签名的普通）交易制定统一的分发提案编码 TxDP：一方拟好交易，各方轮流或并行补签名，集齐后合并广播。本 BIP 目前处于已关闭状态。

一、档案卡

二、放在哪一族

多签协作的“文件传递”这一族，与 BIP-11 分工不同：BIP-11 管的是哪种多签交易算标准交易、能被网络转发和打包；BIP-10 管的是链下协作——一笔需要多人签名的交易，怎么在参与方之间传递、补签、合并。

它也覆盖一个附带场景：普通 1-of-1 交易由离线电脑签名。签名设备不需要持有区块链，正是这份编码的设计目标之一。

三、它要解决什么

多签交易天生是多步协作：一笔被多个地址共同“锁定”的资金，花费时需要相关各方（或脚本要求的子集）逐一看到拟议交易并用各自私钥签名。必须有人提议如何分配这笔资金、收集齐签名、再广播完成的交易。

原文担心的是：多签一旦启用，功能与复杂度同时大增；若每个客户端各用一套传递与收集签名的流程，用户会被客户端选择割裂。提供一套高效、统一的编码，就是为了让实现它的程序彼此互操作，提高开发者采用兼容协议的机会。

另一个动机在离线签名：这套编码把验证与签名所需的全部信息都打包在内，签名方不需要访问区块链，因此可以做非常轻量的专用签名设备——只需极少的比特币工具加一个 ECDSA 模块。这一点让 BIP-10 的用处超出多签本身。

四、规则本身

4.1 流程：分发提案（TxDP）

原文为这套流程定了一组推荐术语，各实现应统一使用：

1. 一方发起流程，创建 “Distribution Proposal”（分发提案，简称 DP 或 TxDP）。
2. 创建者（preparer）按自己希望的花费方式构造交易，但把 TxIn 的脚本留空——那里将来放签名脚本。
3. 提案同时附上所花费的未花费输出所在的完整交易（序列化后一并纳入）。原因是：被签名的数据包含前序交易哈希、却不包含金额；附上完整交易后，签名方可以核对该交易与 OutPoint 哈希相符、核对每个输入的金额，全程不需要区块链。
4. TxDP 有自己的 “DP ID”（也叫 Unsigned ID）：拟议交易在脚本留空状态下的哈希，用 Base58 表示。这个命名是特意定的，以免与广播后的真实交易 ID 混淆——真实 ID 要等所有签名集齐后才能确定，可称为 “Broadcast ID”。
5. TxDP 内含一份可无序排列的“签名—公钥”对列表，代表已收集到的签名。若你收到的 TxDP 只差你的签名，你签完即可广播。
6. 内容相同、签名不同的多份 TxDP 可以轻易合并：发起方可以一次性把请求发给所有人，收回后逐一合并，而不必把文件在各方之间接力传递。
7. TxDP 若存成文件或用邮件发送，文件后缀应为 .txdp 或 .btcdp。

4.2 文本格式

编码借用了 PGP/GPG 的 ASCII 文本块风格：紧凑、在任何字符编码下解释一致，可以直接粘进邮件正文或存为文本文件；又比 PGP 多了一些人类可读的元素，不必借助程序也能大致人工查看。其骨架为：

'-----BEGIN-TRANSACTION-TXDPID-------'
 ("_TXDIST_") (magicBytes) (base58Txid) (varIntTxSize)
    (serializedTxListInHex ...)
 ("_TXINPUT_") (00) (InputValue)
    ("_SIG_") (AddrBase58) (SigBytes) (SigHex ...)
 ("_TXINPUT_") (01) (InputValue)
    ...
'-------END-TRANSACTION-TXDPID-------'

即：头部给出魔数、DP ID 与交易体积，随后是序列化的交易列表（十六进制），再按输入逐个列出金额与已收集的签名。原文给了一个 Armory 在测试网上的完整示例：两个输入（150 BTC 与 12 BTC）合并成两个输出（160 BTC 与 1.9995 BTC），手续费 0.0005 BTC，两处输入都已签好、可直接广播。

收到 TxDP 的一方只需把自己的签名加到对应的 TXINPUT 行下；若那是最后一个所需签名，即可自行广播。实现本标准的软件应能把多份 TxDP 合并为一份；即便没有程序支持，用户也可以手工把 SIG 行复制到同一份序列化文本里合并，只是原文不推荐这样做。

五、谁必须动

普通持币人：不使用多签或离线签名时无任何变化。使用时按钱包的流程收发 TxDP 文件、核对输入金额后再签。

发起方（preparer）：构造留空脚本的交易、附上完整的前序交易、算出 DP ID，并负责把各方返回的 TxDP 合并。

签名方：在不接触区块链的条件下，靠提案内附的交易核对 OutPoint 与金额，确认无误才签名；只差自己一签时可直接广播。

钱包开发者：实现 TxDP 的编码、解析与合并逻辑，并统一使用原文的术语（TxDP、DP ID、Broadcast ID 等），才能与其他实现互操作。

共识层与节点：无变化。本 BIP 是应用层的信息类文档，不改交易有效性规则，也不管交易是否算“标准”——那是 BIP-11 的事。

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

状态为 Closed，结局原文 Changelog 写得很明确：本提案曾在旧版 Armory 中实现并测试（用于离线钱包的 1-of-1 交易签名，类 PyTxDistProposal）；但 Armory 在 2014 年 7 月发布的 0.92 版起改用新格式、不再使用本提案，且没有其他已知项目实现支持，于是 2014-11-26 被撤回（Withdrawn）——按现行状态体系归为 Closed。

常见误读：

“BIP-10 被关闭，说明多签这条路走死了。”

不对。被放弃的只是这一套链下分发编码：唯一实现者 Armory 换了自家格式，又无其他项目跟进，统一编码便失去了存在基础。多签交易本身是另一回事——它由脚本与标准交易规则支撑，与本 BIP 的存废无关。

七、延伸

• 阅读版：https://bips.dev/10
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki
• 相关：BIP-11（M-of-N 标准交易）
• 仓库总目录：https://github.com/bitcoin/bips

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