比特币节点每天处理成千上万条交易通知，但其中相当一部分是“注定进不了我内存池”的低费交易。为减少这类无效沟通，比特币网络在协议版本 70013 中引入了一条简单的消息：feefilter，对应提案编号 BIP133，Bitcoin Core 从 0.13.0 版本开始支持（该版本把协议版本升到 70013）。它的内容只有一个整数：发送方当前内存池的最低准入费率，单位是聪每千字节。接收方看到这条消息后，被允许但并非强制要求，在向该邻居广播交易前先做一次费率自查，低于门槛的直接不发通知。
它解决的具体问题
比特币交易的传播依赖两条消息：先用 inv（公告：我有这样一笔交易），对方若感兴趣再发 getdata（把全文给我）。在 feefilter 出现前，即便一个节点的内存池已经塞满、只接受高费交易，邻居并不知道，仍会把低费交易的 inv 一条条送过来。节点这边要么拉取全文再拒绝，要么用拒绝过滤器挡重复请求，但过滤器会随每个新区块重置，同一条低费交易可能被反复询问。内存池的最低准入费率机制本身是 0.12 版本引入的，用来防御低费攻击和垃圾交易，feefilter 则补上了“把这个信息提前告诉别人”这一环，省掉一整轮 inv 加 getdata 的往返。
消息怎么发、发给谁
feefilter 的载荷是一个 8 字节整数，语义为聪每千字节。节点通常根据自己的内存池最低费率来生成它：内存池越大、越拥挤，这个值越高。为避免泄露节点自身的内存池状态这一隐私信息，实现上有两点缓和措施：发送的数值会做量化并加一点随机抖动，发送时间也按随机分布打散，而不是费率一变就立刻广播。白名单连接有个例外：如果节点配置了白名单强制中继，就不会向白名单对端发这条消息，因为那类连接的约定是不管费率高低都要中继。另外，这条过滤器与轻钱包用的布隆过滤器是叠加关系：一条交易要同时通过两层筛选才会被通知。
普通用户会感受到什么
如果你运行一个内存池常年接近上限的全节点，打开调试日志，会看到节点定期向各对端发送 feefilter 字样的记录，数值随网络费率水平起伏。作为发送方交易的用户，这条消息不改变你自己交易命运：它只影响“哪些邻居选择先不通知你”，不影响交易能否被网络最终接收。低费交易在网络里的传播确实可能更慢，因为越多节点启用了过滤，它经过的路径越少，但这是概率性减速，不是拒收。
常见误区
一是把 feefilter 当成防火墙：它不拒绝任何交易实体，只省略通知这一步，节点收到低于门槛的交易全文时，行为规则与从前相同。二是把“某一跳没收到某交易的 inv”理解成对端故障：更常见的解释是邻居启用了 feefilter 且该交易费率低于门槛。三是把它和节点拒绝服务、连接封禁混为一谈：不遵守这条消息不会被视为作恶，协议本身就写明接收方“可以但不必须”执行过滤。
快速问答
问：feefilter 的数值会一直变吗？答：随内存池水位浮动，长期空置时趋近节点的基础中继费率，拥挤时明显抬高。问：不发这条消息的节点会掉队吗？答：不会，老版本客户端完全兼容，可以永远不发。问：它和费率预估工具看到的推荐费率是一回事吗？答：不是。推荐费率是给用户参考的估算值，feefilter 反映的是某个节点此刻的内存池准入线，两者口径不同。
风险提示：本文为协议机制科普，不构成任何投资建议。运行节点或调整中继参数会改变你的带宽与存储占用，请根据自身条件选择配置。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。