比特币核心 v31.0 的费率估算器改了一个看似不起眼的数：最低的费率统计桶从 1 sat/vB 下探到 0.1 sat/vB，与节点默认的中继费率下限对齐。发行说明同时给了一句有分量的提醒：带这个改动重启节点会作废 fee_estimates.dat 里之前保存的估算——估算器会从零开始重新统计。为什么把桶的下界挪十倍会有作废历史数据的威力？低费率桶会让 estimatesmartfee 给出更便宜的建议吗？这篇把费率估算的分桶机制、这次改动的影响半径和重启后的冷启动现象讲清楚。
先搭机制骨架。比特币核心不预测未来，它做的是历史统计：把过去的区块按时间排成一段段”确认目标窗口”，在每个窗口里再按费率切成一条条桶（bucket），记录每笔交易实际落在第几个区块被确认。当你对 estimatesmartfee 说”我要 6 个区块内确认”，节点就在这些统计里找：从满足成功率要求的区间出发，回看那些交易被确认时所处的费率桶，取桶的平均费率作为建议。整个结构的分辨率就是桶的边界——统计只覆盖”有桶的地方”，1 sat/vB 以下的历史费率在旧版本里全被塞进同一个最低桶，没有更细的分辨率。
v31 的改动把最底层的刻度加密了：100 sat/kvB（等于 0.1 sat/vB）起就有独立的桶，源码里 MIN_BUCKET_FEERATE 常量为 100（单位是 sat/kvB 语境下的内部表示），对应发行说明”最低费率桶从 1 sat/vB 更新为 0.1 sat/vB，与默认 minrelaytxfee 一致”的表述。直接后果是：当拥堵回落、大量交易确实以 0.1 到 1 sat/vB 之间的费率进块时，估算器现在能对这一档单独建模，长确认目标（比如 100 个区块这种慢车道）的建议费率不再被”最低也按 1 sat/vB 记”拖住，可能报出更低且更贴近现实的数值。
为什么必须作废旧的 fee_estimates.dat？分桶边界是统计文件的骨架：历史记录里每个观测值标记的是”当时落在第几号桶”，桶的边界一变，同一号桶对应的费率区间就变了，旧数据直接对新刻度就是坐标错位——与其悄悄错着算，不如整本作废。这就是发行说明”重启会使先前保存的估算失效”的技术原因。由此带来一个可观察的现象：升级后头几个小时里，你的节点会对一些确认目标返回”没有足够历史数据”（estimatesmartfee 的 blocks 返回 0 或空），这是冷启动，不是故障；fee_estimates.dat 每小时落盘一次，随着新区块被观察，桶会逐步填回来。
两条使用层面的提醒。其一，建议费率的地板不由这次改动决定：估算结果再低，你的交易要过中继与打包，还得看 minrelaytxfee（默认 0.1 sat/vB）和 mempool min fee 的脸色；估算器报 0.15，不代表网络每条路径都收。钱包侧同样有独立的最低交易费参数，最终费率是这几层闸门叠加的结果，把 estimatesmartfee 的返回值直接当”绝对可以进块的价格”是常见误读。顺带一提，v31 还有一件相关大事：settxfee 与 -paytxfee 这两个设置静态费率的入口在本版本被正式删除（v30 标记废弃），官方推荐的姿势就是靠估算或按笔指定 fee_rate 参数——费率桶细化与静态入口拆除是同一套理念的两半：让费率决策回到逐笔、基于统计的轨道。其二，想跨版本比对费率曲线的人要注意口径断裂：同一台节点升级前后各取一段 estimatesmartfee 时间序列，低费率段的跳变里有一部分是刻度变化造成的，不是市场变化，做分析要先断点处理。
版本事实核对口径：最低桶数值与作废说明来自 v31.0 发行说明 Fee Estimation 一节；MIN_BUCKET_FEERATE 常量可在源码 policy/fees/block_policy_estimator.h 查得；v30 及更早版本的最低桶是 1 sat/vB，无此问题。
风险提示：费率估算只反映历史统计，不保证任何一笔交易的确认时间，低费率窗口可能在下一个区块周期就结束；本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。