Sending a payment is not the same as confirming it. Until a miner includes it in a block, nodes — programs that check and relay Bitcoin transactions — may keep it in their Mempool, a local list of pending transactions. Under certain conditions, RBF lets them accept a new transaction instead, spending at least one of the same UTXOs: an output that has not yet been spent. The replacement needs valid signatures and must be submitted to the network; a higher fee alone does not guarantee quick confirmation.
Anna sent 20,000 sat, but her payment is still pending. The abbreviation sat means satoshi, the smallest unit of bitcoin. Her wallet offers to increase its fee using RBF. In a simple example, the original transaction spends 50,000 sat: 20,000 sat goes to the recipient, 200 sat pays the fee and 29,800 sat returns to Anna as change. The replacement can still pay the recipient 20,000 sat while raising the fee to 2,000 sat and returning 28,000 sat to Anna. These numbers illustrate the mechanism, not a recommended current fee. Before signing, Anna checks the address, the recipient’s amount and the new total fee. The wallet must be able to sign the required inputs; a hardware wallet may need to be connected again. The replacement has a new txid, its transaction identifier, so the recipient may need a new tracking link. Using the fee-bump function is different from making an independent second payment with other UTXOs: both independent payments could confirm, paying twice. [1] [2] [12]
A wallet can show an incoming payment before its first confirmation. This is called zero-conf: the payment has been observed but is not in a block yet. Another version may get confirmed first and the displayed incoming payment can disappear. An ‘RBF disabled’ label therefore does not prove that a payment is secure. When handing over goods, accepting zero-conf is a business risk decision. Once a transaction is included in a block, RBF cannot rewrite it; a possible chain reorganization is a separate risk, which is why larger payments may call for more confirmations. [1]
RBF itself does not require the original recipient to stay the same. A replacement can raise the fee while paying the same person, or send the funds elsewhere. Both versions try to spend the same UTXO, making them conflicting attempts, technically a Double Spend; that term alone does not tell you whether fraud is involved. An attacker cannot simply sign someone else’s payment, however: the replacement must still meet the spending conditions, including the required signatures. If a wallet offers to ‘cancel’ by replacing the payment with one to yourself, that is an attempt to beat the original transaction, not a guaranteed reversal. [1]
RBF changes the pending transaction itself. Child Pays for Parent (CPFP) keeps the original transaction and creates a new transaction spending one of its outputs. To collect the new transaction’s fee, a miner must include the original as well, so their combined feerate matters. The new transaction is called the child and the original the parent. Whoever can spend the relevant output can create it, such as the payment’s recipient or the sender spending change. Wallet support, required signatures and transaction dependencies determine what is possible. CPFP does not replace the original payment and does not guarantee a confirmation time either. [2]
The Mempool is not one shared queue for all of Bitcoin. Each node keeps its own list and applies its own rules for accepting and forwarding pending transactions. RBF belongs to this local policy, not a consensus rule governing block validity. A miner can therefore select a valid conflicting transaction that another node did not previously keep. A Full Node then checks the entire block against Bitcoin’s rules; its earlier mempool preference does not determine the result. Acceptance of a replacement by one node is no promise of acceptance everywhere. [1] [6]
Two different numbers matter to a wallet user: the total cost and the rate offered for the transaction’s size. For a hypothetical size of 200 vB, 200 sat means 1 sat/vB; at the same size, 2,000 sat means 10 sat/vB. A virtual byte, vB, is a size unit derived from transaction weight. Rebuilding the transaction can change its size, so the wallet must recalculate the rate too. The total fee is an amount in satoshis; feerate is an amount per virtual byte in sat/vB. For a single replacement in Core 30, the fee must cover the sum of fees of all evicted transactions plus the cost determined by incrementalrelayfee for the replacement’s size. Its feerate must exceed those of directly conflicting transactions. A higher feerate alone or simply adding satoshis is insufficient; Core 30 defaults incrementalrelayfee to 0.1 sat/vB, but node settings may differ. [2] [9]
Another pending payment may already depend on the first one: someone is spending an output of the first, still-unconfirmed transaction. Such follow-up transactions are called descendants. Removing their parent also makes them unusable in the mempool, so the node must consider the whole affected group. Replacing a parent can evict descendants spending its outputs from the mempool as well. The comparison therefore need not involve just two transactions. For a single replacement, Core 30 limits the sum of descendant counts of directly conflicting transactions, including themselves, to 100; this calculation may count shared descendants more than once. Package fees and relationships can therefore affect replacement success. [2]
A node also needs to stop someone overwhelming it with repeated replacement calculations. This is protection against DoS, an attack on service availability. A UTXO is an unspent output from an earlier transaction; an input of the new transaction refers to it. The following rules describe Bitcoin Core 30 specifically, not an unchanging law of Bitcoin. Bitcoin Core 30 policy for a single replacement transaction also restricts new unconfirmed inputs and the number of evicted transactions. A replacement must meet local rules on accepted transaction forms (standardness), relay rules and validity rules, not merely spend the same UTXO. These limits protect processing capacity, memory and bandwidth; package replacement rules must be considered separately for the node version. Core 31 changed this policy with Cluster Mempool, which considers connected pending transactions in groups. A replacement must improve the feerate diagram, which compares cumulative fees with the space progressively occupied. Other conditions still apply, including a sufficient total fee and the additional fee for relaying the replacement. Do not automatically apply the Core 30 limits above to newer versions; check your node’s rules. [2] [13]
Why do some wallets still show an RBF switch? Nodes using the original opt-in RBF policy required an advance signal permitting replacement. Bitcoin Core 24 made full-RBF configurable without that condition, Core 28 enabled it by default and Core 29 removed the mempoolfullrbf switch. The BIP125 details below describe the original signaling scheme, not a universal rule for every node today. BIP125 describes an explicit opt-in signal when at least one input has an nSequence value below 0xfffffffe, and also inheritance of signaling from an unconfirmed ancestor. This is historical policy, not a consensus requirement. Full-RBF allows a replacement to be evaluated without that signal; its absence does not guarantee a payment cannot be replaced. [1] [3] [4] [5] [6]
This section is for operating your own node. RPCs are commands used to query or control software; you do not need to know them to use an increase-fee button. The getmempoolentry RPC shows a transaction’s state if it is in that node’s mempool; testmempoolaccept tests one signed candidate replacement against the current mempool and rules of your node without broadcasting it. The result promises neither acceptance by other nodes nor mining. Core 28 enabled full-RBF through the default mempoolfullrbf setting; Core 29 removed that option. The getmempoolinfo RPC reports fee parameters, but its fullrbf field is deprecated in Core 30; always check the version and actual configuration. [5] [6] [7] [8] [10] [11]
For the clearest picture, read this entry together with Transaction Fees, Mempool, CPFP (Child Pays for Parent), Double-spend, Confirmation, Fee Rate. The reverse links also lead from Change Address, Confirmation, Double-spend, Fee Rate.