RBF 在确认之前解决中继交易。 BIP125 在 Bitcoin Core 0.12 中正式化了选择加入信号和替换规则，而全 RBF 后来甚至在没有信号的情况下也进行了通用替换。 Core 24 添加了可配置的全 RBF，而 Core 28 将其设为默认值。 RBF不改变共识或已确认的区块；它仅更改节点保存和传播的有效的未经确认的冲突版本。
RBF 替换内存池中因相同输入而发生冲突的一笔或多笔未提交交易。块中已提交的任何内容都不会被覆盖，并且替换事务具有不同的 txid，因为它具有不同的序列化。
BIP125 最初标准化了 nSequence 低于 0xffffffffe 的选择加入信号。当默认中继需要 RBF 选择加入时，该信号至关重要； full-RBF 后来删除了信令作为通用替换条件。 (0xfffffffe)
RBF 是本地内存池和中继策略，而不是共识规则。矿工可以包含任何共识有效的冲突交易，并且全节点都会验证结果块，无论它之前在内存池中保存的是哪个版本。
Bitcoin Core 限制了反 DoS 规则的替代。候选者必须提高冲突集的费用结果并满足中继和标准化政策；他们花费相同的 UTXO 的事实不足以被接受。
绝对费用和费率是两个不同的术语。如果绝对增加不能覆盖推送的交易和增量中继成本，那么仅提高费率是不够的；如果没有匹配率，即使只是添加聪也可能是不够的。
替换父交易也可以从内存池中删除其子交易。因此，该策略限制了冲突的大小，并考虑了包中的关系，因此替换并不是过度消耗 CPU、内存和带宽的廉价方法。
RBF 通过替换支出交易本身来提高费用。 CPFP 父进程保留并添加一个昂贵的子进程，以便矿工可以评估公共包。选择取决于钱包控制哪些输出以及交易图的样子。
RBF是一种托管内存池替换机制；双花表示冲突或尝试使用不兼容的相同 UTXO。同样的机制可以是合法的费用上涨和尝试重定向未经确认的付款。
在确认之前，比特币不保证商家看到的第一笔交易就是开采的交易。 Full-RBF 强调了这一点：采用零配置是一种商业风险决策，而不是比特币的最终结果。
通过 getmempoolentry，可以查看未确认的交易，并且 testmempoolaccept 可用于根据自己节点的当前策略测试候选替换。 Bitcoin Core 28 将 mempoolfullrbf 更改为默认开启； getmempoolinfo 显示相关版本的完整 RBF 状态。
要获得更完整的理解，请将本词条与以下词条结合阅读： 交易费, Mempool, CPFP (Child Pays for Parent), 双花, 确认, Fee Rate. 反向关联还来自： 找零输出, 确认, 双花, Fee Rate.