Child pays for parent

Miners do not pick transactions one at a time. Bitcoin Core has selected them by ancestor fee rate since version 0.13.0 in August 2016, so a generous child drags a stingy parent into the same block. That single design choice is what gives the receiver of a stuck payment a way to act, instead of waiting on a sender who may never answer.

How it works

Fee rate is a ratio, and child pays for parent works by improving the ratio of a group rather than of one transaction.

A miner filling a block wants the most satoshis per virtual byte it can get. When a transaction in the mempool depends on an unconfirmed parent, the mining code cannot take it alone, so it evaluates the whole ancestor set: the combined fees of parent and child divided by their combined size. If that number beats the competition, both go in. Bitcoin Core's mining selection has worked this way since 0.13.0, the release that replaced simple per transaction sorting with ancestor feerate sorting.

The arithmetic is worth doing once by hand. Take a parent of 141 virtual bytes paying 1 sat/vB, so 141 satoshis. You want the pair to reach 25 sat/vB. A one input, one output child spending that coin is about 111 virtual bytes, so the package is 252 virtual bytes and needs 6,300 satoshis in total. The parent already contributed 141, so the child has to carry 6,159, which is a fee rate of about 55 sat/vB on its own. The child always pays a premium, because it is buying block space for someone else's bytes as well as its own.

Two limits constrain this. A chain of unconfirmed transactions may not exceed 25 ancestors or descendants by default, and the total size of that family is capped at roughly 101 kilovbytes, so you cannot stack children indefinitely. And relay is not automatic: for years a child that lifted an under paying parent was itself rejected by nodes that had already dropped the parent, which is why Bitcoin Core 28.0 in October 2024 added opportunistic relay for one parent with one child, so the pair travels the network as a unit.

There is a nastier version of the same dependency. If someone else can attach a large, low fee child to a shared unconfirmed transaction, they can inflate the family size and make bumping it prohibitively expensive. That attack is called transaction pinning, and it is the reason Lightning and other contract protocols now use restricted transaction topologies rather than relying on plain fee bumping.

Why this matters when you buy bitcoin

Child pays for parent is the only fee fix available to a receiver, which makes it the tool for exchange withdrawals that stall.

The sequence goes like this. You withdraw from an exchange, the exchange batched your payment with fifty others at a fee rate it chose hours ago, fee pressure rises, and the batch sits unconfirmed. Replace-by-fee is useless to you here because the exchange signed those inputs. What you can do is spend the incoming coin, unconfirmed, to another address in your own wallet at a high fee rate. Miners now see a package worth mining, and both transactions confirm together.

Your wallet has to cooperate. Bitcoin Core, Sparrow and Electrum let you select an unconfirmed incoming coin and spend it; several mobile wallets hide unconfirmed balances entirely and give you nothing to click. If you plan to hold real money in self custody, check for this before you need it, not during a fee spike.

Two cautions. First, a child spends the exact coin you received, so the fee comes out of the money you just withdrew, and on a small withdrawal the cost can be a meaningful share of the amount. Second, the child creates a new coin at a new address, which links the two in the public record. If the withdrawal was part of a privacy conscious setup, bumping it this way is a trade you should make knowingly.

Rescuing a 0.02 BTC withdrawal stuck in a 4 sat/vB batch

Say an exchange sends you 0.02 BTC in a batch paying 4 sat/vB, and by morning nothing under 30 sat/vB is confirming. The batch is large, perhaps 1,500 virtual bytes, and it is not your job to pay for all of it. You only need the package containing your coin to look attractive.

Here is the catch that surprises people: the package a miner evaluates includes the entire parent, all 1,500 bytes of it, not just your share. Add a 111 byte child and the package is 1,611 virtual bytes, so reaching 30 sat/vB means finding 48,330 satoshis in total. The parent supplied 6,000 of that, so the child owes roughly 42,330 satoshis, which on a 0.02 BTC withdrawal is a real cost.

This is why child pays for parent is a rescue tool rather than a routine one, and why it works far better on a small parent, such as a payment sent directly to you by one person, than on a big exchange batch. Sometimes the honest answer is to wait: fee rates fall on most weekends, and a transaction sits in mempools for up to 14 days by default before nodes forget it.

Child pays for parent vs replace-by-fee

Both bump a fee, but they are used by opposite parties and leave different traces. Replacement rewrites the original transaction, requires the keys that signed its inputs, produces a new transaction id, and makes the first version vanish. Child pays for parent adds a new transaction on top, requires only the keys to an output you received, changes nothing about the parent, and leaves both on the chain permanently.

Replacement is cheaper when it is available, because you only pay for one transaction's bytes rather than two. Use it whenever the stuck payment came from your own wallet. Reach for the child when the stuck payment came from someone else.