bumpfee 给卡住的比特币交易加钱：改费重发的机制与失败清单

一、bumpfee 到底改的是什么

交易迟迟不进块时，钱包命令行里那条 bumpfee 常被拿来救急。它做的事不是给原交易贴钱——账本上没有修改一笔已广播交易的途径——而是以原交易为底稿再造一笔新交易：同一批收款人、同样的付款金额，费率抬高，广播出去顶替旧的那笔。旧交易被替换出内存池，等于一次带改版的重复提交。

命令挂在钱包模块下，参数就是那笔卡住交易的 ID。第一条硬前提就写在文档第一句：这笔交易必须来自你自己的钱包。别人广播的单子，这里碰不了。

二、加的钱从哪来

费用没有独立字段，它等于输入总额减输出总额。要让新交易费率更高，程序只有两条路，文档原文把这两条说清楚：必要时削减找零输出，或者添加新的输入，需要时还能新增一个找零输出。

钱包默认优先第一种：从找零里抠钱。原交易带找零、余额够填差价，加费就是一次干净的内部腾挪。没有找零或找零填不平时，程序开始从钱包里挑新的未花费输出凑进来。这一步的副作用要留心：新的输入来自哪个地址，交易史就多了哪条归并线索，旁观者可以把更多输出聚到同一个人名下。

三、门槛：高多少才算数

新交易不是比旧的贵一点就能进池。文档给了两道数。一道是通用约束：新费率至少要高出一个增量中继费（getnetworkinfo 返回的 incrementalfee），否则节点自己都不肯收。另一道写在 fee_rate 参数说明里：31.0 版要求新费率至少比旧费率高 0.100 聪每虚拟字节；更早版本文档写的这个数字是 1.000——跨版本复用传参脚本时这里最容易踩。费率单位也有历史换轨：0.21 之前按每千虚拟字节计价，0.21 起统一为每虚拟字节计价。

不写参数就走自动估算：内部调 estimatesmartfee，按 conf_target 的目标确认块数取费率。replaceable 控制替换单还留不留可替换标记：按 31.0 文档，true 时输入序列号写成 0xfffffffd，false 时凡是低于 0xfffffffe 的序列号被抬到 0xfffffffe——新单不再显式声明可替换，此后还能不能加费，只剩未确认祖先恰好可替换这类边角情形。

四、失败清单

结果里的 errors 数组非空是常态输出，多数报错能翻译成一句话。交易不在钱包里：bump 无从谈起。原交易不可替换：没带 RBF 信号、祖先里也没有可替换的，规则不让顶。找不到找零又挑不出够用的输入：钱加不出来。新交易自己又排在低费父交易后面：父单不动，子单照旧不进块。原交易已进区块：替换窗口永久关闭。

五、双包并存的插曲

多次 bump 之间也有队列：上一笔替换单还挂在内存池，它自己就是下一笔的冲突项与祖先，排队受祖先集合规则约束。动手前先查原交易的输入有没有别的版本在途——双胞胎在飞时 bump 的结局取决于哪版先被接受，再查钱包余额：新输入来自本钱包，余额太薄凑不齐差价，调用直接失败。

六、离线与多签的变体

钱包不带私钥时，命令换成 psbtbumpfee：产出的不是广播好的交易，而是一份未签名的 PSBT 草稿，签名与广播留给握钥匙的设备或人，桌面端、签名器、广播端各管一段。多签共管场景走同一条路，改费的决策顺序跟着既定签名顺序走。结果字段留 origfee 与 fee 两个数字，差额就是本轮加急成本；errors 非空时新交易未必广播成功，拿返回的 txid 回内存池或历史里再对一遍。

七、CPFP 是另一条车道

加不了输入的场合，工具换成 CPFP：把卡住交易的输出作为输入再发一笔子交易，节点按祖先包费率一起结算，矿工看到的综合费率被子单抬起来。bumpfee 是付款方动自己的钱包，CPFP 是收款方动刚到账的输出——两条车道的油门踩在不同人的脚下。

八、版本差异

命令的开场定义随版本演进：一些版本的文档写它是给 opt-in-RBF 交易提升费用的工具；31.0 的文档把限定词从首句拿掉，改由 replaceable 参数控制替换单的去留标记。跨大版本排障时，把失败返回读成政策信号而不是偶发故障，先读当前版本的发行说明再改脚本。

风险提示：本文仅为技术机制科普，不构成任何投资建议。