BIP 10：早期多签签名数据如何协作分发

本文只讨论 Bitcoin 技术机制、工程实现和生态基础设施，不讨论炒币、交易策略或投资建议。

BIP 10 的标题是 Multi-Sig Transaction Distribution，作者是 Alan Reiner，Layer 是 Applications，类型是 Informational，状态是 Closed，编号分配日期是 2011-10-28。它讨论的是早期多签场景下，如何标准化待签名数据、签名收集和最终广播之间的协作格式。

今天读 BIP 10，不应把它当成当前推荐格式。它的价值更接近历史工程样本：在 PSBT 等后续机制出现之前，开发者曾经怎样尝试解决“多个参与方如何围绕同一笔链上操作协同签名”的问题。

发生了什么

多签让一个输出的花费条件不再只依赖单个密钥，而是需要多个参与方中的若干签名共同满足脚本条件。这带来更强的权限表达能力，也带来更复杂的协作流程：有人要构造待签名数据，有人要核验输入和输出，有人要补充签名，最后还要把完整结果广播出去。

BIP 10 试图给这个流程定义一种统一编码，称为 Transaction Distribution Proposal，简称 TxDP。它希望不同软件可以围绕同一种文本格式交换待签名数据和已收集签名，从而减少钱包之间各自实现、互不兼容的问题。

官方索引中，BIP 10 当前是 Closed。原文也提到，早期 Armory 曾实现和测试过这种格式，但后续版本已经迁移到新的格式。因此，BIP 10 更适合作为历史协议设计案例，而不是新项目的实现依据。

技术机制是什么

BIP 10 的核心对象是 TxDP。一个参与方先构造待签名的链上操作数据，但把输入脚本留空；同时附带被花费输出所在的完整原始数据，使签名方可以在不持有完整链数据的情况下核验输入值和引用关系。

TxDP 会有一个 Unsigned ID，也就是对空脚本版本的待签名数据求哈希并用 Base58 表示。这个 ID 用于标识签名前的 proposal，避免和最终广播后的 ID 混淆。BIP 10 建议把最终广播后的标识称为 Broadcast ID。

TxDP 还包含按输入组织的签名列表。不同参与方可以拿到同一个 TxDP，分别补充自己的签名；多个包含不同签名的 TxDP 可以合并成一个完整对象。如果某个参与方拿到的 TxDP 只缺自己那份签名，那么签完之后理论上就可以进入广播环节。

编码形式上，BIP 10 借鉴了 PGP/GPG 的 ASCII block 风格。它使用清晰的起止行、_TXDIST_、_TXINPUT_、_SIG_ 等标记，把序列化数据和签名片段组织成可复制、可保存、可通过文本渠道传递的格式。

这种设计也解释了它的时代背景。早期离线签名设备、轻量签名工具和多钱包协作还缺少成熟统一标准，文本块格式可以降低传递门槛，让参与方通过邮件或文件交换数据。

对开发者和节点运营者意味着什么

对开发者来说，BIP 10 最值得借鉴的不是具体文本格式，而是它提出的问题模型：多方签名需要明确区分待签名对象、已收集签名、输入核验材料和最终广播对象。后续更成熟的标准，也是在类似问题上做了更严谨的结构化表达。

对钱包开发者来说，BIP 10 说明离线签名不能只传一个待签名摘要。签名设备需要足够信息核验自己签的是什么，包括引用的输出、输入值、脚本条件和最终输出结构。否则签名方很难做出可靠判断。

对节点运营者来说，BIP 10 不会改变节点验证规则。它属于应用层协作格式，目标是帮助钱包或签名工具整理数据。节点最终看到的仍然是满足共识和策略规则的完整链上数据。

对技术内容写作者来说，BIP 10 应强调“Closed”和“历史格式”。如果不说明状态，读者可能误以为这是当前推荐方案。更准确的写法，是把它放在多签协作格式演进史里理解。

风险、限制和误区

第一个误区，是把 BIP 10 当成现代钱包必须支持的标准。官方状态是 Closed，原始实现也已迁移到其他格式。新项目不应仅凭 BIP 10 做兼容性设计。

第二个误区，是低估签名前核验数据的重要性。多签协作不是简单收集签名，签名方必须能核验输入来源和输出结构。BIP 10 把相关原始数据放进 proposal，正是为了解决离线签名的核验问题。

第三个误区，是混淆 Unsigned ID 和最终广播后的 ID。签名前对象和完成后的对象不同，标识也不能混用。BIP 10 专门设计命名，就是为了避免协作过程中误认对象。

第四个误区，是把文本可复制等同于长期可靠。ASCII block 在早期便于邮件和文件传递，但随着钱包复杂度上升，结构化、可扩展、可严格解析的格式更适合长期互操作。

接下来该看什么

读 BIP 10，建议把它拆成三个问题。

第一，待签名数据如何被唯一识别。Unsigned ID 解决的是协作过程中“大家是否在处理同一个对象”的问题。

第二，签名方如何独立核验。TxDP 附带原始输入相关数据，是为了让离线或轻量设备也能检查签名上下文。

第三，多个签名如何合并。BIP 10 允许不同 TxDP 对象合并签名，体现了多签协作中“并行收集，再合并完成”的工作流。

后续如果继续写多签和钱包标准，应把 BIP 10 作为早期背景，再进入更现代的部分签名数据格式、硬件签名流程和钱包互操作规范。这样既能保留历史脉络，也不会误导读者采用已经关闭的旧方案。

本文结论只限技术讨论，不构成任何买卖、持仓或收益判断。