加费与门槛共用的一把尺：-incrementalrelayfee 的一百聪每千虚拟字节 图 1
加费与门槛共用的一把尺：-incrementalrelayfee 的一百聪每千虚拟字节 · 图 1

钱包加手续费、内存池抬门槛、交易被拒收——比特币节点里好几个”费用下限”看起来像一家人，其实各管一段。其中最常被误读的是 -incrementalrelayfee：它的名字里带”中继”，作用却不是”最低中继费”，而是一把衡量费用增量的尺子。本文按 v31.0 源码讲清这把尺子的刻度、两处用途和它与其他三把尺子的分界。

刻度：默认一百聪每千虚拟字节

src/policy/policy.h 中的默认值是一百，单位是聪每千虚拟字节，折算是每虚拟字节十分之一聪——与 v30 下调后的节点中继费率地板恰好同值，源码里甚至有一条编译期断言锁定”两者默认值相等”。命令行帮助对它的定位写得很直白：用于内存池限额与替换政策的”中继成本”费率参数。它是一个调试级参数，只出现在扩展帮助里，普通用户通常不需要碰。

这里最容易踩的是单位陷阱。参数按千虚拟字节报价，钱包与区块浏览器常用每虚拟字节计价，两者相差一千倍。想把加费台阶抬到每虚拟字节一聪，参数值要写一千，而不是想当然的一。此外还有一条联动：如果只把 -incrementalrelayfee 设高、没有显式设置 -minrelaytxfee，节点会主动把中继费率地板一并抬到同一水平，并在日志里声明这次跟调（源码 src/node/mempool_args.cpp）——只调一个旋钮、两个下限一起动，这个副作用必须心里有数。

用途一：内存池满时的门槛抬升

内存池空间紧张时，节点会拒绝低于某个费率的交易，这个门槛可以高于永久中继下限，并且是分级往上走的。-incrementalrelayfee 定义的正是这类抬升的步长：门槛不是连续漂移，而是按这把尺子一格一格上移。理解这一点，才能读懂区块浏览器与 RPC 里那个会波动的”内存池最低费率”字段为何呈现台阶形状。

用途二：替换交易要多付的部分

需要加费重发时，规则要求新交易不但绝对费用更高，还要多覆盖它给节点带来的额外开销。-incrementalrelayfee 就是计算这笔”多付部分”的基准。把尺子调小，替换变便宜，节点也更容易被小额替换反复折腾；调大则相反，加费门槛抬高，卡单可能等得更久。这个取舍没有标准答案，取决于使用者更在意响应速度还是费用稳定；改动前先想清楚自己是付款方还是收单方，两类角色的最优刻度并不重合。

与三把近邻尺子的分界

第一把是永久中继下限：低于它的交易根本不进内存池，是绝对地板。第二把是钱包侧的最小交易费，管的是这台钱包愿意花多少钱发一笔，属于个体偏好而非全网政策。第三把是打包侧的最低进入费，决定节点组块时接受哪档交易。四把尺子分别落在”能不能中继、要不要提交、能不能进池、要不要打包”四道门上，串起来读才不会把某一次的拒收原因归错类。

怎么核对这台节点此刻用哪条线

排查现场时，先看内存池概览类 RPC 返回的两类费率字段：永久下限与随拥堵浮动的门槛各自是多少，再对照自己的交易费率落在哪一侧。若交易被拒且提示费率过低，先确认它差的是地板还是台阶——前者调钱包费即可，后者要么等费率回落，要么按台阶幅度一次性加够，零敲碎打的补费很可能一直卡在门槛之下。批量作业（例如支付服务商集中结算）尤其要按台阶幅度预留费用余量，而不是贴着估算值报价。

风险提示：本文讨论节点费率政策参数，不构成投资建议，也不构成任何费率承诺；参数默认值与语义以比特币核心 v31.0 源码为准，实际生效值以运行中的节点配置为准。

参考来源