How does Bitcoin core knows whether CPFP carve out rule is already used?

Question

Bitcoin node has 2 rules that limit the use of CPFP:

1. number of descendants (including transaction itself) can't be more than 25
2. total size of transaction and all its descendants can't be more than 100 000 vbytes

However, with CPFP carve out rule previously mentioned numbers can be exceeded. CPFP carve out says that one additional transaction up to 1000 vbytes can "added" to unconfirmed transaction (that does not have unconfirmed ancestors) even thought it will exceed 25 number of descendants and 100 000 vbytes limit.

I am interested in how is CPFP carve out rule checked? In other words, how does a Bitcoin node prevent a given rule from being used twice or more?

For example, assume a transaction with 3 outputs where one of them already made 25 descendant count and 100 000 vbytes. If we add a new transaction (200 vbytes) directly to one of two remaining outputs, what prevents us from adding another transaction (size up to 800 bytes) to that remaining third output?

Is there maybe some indicator for CPFP carve out which say whether it is used or not (although I'm not sure how it could be implemented since you can't know when CPFC carve out happens)? Does the given rule can be activated only when the transaction has exactly 2 outputs since then the CPFP carve out rule cannot be used on more than one outputs? Or is a third way used?

Answer 1

You can only use the carve-out rule once since it creates a 26th descendant. The CPFP carve out rule can only be used when a transaction has 25 descendants (including itself), not more.

That's the reason why the carve-out can only be used for two-parties contract, and why Lightning makes sure no transaction has two outputs directly spendable by the same party: it can be exhausted.

For example, assume a transaction with 3 outputs where one of them already made 25 descendant count and 100 000 vbytes. If we add a new transaction (200 vbytes) directly to one of two remaining outputs, what prevents us from adding another transaction (size up to 800 bytes) to that remaining third output?

From your example it seems your confusion stems from thinking in outputs, whereas the descendant limit is per transaction. In your example, let's say this transaction has no ancestor and from the first output 24 transactions are chain. The 25-descendants limit is hit for this transaction. However the carve-out allows one to chain a single, small, additional transaction on the second output. The transaction now has 26 descendants (accounting for itself). The carve-out rule can't be used to chain one more transaction using the third output.

Answer 2

Nodes generally will only permit a new transaction into their mempool if it does not increase an existing transaction’s descendant set count past 25 and doesn’t make a descendant set exceed 100'000 vB in sum (in both cases the transaction itself is included in its descendant set). This check will be performed for each ancestor transactions of the transaction under consideration. This rule leads to a pinning attack, where one recipient of a transaction can chain 24 additional transactions (or one very large transactions) off of their output, thus preventing other recipients of that transaction from CPFPing the transaction.

The CPFP carve-out permits addition of a 25th descendant (i.e. a descendant count of 26) under the conditions that this new transaction must have only a single unconfirmed ancestor transaction and may not exceed 10'000 vB. Since the carve-out transaction can only have a single unconfirmed ancestor, it necessarily attaches to the first transaction in a tree of unconfirmed transactions. This carve-out mitigates the above described pinning attack by guaranteeing that a transaction can be attached to at least one other output of the original transaction, even when the descendant limit has already been exhausted by another recipient. Given a transaction in which each recipient at most controls one output, this guarantees that at least two recipients can attach child transactions.

We do not need to explicitly track whether the carve-out was already used, because it is obvious from the descendant count of the parent. The carve-out cannot be used twice, because that would raise the descendant count to 27, or the descendant set size is already in excess of 100'000 vB.

Other than one might expect, the transaction making use of the CPFP carve-out is not required to pay a higher feerate than the parent.