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. Bitcoin initially disabled this feature due to concerns over abuse and the network 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 signal replace-by-fee capability 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 were replaceable, thereby offering a way to adjust transaction fees after the fact.

Understanding Replace-By-Fee (RBF)

Traditionally, a transaction is immutable once the sender broadcasts it 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 stalling when fees fluctuate.

RBF vs CPFP

Miners can only include a transaction in a block when all its inputs have confirmation. This requirement can increase the effective fee rate of a stuck low-fee transaction. A child transaction with a much higher fee spends one of the stuck transaction outputs. Miners first include the transactions with the highest fees to maximize their revenue, but miners can only include the high-fee child transaction once the parent transaction achieves confirmation. The miners therefore have an incentive to include both the parent and the child transaction together in a block. A recipient of the transaction or the sender can create a Child-Pays-For-Parent (CPFP) transaction if the target transaction has a change output.

A new transaction with a higher fee can replace an existing transaction as long as the new transaction spends a few or all of the same inputs the original transaction used. Unlike CPFP, only the transaction sender can create an RBF transaction, and miners confirm only one of the two transactions. More often than not, the miners accept the replacement transaction with the higher fee. 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.