simulaterawtransaction能验什么？

Bitcoin Core 的 simulaterawtransaction 只计算原始交易集合对当前钱包的合计余额变化。本文通过对照实验说明它与签名、策略接受、广播和确认之间的边界。

这个 RPC 的名字很容易让人联想到“预演整笔交易”。实际范围窄得多：它站在当前钱包视角，估算给定原始交易被签名并广播后的合计余额变化。把它放到正确位置，它是签名前的有用防线；把它当成执行模拟器，就会漏掉关键风险。

实验台：先确认它真正返回什么

simulaterawtransaction接收一组原始交易十六进制字符串，计算这些交易被签名并广播后对当前钱包造成的合计balance_change。

bitcoin-cli simulaterawtransaction '["<rawtx-hex>"]'
=> {"balance_change": -0.01234567}

返回值只有钱包余额变化数值，负数表示余额减少；它不是逐输入输出的执行追踪，也不会返回确认时间。

负数表示钱包余额减少，但它没有告诉你每个输入、找零输出或外部收款分别贡献多少，也没有给出交易何时确认。多笔交易作为数组提交时，先保存数组顺序和每笔 txid 预期值，避免只留下一个无法追溯的合计数。

正样本使用已知找零和小额外部输出，手工按钱包所属输出复算余额变化。反样本可以替换收款地址、移除找零或加入不属于钱包的输出，观察 balance_change 是否按预期改变。若结果与手工账不一致，停止签名并检查加载的钱包、链状态和交易依赖。

对 watch-only、外部签名器或多钱包环境尤其要注明“当前钱包”是哪一个。include_watchonly 在 30.0 文档中已标为不再使用，旧脚本继续传参不应被误解为覆盖了所有只读地址。

余额模拟不等同于节点会接受或网络会确认交易；广播前还应使用testmempoolaccept检查当前节点策略与拒绝原因。

两者都通过后仍要核对签名摘要、费率、找零地址和广播节点。链头、内存池和 UTXO 状态在检查与广播之间可能变化，因此高价值交易要在短窗口内重跑关键验证。

攻击者可以让合计余额变化看起来合理，却把找零送往错误脚本，或诱导钱包花费不期望的 UTXO。只看一个负数无法发现地址替换、隐私合并、RBF 策略和锁定时间问题。最终审批必须回到解码后的输入输出清单。

保存原始交易、解码结果、输入 UTXO 状态、每个输出归属、balance_change、testmempoolaccept 原始响应、钱包名、节点版本与链头。让第二位操作者从原始数据重放，而不是复述第一位操作者的结论。

仍需控制的变量是：结果依赖当前加载钱包与节点视图，多笔相互依赖交易、已花费状态和并发链头变化都应在最终签名前重新核验。

延伸阅读：Bitcoin Core完成PSBT、内存池与费率口径、描述符检查。本文仅提供技术核验流程，不替代钱包备份、独立审批或资产安全审计。

用同一组输入制作三笔未广播交易：正常找零、找零地址替换、费用异常偏高。比较 balance_change、解码后输出和 testmempoolaccept 结果，记录哪一层首先发现问题。演练结束后销毁测试密钥与原始交易，确保复核过程不会意外进入生产广播队列。