PSBT 版本 2：不再锁死交易骨架，输入输出可以边走边加

一、版本 1 的结构性天花板

BIP174 定义的 PSBT 把一笔未签名交易原封不动塞进 PSBT_GLOBAL_UNSIGNED_TX，各方往里补公钥、补脚本、补签名，但交易的输入输出清单自创建那一刻就冻结了。这对”两人凑钱付一笔”的场景是硬伤：协调者先造好交易发给大家签，参与者想添一把自己的 UTXO 进来分担手续费，格式上无路可走，只能推倒重来。根因不在工具偷懒，而在结构：只要存在一笔”全局裸交易”，任何增删输入输出都会改变交易哈希，牵动所有已产出签名的有效性。

二、版本 2 把骨架拆成字段

BIP370（状态已部署）的做法是干脆宣布：版本 2 的 PSBT 禁止携带全局裸交易，改为全局必备 PSBT_GLOBAL_VERSION 等于 2，另设一组新全局字段——交易版本、备用锁定时间、输入计数、输出计数，以及关键的修改标志位 PSBT_GLOBAL_TX_MODIFIABLE：第 0 位管输入能否增删，第 1 位管输出能否增删，第 2 位提示存在 SIGHASH_SINGLE 签名、增删必须保持输入输出对位。每个输入也第一次拥有了自己的字段：前手交易哈希、被花输出序号、序列号，以及两个时间锁需求字段（按高度或按时间）。锁定时钟从”一个全局数”变成”每个输入一票”：最终 nLockTime 取所有输入要求的最大值，两种锁并存时按高度锁优先。

三、角色表上多了一个构造者

版本 2 的角色分工相应重排：创建者（Creator）初始化一份零输入零输出的空壳并声明可修改性；新增的构造者（Constructor）负责在门槛内添加或删除输入输出，动手前必须先检查对应的可修改标志位；之后的更新者、组合者、签名者、终结者流水线与版本 1 基本同构。签名者因此多了一条必须核对的语义：可添加标志意味着”你签完之后别人还可能添你的本金和找零”，凡是要限制费用分摊范围的签名方，都应要求构造在签名前收口。

四、身份问题：没有裸交易怎么认这份文件

PSBTv2 没有现成的交易哈希可用，规范给出的唯一身份是：用当前信息构造一笔无签名交易计算 txid，但序列号一律按 0 处理再计算——因为序列号允许被更新者与组合者改动。给 PSBT 建立指纹的中间件必须按这个口径来，否则同一份文件在两家工具里会”长了两张脸”。

五、工具链互操作的分寸

两代格式并存后，翻译者（Translator）角色负责版本间转换，但转换不是无损表演：把版本 2 折回版本 1 必然重新冻结交易结构。工程上的稳妥做法是协商期内始终用版本 2 流转，各方结构与费用分摊定稿后，再按最终格式终结并广播。和所有格式演进一样，版本 2 解决的是”结构冻结”这一类具体疼痛，它没有让盲签变得更安全——签名前逐项核对金额、地址与授权边界，从 BIP174 时代起就一直是每个签名者自己的责任。

六、版本 2 的字段纪律

给实现者的四条硬约束：可添加标志一旦在协商期被各方读过，中途禁止再改回只读——语义变化不会被旧字段拒绝，只会让后续构造者的行为与签名方的预期静默分叉。序列号字段从”全局交易里的固定值”变成逐输入字段，意味着 RBF 信号也首次进入”构造期可协商”的范畴，谁想让某输入可替换必须显式写入该输入的序列号并在签名前收口。锁定时间的”取最大”规则还藏着一个陷阱：只要有一个输入声明了高度锁，时间锁就被整体放弃——一个恶意或糊涂的更新者只需塞一个极低的高度要求，就能把所有人期望的时间锁作废，签名前重算一遍最终 nLockTime 因此不是可选项而是义务。最后，PSBTv2 的 base64 编码仍携带 psbt 幻数，混进旧工具不会静默出错，而是干脆报错——这类”响亮失败”值得写进你团队的兼容性测试清单。