fundrawtransaction怎么控制选币？ 图 1
fundrawtransaction怎么控制选币？ · 图 1

fundrawtransaction的名字容易让人误以为它会“一步完成付款”。实际上它只是在已有输出的未签名原始交易上，用钱包UTXO补足输入、计算费用并安排找零。fundrawtransaction为未签名原始交易补充钱包输入、找零和费用，返回hex、fee与changepos。 返回的hex仍然需要解码、复核和签名。

把一次付款拆成四个工位

createrawtransaction 构造意图
  → fundrawtransaction 选币、费用、找零
  → decoderawtransaction 人工或策略复核
  → signrawtransactionwithwallet 签名
  → sendrawtransaction 广播

分阶段的意义，是让“我要付给谁多少钱”和“钱包选了哪些输入”分别可审计。若直接把fund后的hex送去签名，自动选币、找零地址或费用单位错误都可能在最后一步才暴露。

参数不要按字母表理解

有效选项包括changeAddress、changePosition、lockUnspents、fee_rate、subtractFeeFromOutputs与include_unsafe等；includeWatching在Core 31文档中已标为弃用且不再使用。 可以按四组整理：changeAddress与changePosition控制找零；fee_rate与conf_target等控制费用；lockUnspents影响被选UTXO之后是否锁定；subtractFeeFromOutputs决定费用从哪些收款输出扣除。includeWatching在Core 31已经弃用且不再使用，不应作为新实现的控制项；include_unsafe会允许使用钱包认为不安全的输入，只有理解风险来源并有补偿控制时才考虑。

选择影响验收点
changePosition找零输出位置changepos与解码结果一致
fee_rate目标费率单位、总费用、合理区间
lockUnspents后续并发选币锁定清单与释放路径
subtractFeeFromOutputs收款净额哪些输出被减费
include_unsafe输入可信度为什么必须使用及风险记录

不要同时指定互斥的费用选项，也不要把BTC/kvB、sat/vB等单位凭经验互换。调用后用返回fee和交易vsize复算有效费率，再与节点估算和业务上限比较。

找零是隐私决策，不只是数学余数

自动找零可能把原本不相关的UTXO合并，暴露地址聚类；自定义changeAddress又可能因复制错误把找零送到不受控地址。使用钱包生成的找零时要确认描述符与备份覆盖，自定义地址时则进行白名单和双人复核。

changePosition只是位置，不保证某个输出“看起来像找零”就真是找零。下游系统应使用返回的changepos和钱包元数据，而不是靠金额大小猜测。

subtractFeeFromOutputs最容易造成金额争议

未开启减费时，钱包会额外筹集费用，目标输出保持原金额；指定减费输出后，收款方实际收到的金额会减少。多个输出被指定时，RPC会在这些输出之间等额扣费，不支持业务层自定义比例；签名前必须把每个输出净额展示给复核者。支付发票、批量提现和归集对这一差异的容忍度完全不同。

并发钱包为什么要锁UTXO

多个工作进程同时fund时，可能选中同一UTXO。lockUnspents可以降低并发冲突，但也要求失败、取消和超时后有明确解锁流程。锁定状态不是链上冻结，节点重启和钱包操作还需单独测试。

该RPC不会签名交易，调用者仍需在签名前核验全部输入、输出、费用、找零脚本和金额。 fundrawtransaction不会签名。签名前至少核对全部输入属于预期钱包、每个目标地址与金额、找零脚本、绝对费用、有效费率、锁定状态和RBF策略。广播后再以txid和节点接收结果闭环。

本文是Bitcoin Core 31钱包RPC操作指南，不替代密钥管理或支付审批制度。选币结果受钱包UTXO、标签和节点环境影响，生产上线前应在regtest用小额、批量、多找零和并发失败场景验证。

把自动选币接回支付审批

生产审批记录应同时展示原始支付意图和fund后的真实交易，两位复核者分别确认收款净额、找零归属、总费用与被选UTXO。失败或取消任务还要释放锁定输出，并记录是否需要重新估费和重新选币。

签名与加速阶段可继续阅读比特币UTXO与找零、bumpfee与psbtbumpfee、PSBT签名前核对。选币结果仍受以下条件限制：实际选币结果受钱包UTXO、标签、避免找零策略和费用估算环境影响，示例不保证复现同一输入集合。