钱包造交易的三道费用闸门：mintxfee、fallbackfee 与 maxtxfee

钱包替你踩下的三道手续费刹车

在比特币核心钱包手动构造交易时，偶尔会看到诸如费用过高被拒绝的报错，或者明明指定了目标确认数，算出来的手续费却贵得离谱。多数情况下，不是网络出了问题，而是钱包内部的三道费率防线在你看不见的地方起作用：-mintxfee、-fallbackfee、-maxtxfee。它们分别负责地板、后备和天花板。

地板：mintxfee

-mintxfee 定义了钱包眼中什么算零费：按 v31 配置参考，费率低于 0.00001 BTC/kvB 的交易在创建阶段就被当作零费处理，钱包干脆不会造这种交易。它的历史默认值可以追溯到每 kB 一千聪的最低中继费传统，今天以千虚拟字节计价。它的意义是防止钱包生成那种永远进不了任何节点内存池的自嗨交易。你几乎不需要调它，调高了只会让找零和小额支出更难成型。

后备：fallbackfee

费率估算依赖节点自己观察到的历史打包数据，新节点或长期空闲的节点可能攒不出足够的样本。-fallbackfee 就是估算失灵时的兜底费率。注意版本差异：早期版本曾给它一个非零默认值，而在 v31 的配置参考里它默认 0.00，也就是默认不启用后备，转而提示你等待估算数据就绪或用 estimatesmartfee 显式确认。设置它等于告诉钱包：估算没把握时按这个价付。设太高，拥塞期会白白多付；设太低，交易可能出不了门。

天花板：maxtxfee

-maxtxfee 是单笔交易的绝对手续费上限，v31 配置参考里的默认是 0.10 个比特币。它防的不是网络，而是操作事故：手滑多打了一个零、选币逻辑异常、或者把费率和费额搞混。一旦某笔交易算出的总费用超过这条线，钱包直接拒绝，报费用过高。这个上限自 0.12 版引入以来一直在起作用。真正需要合并大量粉尘 UTXO 的场景可能撞上它，正确做法是评估归集成本后分次处理，而不是盲目把上限调到离谱的值。另外，旧的手动设价命令 settxfee 在 30.0 文档中已标注废弃，脚本里请改用按次指定的方式，不要把自动化建在废弃接口上。

使用建议

把三个参数想成一条走廊的地板、扶手和天花板：日常交给估算和目标确认数，出问题再逐项排查是哪道防线触发。法律与费用边界以官方文档当前版本为准，本文不构成投资建议。

三个参数怎么配合工作

一次典型的钱包建交易经历这样的顺序：先按目标确认块数向费率估算器要一个 sat/kvB 报价；估算器样本不足时，若 fallbackfee 非零就用它顶替，若为零则按文档提示选择等待或降目标；得到费率后乘以虚拟字节数得出总费用，撞上 maxtxfee 这条绝对线就直接拒绝；最后如果算出的费率还低于 mintxfee 的地板，交易干脆不会生成。理解顺序就知道排障顺序：报价异常先看估算器状态（estimatesmartfee 的置信度字段是关键信号），报价正常但总费用离谱再看体积和选币，最后才怀疑上限参数。

改配置的正确姿势

这三个参数都是 bitcoin.conf 或命令行级别的钱包段配置，改动后需重启钱包生效；settxfee 这类运行时覆盖路径已在 30.0 文档中标注废弃，新脚本不要再依赖它。给自动化钱包服务的部署惯例是：保持 mintxfee 默认、把 fallbackfee 显式设成一个经过评估的保守值、maxtxfee 按业务面额上限加合理手续费余量设置，并给费用拒绝配置可区分的告警日志。法律口径的金额与单位均以你使用的比特币核心版本官方文档为准。顺带一提，费用估算器也有冷启动问题：刚同步完的节点观察窗口里样本稀疏，estimatesmartfee 可能不返回可用报价（结果里没有 feerate 字段），新部署的服务首笔交易被要求等待数据或走人工核对都属正常，不必为此常驻一个非零 fallbackfee。