prioritisetransaction 改的只是这台节点的排序，不是全网账本

不改费用也能插队？prioritisetransaction 的真实语义

矿工组块按费率从内存池挑交易，这是常识。但比特币核心提供了一个 RPC，能让某笔交易在组块算法眼里凭空变贵或变便宜，而没人多付一个聪——它就是 prioritisetransaction。名字里带优先级，语义却很容易被误读，值得逐字拆开。

它到底改了什么

官方文档的原话是：接受该交易进入被打包的区块时具有更高（或更低）的优先级。参数 fee_delta 的单位是聪，是一笔绝对费用增减量，不是费率；文档特别强调，这笔费用并不真实支付，只是让挑选算法把这当作它本应支付了更高（或更低）的费用来处理。换句话说，它改的是这台节点做区块模板时的排序视角，不改交易本身，不改共识规则，也不影响其他矿工的账本。

还有一个历史包袱：第二个参数 dummy 只是旧 API 的兼容占位，必须传零或空，文档标注已废弃。新代码应当用命名参数直接传 fee_delta，把占位符省略掉，避免版本更迭时踩坑。

它能做什么，不能做什么

典型场景有三类。矿池或独立矿工想按自己的策略微调顺序，例如给自己矿工的某些交易一点结构性倾斜，或对某类实验交易降权观察；研究人员在测试网复现拥塞行为，用负的 fee_delta 模拟费率被压低的排队效果；以及本地排障时临时验证某个打包位置的后果。

但边界必须说清。第一，它只对执行这条 RPC 的那个节点的建块选择生效，网络层面的中继和别人的矿池完全不受影响，它不是全网加速按钮。第二，它不保证任何交易被打包——最终决定权在每个出块矿工自己的模板算法里。第三，这个优先级只存在于运行内存中：节点重启后，除非你特意用 importmempool 并把 apply_fee_delta_priority 打开导入带有费用增量元数据的快照，否则调整就消失了，而官方对导入外部文件的元数据持明确的警告态度。

普通用户需要碰它吗

不需要。对持币和转账的用户，它唯一的价值是帮助理解一个事实：内存池显示的费用排名只是各节点各自的视图，不存在全网络统一的一个队列。评估自己的交易何时会被打包时，看的是公共费率市场，而不是任何单点能给你的特殊照顾。机制细节以比特币核心 RPC 文档你正在使用的版本为准，本文不构成任何交易建议。

和邻近机制划清界限

prioritisetransaction 常和两个功能被混谈。一是 -blockmintxfee：那是建块时什么费率以下压根不看的全局地板，作用于所有交易，不针对单笔。二是 -incrementalrelayfee 等内存池准入参数：它们决定交易能不能进池，而本命令假设交易已在池中，只动本机排序视图。还有一个更隐蔽的对比对象是打包费率的祖先费率计算：挑选算法按交易及其祖先的合并费率排序，fee_delta 则是在这个合并值上加绝对增量，对一个低费的父交易子交易链，给子交易加增量可能完全不起作用，因为瓶颈在祖先链——这是排障时最容易看走眼的地方。

一个可复现的小实验

在 regtest 里造两笔费率接近的交易 A 和 B，用 getblocktemplate 先看默认模板里两者的先后；对 A 调用一次正向 fee_delta 的 prioritisetransaction，再取一次模板，观察顺序变化；重启节点后重复取模板，确认调整没有留存。这个十分钟的实验能把排序是内存视图不是共识事实这件事彻底钉牢。所有操作在测试网完成即可验证机制，无需在公网做实验。