一笔交易广播出去还没进块，能不能加钱重发？答案写在交易输入的一个编号字段里，而钱包是否默认填这个”可替换信号”，由 -walletrbf 决定。v31.0 源码里这个参数的帮助文本写着”RPC only, default: 1”——短短几个词里藏着两个容易踩的坑：一是默认值曾经历过翻转，二是”RPC only”说明它管不到图形界面。本文把这三层说清。
默认值的时间线要写准
参数在 0.14 引入时默认关闭；到 24 系列，24.0.1 的发布说明明确写下：-walletrbf 启动选项现在默认为真。v31.0 源码 wallet.h 里的常量 DEFAULT_WALLET_RBF = true 与此一致。写教程时最常见的错误是拿旧印象说”需要手动开启”，或反过来把 0.16 图形界面已默认使用 RBF 的历史（当年发布说明写明 send 界面默认走 RBF、RPC 默认当时不变）套到今天——两件事分属不同子系统，版本语境不同。
信号到底写在哪
钱包构造交易时，如果该笔被标记为可替换，会给没有时序用途的输入填入 BIP125 约定的编号 0xfffffffd，低于最大值但仍属非终值；反之填入非终值的另一个数值。这个编号本身不改变交易的有效性，只是向矿工表达”我这笔允许被更高费率的冲突交易顶替”。打包判断是矿工与矿池的政策，不是共识规则——所以信号是”意愿”，进不进块看网络环境。
RPC only 的确切含义
钱包加载时读取 -walletrbf 存为默认值，之后所有走 RPC 的发送类命令在未显式指定 replaceable 选项时继承这个默认。spend.cpp 里的逻辑就是三选一：命令带了 replaceable 用命令的，没带用钱包默认，仅此而已。“RPC only” 的历史包袱来自图形界面另有自己的 RBF 策略线，不由该参数管辖；配置前应确认你的发送路径究竟是 RPC 还是界面。
单笔覆盖全局的写法是 bitcoin-cli -named sendtoaddress address=… amount=… replaceable=false，用 replaceable 选项逐笔压制或强制。想审计”我的钱包到底在不在发信号”，看 listtransactions 或 gettransaction 输出里的 bip125-replaceable 字段，取值 yes、no 或 unknown——unknown 表示该笔依赖的未确认父交易信号状态未知，不是故障。
关掉的代价与留下的暴露
支持全量 RBF 的接收方越来越多，对它们而言信号与否影响不大；但零确认场景下，明确带信号的交易能被收款方按”可替换”定价，而不带信号的交易在保守中继政策下可能遇到更多阻力。另一方面，全部交易统一带信号也是一种标准化：它让”可替换”不再是区分个别用户的指纹。两种立场都有依据，关键是知道自己用的默认是什么，而不是道听途说。
还有一个隐蔽的联动：钱包的自动重广播逻辑（未确认交易的定期重发）在处理带信号交易时可以自由构造替换版本；关掉信号后，同一批钱想加急就只能走 CPFP 或在交易被丢弃后重造。理解这一点，就不会在费率飙升时惊讶于”加不了费”。
半确认场景的一个补充
钱包重发未确认交易时还有另一个常被混淆的开关：自动重广播的间隔与目标确认数由费率估算与 txconfirmtarget 类参数主导，与信号开关无关。带信号的交易重发时通常以更高费率构造替换版本，nSequence 随之更新；不带信号的重发只能原样重播，寄希望于对端仍然记得。两套机制一个管”能不能换”、一个管”多久喊一次”，在拥堵时段叠加使用时，检查任何一条都应从构造出的交易原始字节出发，而不是从界面上的提示语出发。
检查清单
一看参数：bitcoind -help-debug 或源码确认你版本的默认值；二看单笔：发送时显式带 replaceable 最稳；三看链上：用区块浏览器的 replace-by-fee 标记交叉验证 bip125-replaceable 字段；四看历史：交易一旦进块，信号失去意义，任何”替换”都不可能。四步都过，这个参数对你就不再是玄学。
风险提示：本文为钱包参数与交易信号机制说明，对应 Bitcoin Core v31.0 源码；默认值与中继政策随版本与矿工策略演进，不构成投资建议；涉及未确认资金的一切决策请以完整确认后的链上状态为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。