2011 年的比特币多签还是一件事半功倍难的事：一笔要两三个人一起签名的交易，提案怎么发、签名怎么收、收齐后谁来广播，各家钱包各做各的。BIP-10《多签交易分发》就是冲着这个混乱来的，作者是 Armory 钱包的开发者 Alan Reiner，2011 年 10 月 28 日立项。它提出的核心物件叫 TxDP（Distribution Proposal，分发提案），本质是一串像 PGP 密文那样的 ASCII 文本块，把一笔还没签好的交易原封不动装进信头信尾之间，让你能像转发邮件一样把待签交易传来传去。
它的第一个设计决定很实在：TxDP 不只装提案交易本身，还把它要花的每一笔旧交易（prev-tx）完整序列化后一起塞进去。为什么？因为签名哈希里包含的是前一笔交易的哈希，而不是金额。签名设备如果只看提案，就无法确认「这个输入点到底值多少钱」——替你生成提案的那台联网机器完全可能撒谎。把前交易一并带上，签名方就能自己重算哈希、核对输出值，全程不需要访问区块链。这让只装了一套加密工具、不同步任何链数据的轻量签名设备成为可能，也是这份提案超越多签场景本身的价值所在。
第二个决定是给「没签全的交易」一个独立编号。提案里所有签名脚本位留空时，对这份数据求哈希再做 Base58 编码，得到 DP ID，提案文档特意强调它应该叫 Unsigned ID，以免和广播后真正的交易编号混淆——因为签名加回来之前，最终交易哈希根本无法确定。收齐全部签名之后才存在的编号，文档建议称为 Broadcast ID。一个交易两个名字，分别对应「谈判中」和「已成局」两个阶段，这个命名纪律本身就是一种防错设计。
格式层面它借用了 PGP 的手法：用 BEGIN 和 END 长横线包裹，里面是魔数、随机字节、Base58 交易哈希、变长整数，然后逐行十六进制的旧交易列表，再按输入序号列出已经收到的每份签名。签名条目带着 Base58 地址，方便人眼检查。收信人只做一件事：在自己的 TXINPUT 位置补上自己的签名；如果自己是最后一个签名，可以直接广播。两份内容相同、签名不同的 TxDP 可以机械合并——这一点让「同时向所有人要签名、收齐再拼」替代了「挨个传阅」，减少了链条式传递里任一环节卡死的风险。
这份提案的结局干净利落。Changelog 写明：2014 年 11 月 26 日，Armory 从 0.92 版起弃用该格式改用新方案，且没有其他已知实现者，于是状态改为 Closed 撤回。它的参考实现只存在于 Armory 0.91 及更早版本的一个类里。后来的历史选择了 PSBT——同样是「把待签交易连同上下文打包、支持多方接力」的思路，但用了键值对结构和通用扩展字段，最终成为 BIP-174 行业标准。TxDP 输掉了格式之战，但它验证过的三件事——金额要自证、编号要分层、合并要可交换——全部在 PSBT 里活了下来。
常见误区有三个。其一，把 TxDP 当成一种交易格式：它只是分发容器，装进去的仍是普通比特币交易，广播后链上看不出任何 TxDP 痕迹。其二，把 Unsigned ID 当交易哈希用：去区块浏览器查它是查不到的，它只对未签名的那份序列化有效。其三，以为多签协作协议是近年才有的：这份 2011 年的文档已经写清了提案、收集、合并、广播四步流程，与今天 PSBT 工作流骨架相同。
一条对照线：拿 TxDP 和 PSBT 各看一份样例就能发现，前者把签名和地址排成给人看的文本行，后者把同样的信息做成编号字段的键值表。一个偏邮件时代的人类可读，一个偏机器时代的严格解析，两种气质差别的背后，是社区对「谁先解析这份文件」这个问题的不同答案。
快速问答。问：TxDP 现在还能用吗？答：已知软件都已不实现，它处于撤回状态，只剩文献价值。问：它和 PSBT 最本质的区别？答：TxDP 需要携带完整前交易来证明输入金额，PSBT 用结构化的非见证字段达到同样目的并兼容见证与隔离见证。问：为什么它特别提「不需要区块链」？答：这是它的卖点：验签所需的一切都在信封里，离线机器可以完全没有链上状态。
风险提示：本文是协议史与机制科普，不构成投资建议；执行任何多签流程前，请确认每台签名设备都能独立核验输入金额与收款地址。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。