多签群里最常见的协作事故，发生在”名字太像”的两条命令之间：joinpsbts 与 combinepsbt。两者都收一串 base64 的 PSBT，都吐出一份新 PSBT，中文教程里经常被笼统称为”合并”。但按 BIP174 的角色划分，它们干的是完全不同的活——把这两者用混，轻则报一堆看不懂的错，重则让协作各方的签名永远凑不齐。
先看官方文档的一句话定义。combinepsbt 的描述是 Combine multiple partially signed Bitcoin transactions into one transaction，并特意补了一句：Implements the Combiner role——实现的是 BIP174 规范里的”合并者”角色。注意定语：partially signed，部分签名。它合并的是同一笔交易的多个半成品：每份输入的 PSBT 描述的都是同一个交易骨架（同样的输入、同样的输出），只是各自往里面填了不同的料——A 方填了自己的签名，B 方填了自己的公钥和见证字段，C 方补了某个字段的脚本信息。Combiner 的职责就是把这些互补的字段按输入逐条拼进一份新 PSBT。
这和 joinpsbts 的场景恰好正交。joinpsbts 面向的是多方各造各的交易骨架再拼成更大的交易（输入输出求并集），是”拼单”；combinepsbt 面向的是所有人围着同一笔交易传阅，各自签名，是”会签后的收文件”。用错方向的典型症状：3-of-3 多签，三方各自 walletprocesspsbt 签完后，有人把三份都丢进 joinpsbts——按它的规则，输入重叠直接报错终止，因为 joinpsbts 的合法前提是不重叠；换成 combinepsbt，它认得”这是同一笔交易的三份签名”，把三组签名字段并到一起，交给 finalizepsbt 组装出可广播的完整交易。
从工程视角看 combinepsbt 有三个值得记住的性质。第一，它不重排、不决策，只做字段搬运：合并后交易的 txid 与各方手里那份必须一致，PSBT 从设计上就锁死了交易骨架，谁也不能在传阅途中改输入输出而不留痕。第二，它对字段冲突的处理很朴素：同类字段（比如同一个输入的同一个签名字段）内容不同时会拒绝或丢弃其一，BIP174 对各字段的合并语义有逐条规定，实现只需照章执行——排障时值得回到规范文本，而不是猜实现行为。第三，它完全离线且无信任假设：合并动作不需要谁可信，签名字段本身自带验证材料，凑没凑够由 analyzepsbt 一查便知。
由此可以得到一条简单的工作流判断口诀：数一数每份 PSBT 的输入清单。完全相同，说明大家在会签同一笔交易，收文件用 combinepsbt；各不相同，说明大家在拼各自的资金进场，合骨架用 joinpsbts；既非全同又非全不同，先停下来检查流程——那说明某一环把交易改了，签名很可能已经作废，老老实实重新 walletcreatefundedpsbt 走一遍，比抢救半残 PSBT 便宜得多。
两个实用细节收尾。combinepsbt 的参数就一个：PSBT 字符串的 JSON 数组，至少两份才有意义；输出是一份 base64，直接可以喂给 finalizepsbt 或 analyzepsbt。另一条：硬件签名链路里它常被放在流程末端——冷设备各自签完，回传热节点合并，全程没有一台机器需要看到全部私钥；也正因如此，合并后的交易一定要在广播前用 finalizepsbt 确认 complete 为 true，缺签名的半成品广播只会收获一串拒绝。再补一条协作卫生：多方传阅 PSBT 时给每轮传阅留哈希记录（decodepsbt 输出即可），任何一份在传阅中被改过骨架，combinepsbt 或最终 finalizepsbt 的报错都会第一时间暴露它，届时对照记录能立刻定位是哪一环出的问题，避免多签群里互相猜忌的僵局。
风险提示：PSBT 字段的合并语义以 BIP174 与所用实现为准，多签流程中签名错误可能导致交易无法完成，广播前请逐项核对输入输出与签名状态。本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。