多签协作、离线签名、给硬件设备递单子——这些场景都需要一份”钱已经选好、只差签字”的 PSBT。多数教程讲 walletcreatefundedpsbt 只讲到前两个参数：输入清单和输出清单，实际上决定这笔交易能不能算准手续费的，是后面那几个不起眼的选项，尤其是 solving_data。这篇按参数顺序把这条命令拆开。
第一个参数是输入数组，每项写 txid 和 vout，就是你打算花掉的那几枚 UTXO；传空数组时钱包自己选。第二个参数是输出数组，每项要么是”地址:金额”的映射，要么带 data 键做载数据输出。到这里为止的行为很直白，和 fundrawtransaction 的差别只是这一步是从零造交易而不是包装已有交易。
第三个参数 locktime，语义与裸交易的锁定时点一致，不展开。第四个 options 是重头，逐项说。add_inputs：默认 false，当你在第一个参数里点名的输入不够付第二个参数的输出金额时，命令直接报错；设为 true 后钱包会从自己的库存里补输入，把”指名道姓”和”自动选币”混用。注意补进来的币你事先不知道是哪几枚，隐私敏感的场景慎用。include_unsafe：默认 false，会避开被别的节点标记为 unsafe 的输入（比如和共识冲突交易沾边的）；离线签名链路里如果两边对”unsafe”的理解不一致，会出现这台能选那台不能选的错位。feeRate：单位 BTC/kvB 的手动费率，覆盖钱包的自动估算——给了它，confTarget 就被无视。subtractFeeFromOutputs：一个下标数组，声明手续费从哪几个输出里倒扣，常见于”把余额全给收款方”的归集场景；金额单位换算、舍入方向，都以这笔交易实际落链的字节数为准。
接下来是最容易被略过的 solving_data。它的 pubkeys、scripts、descriptors 三个数组回答的是同一个问题：这些输入的解锁脚本长什么样？钱包选币时按”输入大概多大”估算手续费，如果输入来自多签、时间锁合约这类非标准脚本，钱包默认只按裸公钥形状的脚本尺寸猜，实际字节可能大好几倍——估出来的费率就系统性偏低。把完整的公钥清单、赎回脚本或描述符塞进 solving_data，费用估算用的就是真实解锁尺寸。一个不显眼的好处：你从返回结果里拿到的 fee 字段更贴近真实值，加钱重发的返工概率显著下降。多签协调群里最常见的”第一次估算 2000 聪、签完变 9000 聪”事故，多半就是 solving_data 缺位。
replaceable 对应 BIP125 信号，默认跟随钱包设置；显式设为 true 给未来的 bumpfee 留后路，设为 false 则这笔交易进不了 RBF 替换通道。公开收款方在意的正是这个标志，别随手关。
返回结构三件套：psbt 是 base64 的半成品，fee 是钱包替你垫付的总手续费（注意是你的库存出，不在输出金额里），changepos 是找零输出的下标，-1 表示没加找零。拿到 PSBT 后的流程就是标准化的了：decodepsbt 肉眼过一遍输入输出，walletprocesspsbt 各自签名，凑够权重后 finalizepsbt 合并上链。
最后一个提醒：walletcreatefundedpsbt 的选币发生在调用它的那台钱包节点上，硬件签名方只看到一份 PSBT，看不到”钱包为什么选这几枚币”。想审查选币质量（隐私聚类、粉尘碎片），得回到发起端用 listunspent 复核，别指望在 PSBT 里找答案。
补一条官方口径：文档给 solving_data 的定位是”产出带占位签名的最终交易所需的密钥与脚本，用于选币期间的费用估算”，并列出 pubkeys、scripts、descriptors 三个数组。注意它服务的是估算环节而不是签名环节——真正解锁所需的完整材料由签名方自己的钱包或硬件提供，solving_data 只是提前把尺寸信息透给选币器。这条口径还能反过来用作自检：如果没提供任何 solving_data 而返回的 fee 异常偏小，基本说明复杂脚本输入被按小尺寸低估了，签名后大概率费率不足，只能 bumpfee 返工。
风险提示：涉及金额单位、手续费估算与输入选择的命令行为请以所用版本官方文档复核；离线签名流程中参数配置错误可能导致费率不足或暴露隐私，签名前务必逐项核对交易内容。本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。