Replace-by-fee and child-pays-for-parent

Replace-by-fee, specified in BIP 125, lets a sender broadcast a second transaction that spends the same inputs as the first and pays a higher fee. Nodes that implement the policy will accept the replacement and drop the original, provided the replacement meets certain conditions. The most important condition is that the new transaction must pay a fee that is meaningfully higher than the one it replaces, so that an attacker cannot spam the network with marginally improved versions of the same transaction.

BIP 125 sets out the rules a replacement must satisfy. It must conflict with the original by spending at least one of the same inputs. It must pay a higher absolute fee. It must also pay a higher fee rate, so that a larger replacement cannot dilute the rate by adding size. And it must not introduce new unconfirmed inputs beyond a limited allowance, which prevents a replacement from being used to pull in a chain of unrelated unconfirmed transactions. A node that applies the policy will reject a replacement that fails any of these tests.

The practical effect is that a sender who opted in can raise the fee on a stuck payment by constructing a replacement with a higher rate and broadcasting it. The recipient's address and amount are unchanged; only the fee and the change output typically differ. The original transaction disappears from mempools that accepted the replacement, and the new one takes its place in the queue.

The trade-off is signalling. A transaction must indicate that it is willing to be replaced, and wallets that do not set that signal produce transactions that nodes will not replace under the policy. This is why some payments cannot be bumped this way and must fall back on the other mechanism. The signalling requirement exists because replacement changes an important property of a transaction: a merchant who accepts an unconfirmed payment needs to know whether it can be withdrawn, and the signal tells them.

Child-pays-for-parent, usually shortened to CPFP, takes the opposite approach. Instead of replacing the stuck transaction, the sender — or the recipient — creates a new transaction that spends one of its outputs. That new transaction is the child, and the stuck one is the parent. The child pays a fee high enough that the combined fee of parent and child, divided by their combined size, is attractive to miners.

The mechanism works because miners select transactions in packages when a dependency exists. A child cannot be confirmed before its parent, so a miner that wants the child's generous fee must also include the parent. The child's fee effectively subsidises the parent's inclusion. This is why the technique is available even when the parent did not signal replaceability: nothing about the parent is modified, so no replacement policy applies.

CPFP is particularly useful to recipients. A merchant who is waiting on a payment that was sent with too low a fee can spend the incoming output in a child transaction and pay enough to pull both into a block, without needing the sender's cooperation or a replaceable parent. The cost falls on whoever creates the child, which is a meaningful difference from RBF, where the cost falls on the sender.

The trade-off is that CPFP requires an output to spend. A transaction that sends its entire value to a recipient with no change leaves the sender nothing to attach a child to, and the recipient must act instead. It also costs more in total, because the child adds its own size to the package that must be paid for. RBF replaces one transaction; CPFP adds a second.

The two mechanisms are not competitors so much as complements, and the choice is usually made by circumstance rather than preference. If the sender controls the transaction and it signalled replaceability, RBF is the cheaper and simpler route: one transaction replaces another, and the total size paid for does not grow. If the transaction did not signal replaceability, or if the party who wants it confirmed is the recipient rather than the sender, CPFP is the available route.

Both mechanisms share a limitation worth stating plainly. Neither can make a transaction confirm faster than the network is willing to confirm it; they can only raise the bid. If the fee market moves again after the bump, the same problem can recur, and a sender may need to bump more than once. The underlying constraint is unchanged: block space is scarce, and the only way to secure it is to pay what it currently costs.

The transaction fees page explains how the rate these mechanisms bid against is determined, and the transaction lifecycle page covers the signing and broadcast steps that both depend on.