钱包报价背后的三档统计窗口：比特币费率估计器如何切分确认延迟

钱包问你”想几个区块内确认”，然后报出一个费率建议。这个建议不是拍脑袋，而是节点长期观察”历史上各种费率的交易实际等了几个区块才进块”统计出来的。统计得把”等几个区块”切成几档窗口，切法全写在源码里：短期窗口盯 12 个区块，中期 24 个，长期最多拉到 1008 个确认（约一周）。本文全部以 Bitcoin Core v31.0 源码为准，相关常量在 src/policy/fees/block_policy_estimator.h。

观察什么：交易进块要等几块

估计器的思路是”分桶计数”。它把费率轴切成很多桶，每笔被丢进内存池的交易按自己的费率落进某个桶。之后每出一个块，节点回头看：这个块收录了哪些交易？那些交易当初落在哪个费率桶？于是每个桶逐渐积累出一张经验表——“落在费率的这个档位，历史上有多少比例是 1 块内进块的、多少是 2 块、3 块……”。有了这张表，给定一个”我想 N 个区块内确认”的目标，就能反查需要落在哪个费率桶。

三档窗口和它们的地平线

关键是”等几块”这条轴要切多长。源码定义了三个地平线：SHORT_BLOCK_PERIODS 为 12，注释写明”为短期地平线最多跟踪 12 个区块的确认延迟”，配套 SHORT_SCALE 为 1；MED_BLOCK_PERIODS 为 24、MED_SCALE 为 2，管中期；LONG_BLOCK_PERIODS 为 42、LONG_SCALE 为 24，是长期地平线的分桶数——注意 42 是分段数而非直接 42 个区块，配合步长（scale）把粒度铺开，最终覆盖到很长一段。还有一条更硬的截止：OLDEST_ESTIMATE_HISTORY 取值为 6 * 1008，即 6048 个区块（约六周），注释说”比这更老的历史估计作废”。所以哪怕你问一个很长的确认目标，估计器也不会拿六周前的老皇历来糊弄你。

衰减：让近期样本更有话语权

历史观察不是等权累加的，源码给每档地平线配了”衰减值”。SHORT_DECAY 为 0.962，注释解释这相当于”半衰期 18 个区块、大约三小时”——意思是三小时前的观察，权重衰减到一半。MED_DECAY 为 0.9952，半衰期约 144 个区块、一天；长期衰减更慢，因为它本就要刻画更稳定的慢车道费率。这套指数衰减让估计器对新近网络状态灵敏、又不至于被单笔异常带跑。这也是为什么刚同步完的新节点报不出长期估计：它还没攒够跨窗口的样本。

你的估算落在哪一档

当你传一个 conf_target（确认目标）时，RPC 会在短、中、长三档里选对应窗口去查费率桶：目标小（比如 1 到 6 块）走近期窗口，报出的建议对当下拥堵更敏感；目标大（几十上百块）走长期窗口，数值更平滑、更贴近”慢慢等也能进”的现实。读 estimatesmartfee 的返回时，blocks 字段告诉你建议实际对应几个区块——它可能小于你请求的目标，因为估计器在自己能力范围内已经提前收敛。

常见误区

一是把三档窗口当成”三条独立的价格曲线”，其实它们喂自同一份观察流，只是聚合窗口不同，长期值不会和短期值同时打架。二是以为 OLDEST_ESTIMATE_HISTORY 六周后老样本”消失”，其实它只是停止影响估计，文件本身照存，重启后仍从上次位置继续。三是把半衰期当成”过三小时估计才更新”：衰减是每出一个块、随时间连续发生的，不是等到半衰点才跳变。理解这套切窗与衰减，你就明白了钱包那个”建议费率”到底是谁、在替谁、基于多久的经验说话。

风险提示：本文为费率估计机制科普，常量与窗口以 Bitcoin Core 当前版本源码为准，可能随版本调整；估算结果不构成费率承诺或投资建议。