Question on CPFP and what happens if its violated.

[d4n13]

I know there is already a pull request on this, but seeing how many of the devs have there hands full answering BIP66 questions, I thought I might be this question to the community to hopefully set my mind right.

https://github.com/bitcoin/bitcoin/pull/1647 AKA "Child-Pays-For-Parent" (CPFP) effectively puts selection logic into the mining reference code to select dependent transactions together.  My question is this...

What happens if a child is accepted into a block and a parent is not?

To define terms,

Parent TXid = x.  It spends outputs that have already had 6+ confirmations.
Child TXid = y.  It spends outputs from Parent (x).

Parent and child enter the mempool together, but the child (txid:y) is paying high fees to try to get into the blockchain.  CPFP would make the two dependent transactions go in together, but what if a miner doesn't do that?

Would a block be valid if one of it's TXs (txid:y, aka "child") is spending outputs that are still in the mempool (txid:x, aka "parent")?

If the block was accepted then the "child" (txid:y), should it be reported as 0 confirms since it's dependent "parent" (txid:x) is still in the mempool?

references:
[PR1647] Child Pays For Parent
bitcoin-dev mailing list discussion on this subject

[1714784812]

1714784812

[1714784812]

1714784812

[1714784812]

1714784812

[1714784812]

1714784812

[dexX7]

Would a block be valid if one of it's TXs (txid:y, aka "child") is spending outputs that are still in the mempool (txid:x, aka "parent")?

No, this isn't possible. The parent must be processed/mined before the child can.

[achow101]

Would a block be valid if one of it's TXs (txid:y, aka "child") is spending outputs that are still in the mempool (txid:x, aka "parent")?

If the block was accepted then the "child" (txid:y), should it be reported as 0 confirms since it's dependent "parent" (txid:x) is still in the mempool?

The idea behind CPFP is that both transactions will go into the same block, thus confirming both transactions at the same time. A transaction cannot be considered confirmed nor added into a block unless its parent is also confirmed, be it previously or in the same block.

[d4n13]

The idea behind CPFP is that both transactions will go into the same block, thus confirming both transactions at the same time. A transaction cannot be considered confirmed nor added into a block unless its parent is also confirmed, be it previously or in the same block.

OK... With the fall out of the BIP66 SPV Miners who were not performing complete block verification, I got worried.  I was looking for codified consensus rules.  I see that the COrphan class does take dependencies into account in the HaveCoins check.  Also, HaveCoins is checking for mempool dependencies on incoming transactions from peers.

So I'm convinced that bitcoind is handling this for miners using getblocktemplate, but how many miners out there are using their own custom code?

So feeding my paranoia for a bit here, even if a miner running custom code did submit a new block with an unfunded tx (since the tx was in mempool), then hopefully the clients would reject it.  I searched through ConnectBlock, looking for where this was checked, like with HaveCoins, but eventually gave up.

So if mempool dependencies are already taken into account, then what does CPFP do?  Best I can tell it adjusts the priority weighting calculate child and parent together.  True?

Thx

[achow101]

So if mempool dependencies are already taken into account, then what does CPFP do?  Best I can tell it adjusts the priority weighting calculate child and parent together.  True?

I believe so. you can check the code from the pull request you reference above, it should relatively easy to figure out what CPFP does. To aid you in your search through the code, I recommend that you look at the docs for Bitcoin which can be found here: https://dev.visucore.com/bitcoin/doxygen/. These docs make it much easier to find things in the code.

[d4n13]

I believe so. you can check the code from the pull request you reference above, it should relatively easy to figure out what CPFP does. To aid you in your search through the code, I recommend that you look at the docs for Bitcoin which can be found here: https://dev.visucore.com/bitcoin/doxygen/. These docs make it much easier to find things in the code.

  The Holy Grail

I'm sure that link was likely in a README that I should have read, so extra thanks for pushing me along.

[arnuschky]

So feeding my paranoia for a bit here, even if a miner running custom code did submit a new block with an unfunded tx (since the tx was in mempool), then hopefully the clients would reject it.  I searched through ConnectBlock, looking for where this was checked, like with HaveCoins, but eventually gave up.

While I cannot provide the exact location of that check in the code, you can be certain that this is happening. Else all I would need to do to become filthy rich is to mine a single block that generates thousands of coins from nothing...