<p>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.</p>
<p>That's the reason why the carve-out can only be used for two-parties contract, and <a href="https://bitcoin.stackexchange.com/a/98849/101498">why Lightning makes sure no transaction has two outputs directly spendable by the same party</a>: it can be exhausted.</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>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.</p>

CC BY-SA 4.0
2023-12-10T10:13:59.960Z
2023-12-10T10:13:59.960Z
Antoine Poinsot
<p>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.</p>
<p>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 <a href="https://github.com/bitcoin/bitcoin/blob/d5e5810bd36f6e899d64a57e9264729b27a9c3f8/src/policy/policy.h#L73-L78" rel="nofollow noreferrer">10'000 vB</a>. 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.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-12-11T18:58:55.460Z
Nice answer, thanks. Have 2 questions. 1) Descendant set includes the transaction itself, so the size of the transaction itself + its descendants cannot exceed 100'000 vB? 2) "`...and may not exceed 10'000 vB`", isn't it 1'000 vB, not 10'000 vB?
LeaBit
CC BY-SA 4.0
2023-12-11T19:01:51.817Z
1) Yes, 2) the `EXTRA_DESCENDANT_TX_SIZE_LIMIT` is 10'000: https://github.com/bitcoin/bitcoin/blob/d5e5810bd36f6e899d64a57e9264729b27a9c3f8/src/policy/policy.h#L73-L78
Murch
CC BY-SA 4.0
2023-12-11T19:06:52.503Z
Was it 10,000 from the beginning? I ask because the [proposal](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html) mentions 1,000. Also, in [bitcoin optech](https://bitcoinops.org/en/topics/transaction-pinning/) it says in global 101'000, not 110'000.
LeaBit
CC BY-SA 4.0
2023-12-11T19:18:47.433Z
It was 10'000 vB in the [original PR](https://github.com/TheBlueMatt/bitcoin/blob/50cede3f5a4d4fbfbb7c420b94e661a6a159bced/src/validation.h#L71), and appears to be 10'000 in the current codebase. Perhaps you should file an issue in the Optech repository to request clarification.
Murch
CC BY-SA 4.0
2023-12-11T19:25:50.127Z
Thanks for the clarification.
LeaBit
CC BY-SA 4.0
2023-12-11T19:30:04.597Z
Or you could ask about the discrepancy as a new question here on BSE, I suppose
Murch
CC BY-SA 4.0
2023-12-11T17:14:40.680Z
2023-12-11T19:03:09.413Z
2023-12-11T19:03:09.413Z
Murch
<p>Bitcoin node has 2 rules that limit the use of CPFP:</p>
<ol>
<li>number of descendants (including transaction itself) can't be more than 25</li>
<li>total size of transaction and all its descendants can't be more than 100 000 vbytes</li>
</ol>
<p>However, with <strong>CPFP carve out</strong> rule previously mentioned numbers can be exceeded. <strong>CPFP carve out</strong> says that one additional transaction up to 1000 vbytes can &quot;added&quot; to unconfirmed transaction (that does not have unconfirmed ancestors) even thought it will exceed 25 number of descendants and 100 000 vbytes limit.</p>
<p>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?</p>
<p>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?</p>
<p>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?</p>

<bitcoin-core><lightning-network><child-pays-for-parent><pinning-attack>
How does Bitcoin core knows whether CPFP carve out rule is already used?
LeaBit
# How does Bitcoin core knows whether CPFP carve out rule is already used?

(Asked by: username_0 on 2023-12-10)

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?

**Tags:** bitcoin-core, lightning-network, child-pays-for-parent, pinning-attack


---

## 2 answers

### Answer by username_1 on 2023-12-10. Score: 3 | Accepted answer

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](https://bitcoin.stackexchange.com/a/98849/101498): 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 by username_2 on 2023-12-11. Score: 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](https://github.com/bitcoin/bitcoin/blob/d5e5810bd36f6e899d64a57e9264729b27a9c3f8/src/policy/policy.h#L73-L78). 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.

> **Comments:**
> **username_0**: Nice answer, thanks. Have 2 questions. 1) Descendant set includes the transaction itself, so the size of the transaction itself + its descendants cannot exceed 100'000 vB? 2) "`...and may not exceed 10'000 vB`", isn't it 1'000 vB, not 10'000 vB?  
> **username_2**: 1) Yes, 2) the `EXTRA_DESCENDANT_TX_SIZE_LIMIT` is 10'000: https://github.com/bitcoin/bitcoin/blob/d5e5810bd36f6e899d64a57e9264729b27a9c3f8/src/policy/policy.h#L73-L78  
> **username_0**: Was it 10,000 from the beginning? I ask because the [proposal](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html) mentions 1,000. Also, in [bitcoin optech](https://bitcoinops.org/en/topics/transaction-pinning/) it says in global 101'000, not 110'000.  
> **username_2**: It was 10'000 vB in the [original PR](https://github.com/TheBlueMatt/bitcoin/blob/50cede3f5a4d4fbfbb7c420b94e661a6a159bced/src/validation.h#L71), and appears to be 10'000 in the current codebase. Perhaps you should file an issue in the Optech repository to request clarification.  
> **username_0**: Thanks for the clarification.  
> **username_2**: Or you could ask about the discrepancy as a new question here on BSE, I suppose  

---

