Topic: [INFO - DISCUSSION] Child-Pays-For-Parent (CPFP) (Read 256 times)

If the parent pays 1 sat/vb, and the equally-sized child pays 10 sat/vb, then both as a whole pay the average, 5.5 sat/vb. The child has to take into account the parent's transaction size, and that's why CPFP might be expensive sometimes. If the parent is extremely large in size, as a big consolidation, then the child has to account that.

The formula is demonstrated in here by hosseinimr93:

Both transactions' fee rate is: f = (f_B*S_B + f_A*S_B)/(S_A + S_B).

You can try playing with it in this python program:

You can change PARENT_SIZE, CHILD_SIZE, PARENT_FEE_RATE, CHILD_FEE_RATE to your values.

Yes, we accept Bitcoin payments in several different projects and it happens regularly. Especially with larger amounts, then we are forced to use CPFP to get our money.

Question: could CPFP lead to exploitation, eg. not including transaction fees if they know the parent will be forced to pay those fees if they ever want to see their money?

I'm using this thread to share a new CPFP calculator I made:

https://bitaccelerate.com/cpfp-calculator/

It works in a different way. Unlike others, it does not require the child transaction to be published in advance and then increase its fee through RBF. It directly calculates what fee should be used for the child transaction.

The only requirement is that the child transaction has only one input and one output for the calculations to be accurate. This is not complicated to do, and the benefits are much easier to work with when using the tool.

The important thing isn't the absolute value of fees, but the "fee rate"-- the amount of fee per unit weight.

Ignoring dependencies and boundary conditions miners will make the maximum amount of income if they fill their blocks highest-fee-rate first until the block is full.

But dependencies matter: a block can't include a child transaction without including its parent.  Before CPFP the transaction selection code would just consider all transactions that could be included ordered by feerate and take the highest one until the block was full. And so it didn't matter how high a fee the child transaction paid, it wouldn't improve the parents poor position.  CPFP logic makes the mining code view the composition of the child and parent as a single virtual transaction with the total fees and total weight of its components, so its sorted by their total feerate (total_fee/total_weight).

It's important to keep this in mind because if the parent transaction has a high weight the fee paid by the child will need to be correspondingly large even if the child is low weight itself, if the child is to meaningfully improve the parent txn's mining priority.  This is particularly relevant because one way people end up underpaying is that they (or their software) misunderstood how fees works and set their fees without paying attention to the txn's weight then produced a high rate transaction that had a very low feerate even though the absolute value of fee would have been reasonable on a smaller transaction.

The boundary conditions also matter somewhat.  If the fee the child pays is only good enough to raise the combination's feerate to the very end of the block there may not be enough room there for both the parent and child.  Room for the child alone or the parent alone isn't enough.  The feerate needs to be high enough to raise the bundle of transactions early enough in the selection process so that there is room for the whole thing.

It wouldn't be economically rational for someone to prioritize the parent when they can't also fit the child that made it worthwhile (and would even open up the network to attacks).

yes, that's right - Carol doesn't appear at all in the whole thing. therefore the third name is superfluous in the introduction - very well done


could be done, but ultimately isn't that the same as it's mapped (that's honestly my understanding)?
the important thing is that the two fees (low & high) in total represent a relatively acceptable 'total' fee for the miners, which they can then confirm

i experienced this for example a few weeks ago with my bundesliga pools, that the participants sent off their stake with a very small fee. but since the whole pool lasts almost a year, the transaction would have enough time to be confirmed in the mempool (which then already happened)

Bob's sentiment towards Alice give me a bit chuckle, considering there are some people (on different board) who feel angry or feel helpless their incoming transaction never got confirmed.


There's small mistake in this image. You mentioned "Alice, Bob and Carol" while other image only mention Alice and Bob.


Description on 3rd panel could be improved. Miner ideally decide to include both transaction if average/median TX fee rate of both transaction is high/expensive enough. It's possible Alice's TX has big size/weight, while Bob's TX has small size/weight.

FWIW, miners don't ignore it--- it's there at the bottom of the ranking, waiting for a time when there aren't higher paying fees above it to get confirmed and it's not stuck, its waiting in the queue.  But if there is an influx of higher paying transactions it could wait arbitrarily long.

When a txn pays fees so low that miners ignore it then CPFP won't work because a they won't process the child at all unless the parent is in their mempool.  This becomes an issue when mempool size management increases the minimum feerate, since a parent that has been evicted due to size management then can't have children considered.

The illustration doesn't explain how it's considered.  Basically when building the mempool the miner effectively considers combined bundle like a separate transaction, and if that ranks higher in the mempool then it will include it.

This all becomes very complicated because a set of unconfirmed transaction can have a whole graph of unconfirmed children, multiple layers deep.  Just figuring out which order to consider a set of related transactions to get the best fees has exponential complexity so today miners use a very rough approximation that means that the improvement of a new child is sometimes ignored when its part of a complicated web of unconfirmed transactions.

The approximation handles the trivial example in the comic okay, but anything even somewhat more complicated like two siblings share the cost of one parent, isn't handled well at all.

I have done this method when I was running some group buys for Avalon gear a fee buyers sent tiny fees. I was able to fix them and combine all of it with a large fee to the seller cannon.io

today i would like to present you 4 slides about 'child-pays-for-parent'. this cpfp method can be used when the transaction is not accepted by the miner from the sender (due to a very small fee) and gets stuck in the mempool for a few hours or even days. how this works, you can see from the slides below

in addition, i have a few useful links on this topic for you:
https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/05_3_Funding_a_Transaction_with_CPFP.md

https://river.com/learn/terms/c/child-pays-for-parent-cpfp/

CPFP Calculator
https://cpfp.djbooth007.com/



https://twitter.com/BTCillustrated