Replace-By-Fee (RBF)

Introduction

Replace-By-Fee (RBF) on the Bitcoin blockchain is a mechanism that replaces a previously transmitted transaction with a new transaction that pays a higher fee. This feature is extremely useful during times of high network congestion, when transactions with lower fees can get stuck waiting for confirmation. RBF ensures you can prioritize transactions based on your willingness to pay higher fees.

RBF originated from when Satoshi Nakamoto was still actively contributing to Bitcoin. This feature was initially disabled, due to concerns over abuse and the network's ability to handle additional complexity. Eventually, the network grew and needed this functionality, particularly during the Block Size debate when congestion was a significant issue.

The formalization of RBF came in 2015, with the introduction of Opt-in RBF by developer Peter Todd, leading to the creation of Bitcoin Improvement Proposal 125 (BIP 125). This proposal outlined how transactions could be marked as replaceable and set the conditions under which the network would accept them. The adoption of BIP 125 marked a significant milestone, allowing users to signal explicitly that their transactions could be replaced, thereby offering a way to adjust transaction fees after the fact.

Understanding Replace-By-Fee (RBF)

Traditionally, a transaction is immutable once it's broadcast to the network. However, RBF enables users to accelerate their transactions to increase fees and expedite confirmation. Bitcoin transaction fees can be unpredictable, and submitting a transaction with the best fee at the moment doesn't always guarantee timely confirmation. With RBF, you can replace transactions with higher fees if needed, preventing them from being stuck when fees fluctuate.

RBF vs CPFP

A transaction can only be included in a block when all its inputs are confirmed. This requirement can be used to increase the effective fee rate of a stuck low-fee transaction. One of the stuck transaction's outputs is spent in a child transaction with a much higher fee. Miners first include the transactions with the highest fees to maximize their revenue, but the high-fee child transaction can only be included once the parent transaction is confirmed. The miners are, therefore, incentivized to include both the parent and the child transaction together in a block. A Child-Pays-For-Parent (CPFP) transaction can be created by a recipient of the transaction or by the sender if the target transaction has a change output.

A transaction can be replaced by a new transaction with a higher fee as long as the new transaction spends a few or all of the same inputs used by the original transaction that's being replaced. Unlike CPFP, only the transaction sender can create an RBF transaction, and only one of the two transactions can be confirmed. More often than not, the replacement transaction with the higher fee is accepted by the miners. One key benefit of RBF over CPFP is that it doesn't require the presence of a change output in the original stuck transaction.

Benefits of RBF

The introduction of RBF brings several benefits:

  • Transaction Flexibility - RBF enables greater control over your transactions. In situations where the initial fee was insufficient to attract miners' attention, RBF lets you increase the fee dynamically to accelerate confirmation.
  • Enhanced User Experience - By empowering you to manage your transactions after broadcasting them, RBF contributes to a smoother and more efficient transaction experience, particularly during periods of network congestion.