钱包发一笔比特币交易时，可以选择”我要它六块内被打包”，也可以直接说”每虚拟字节给我出 15 聪”。走前一条路时，还有一个常被忽略的旋钮：estimate_mode，它取 economical 或 conservative，决定同样的确认目标翻译成多大的费率。本文按 v31.0 源码 src/wallet/rpc/spend.cpp 把这两档的真实分工讲清楚。
帮助文本里的官方定义
sendtoaddress 的参数表里，estimate_mode 的说明写着：取值不区分大小写，必须落在几档之内；而两档的语义由 FeeModesDetail 拼接出那句关键注释——“economical mode is used if the transaction is replaceable; otherwise, conservative mode is used”。拆开这句机器生成的话：默认的 unset 模式下，钱包先判断这笔交易是否带替换信号（是否按 BIP 125 打了 RBF 标记），带信号走 economical，不带就走 conservative。显式传值则跳过这个自动分流。
为什么替换信号会改变选档？逻辑在于错误的可撤销性。可替换的交易即使第一口价出低了，之后还能用 bumpfee 或手动 RBF 加价重发，试错成本被兜住，钱包就敢用更省的估计——取那个”历史数据显示该目标内能进块”的较低分位。不可替换的交易没有后悔药，估算失手只能干等，钱包改用保守策略：看更长、更苛刻的观测窗口，取对拥堵更悲观的那个数，宁可为早进块多付。
参数互斥的三条硬规则
源码函数 InterpretFeeEstimationInstructions 用三个判断钉死了参数关系。其一，conf_target 与 estimate_mode 要么全走位置参数、要么全走 options 对象，两边同时给直接报”but not both”。其二，fee_rate 同样二选一。其三，也是最常见的一记：只要给了 conf_target 而 estimate_mode 留空或为 unset，命令直接抛 “Specify estimate_mode” 错误——想按块数出价的调用必须对模式表态，没有静默默认值可蹭。
三档里还有个第三值 unset，它不是”第三种模式”而是”交给自动分流”，前面说的 economical/conservative 按替换信号选路就发生在 unset 之下。
什么时候值得手动选档
场景一是脚本化服务费估算：批量做市、开票系统按 conf_target=3 加 economical 出价，同时给每笔打上 RBF，两件事配套才成立——只设 economical 却不带替换信号，等于把”敢便宜”的前提丢了。场景二是必须一次过的大额不可替换转账：明知全链拥堵、又不想引入 bumpfee 流程，可以把不可替换交易配 conservative，让钱包按悲观假设出价。场景三是比较费差做审计：对同一目标块数分别取两档结果，差值本身就是当期估算器不确定度的一个粗量化读数——两档几乎相等说明近期费率稳定，估算窗口分歧大则说明拥堵突变。
最后提醒一层边界：两档模式都建立在费用估算器自己的历史观测上，v31.0 把估算器的最低费率桶从 1 聪每虚拟字节下调到 0.1 聪，重启后旧 fee_estimates.dat 作废重新积累——这意味着大版本升级后的头几小时，两档估计可能都偏保守。estimate_mode 管的是”怎么读估算器”，不是”估算器数据够不够”，两个维度别混在一个参数上思考。
与 fee_rate 直给的决策树
把三种出价方式排个序：知道自己要什么费率就直接 fee_rate，估算器整个不参与，结果最确定；只有目标没有把握时用 conf_target 加 estimate_mode，把翻译工作交给估算器；什么都不传则落回钱包的 -txconfirmtarget 默认目标走自动分流。脚本作者常犯的错是三种混用——先设了全局默认目标，又在调用里给 economical，还留了个 fee_rate 空串——最终触发上面那条 “but not both” 互斥报错。一条干净的调用里，费率语义只应有一个来源：要么块数加模式，要么每虚拟字节多少钱。测试网演练时把两档各跑一遍、记录进块时间与实付费用，比读十篇经验帖更能建立对该模式松紧的直觉。
风险提示：本文为钱包费率机制说明，涉及资产转账的费用参数请先小额演练；本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。