<blockquote>
<p>One of the rule for the transaction replacement (RBF) is that the number of original transactions (directly conflicting transactions + their descendants) can't exceed 100.</p>
</blockquote>
<p>This is a non-equivalent restatement of the implementation description. Your (reasonable) misunderstanding appears to be that you expect every replaced transaction to be collected and then this deduplicated set to be counted.</p>
<p>Instead, the rule is that &quot;the sum of the directly conflicting transaction’s descendant counts cannot exceed 100&quot;. Specifically, this prescribes a different behavior, namely only iterating over the direct conflicts, reading their &quot;descendant count&quot; fields, and summing those up. This may overestimate the count of replaced transactions but does <strong>not</strong> require actually enumerating all descendants in order to deduplicate them.</p>
<p>So, in your example, the direct conflicts are A and B. The descendant count of A is 3 (<code>{A, B, C}</code>), and the descendant count of B is 2 (<code>{B, C}</code>), therefore in the context of the check, they would count as 5 towards the 100 limit, even though the descendant sets overlap.</p>

CC BY-SA 4.0
2023-12-07T19:09:07.157Z
Thanks for this nice explanation!!
LeaBit
CC BY-SA 4.0
2023-12-07T18:40:01.530Z
2023-12-07T18:47:19.910Z
2023-12-07T18:47:19.910Z
Murch
<p>The rule implemented in Bitcoin Core today (as of version 26.0) is that the sum of the number of descendants, counted over all conflicted transactions, cannot exceed 100.</p>
<p>In your example, that number is 5. The descendant set of A is {A,B,C}. The descendant set of B is {B,C}. If R conflicts with A and B, then those set counts are added up, and 3+2=5.</p>
<p>Note that this overestimate <em>only</em> matters for determining the maximum conflict set size. Once the number is calculated and verified to not exceed 100, the exact (properly deduplicated) conflict set is calculated (set {A,B,C} in your example) and used for further checks (including fee-based conditions).</p>

CC BY-SA 4.0
2023-12-07T18:34:14.707Z
So in each descendant set, each transaction can appear only once, and the descendant set is calculated for each directly conflicting transaction. The sum of the sizes of the descendant sets must not exceed 100. Did I understand correctly?
LeaBit
CC BY-SA 4.0
2023-12-07T18:35:34.910Z
You look up each conflicting transaction’s mempool entry. You read the "descendant count" field from that entry. You sum those up across the direct conflicts of your replacement. That sum cannot be greater than 100. Basically, it is a potential overestimate, but that way you don’t have to look up all of the descendants and deduplicate.
Murch
CC BY-SA 4.0
2023-12-07T18:36:13.997Z
Yes, descendants are calculated correctly (i.e., deduplicated) for transactions already in the mempool. They're just not re-deduplicated in the construction of the conflict set size.
Pieter Wuille
CC BY-SA 4.0
2023-12-07T18:41:18.030Z
@Murch Thank you, now I understand why there is a potential overestimate. Just one more question. When it comes to the rule for fee calculation (the rule that says that the fee of the replacement transaction must be greater than the total fee of all transactions it replaces - direct conflicting transactions + their descendants), is each transaction in that case calculated only once or some overlaps may occur as in this case?
LeaBit
CC BY-SA 4.0
2023-12-07T18:42:18.603Z
@PieterWuille Thanks. Are such overlaps possible when it comes to fee calculation?
LeaBit
CC BY-SA 4.0
2023-12-07T18:43:51.320Z
@LeaBit No, the actual conflict set is calculated exactly (and properly deduplicated) after counting its size, and further analysis is done using that exact conflict set. The "sum of descendant set sizes of conflicts cannot exceed 100" is just a quick check before actually constructing the set, to make sure it won't grow too big.
Pieter Wuille
CC BY-SA 4.0
2023-12-07T18:50:39.253Z
@PieterWuille So that check to see if it exceeds 100 is just a quick check based on the descendant fields of each direct conflicting transaction (as Murch said). It must not exceed 100, although overlaps and overestimation may occur. In that case, the conflicting sets are {A, B, C} and {B, C}, and the sum is 5. However, when it comes to further checks, then the real conflicting set does not have any duplicates, so it is actually {A, B, C}. Further checks are being made on this conflicting set, including the calculation of the correct fee. Did I understand correctly?
LeaBit
CC BY-SA 4.0
2023-12-07T18:51:32.527Z
@LeaBit That is correct.
Pieter Wuille
CC BY-SA 4.0
2023-12-07T18:55:12.060Z
@PieterWuille And just one more question. It only matters that direct conflicting transactions signal replaceability (some nSequence smaller than 0xffffffff-1). If one of the direct conflicting transactions included in the replacement does not signal replaceability, replacement will not occur. Descendant transactions do not have to signal replaceability (all nSequence can be 0xffffffff), they will be replaced if one of their ancestors is replaced?
LeaBit
CC BY-SA 4.0
2023-12-07T18:57:23.050Z
According to [BIP125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki), transactions are to be considered replaceable if they either explicitly signal replacement, or if they descend from an unconfirmed transaction that does (look for "inherited signalling").
Pieter Wuille
CC BY-SA 4.0
2023-12-07T18:59:50.757Z
I am asking because [here](https://bitcoin.stackexchange.com/questions/88813/is-inherited-replace-by-fee-signaling-implemented-as-described-in-bip125) they said that the inherited signalling is not implemented in Bitcoin Core.
LeaBit
CC BY-SA 4.0
2023-12-07T19:01:12.837Z
That's possible, I'm not familiar with the details there.
Pieter Wuille
CC BY-SA 4.0
2023-12-07T19:33:48.543Z
I believe the implementation bug referenced there is that an attempt to replace a non-replaceable transaction descending from a replaceable transaction would fail, even though the descendant transaction would be supposed to inherit replaceability. It is possible to replace a descendant by conflicting with its ancestor, regardless of whether the descendant signals replaceability or finality, though.
Murch
CC BY-SA 4.0
2023-12-07T20:56:17.277Z
@Murch Thanks..
LeaBit
CC BY-SA 4.0
2023-12-07T18:27:08.130Z
2023-12-07T18:53:07.643Z
2023-12-07T18:53:07.643Z
Pieter Wuille
<p>One of the rule for the transaction replacement (RBF) is that the number of original transactions (directly conflicting transactions + their descendants) can't exceed 100. However, in presence of overlapping transactions, &quot;wrong counting&quot; of transactions may occur.</p>
<p>For example, consider situation where transactions <strong>A</strong>, <strong>B</strong> and <strong>C</strong> are ancestors of transaction <strong>D</strong>. If replacement transaction <strong>R</strong> replaces <strong>A</strong>, <strong>B</strong> and <strong>C</strong>, then, according to the rule/condition above, they count as 6 and not as 4.</p>
<pre><code>A  B  C
\  |  /
 \ | /
   D
</code></pre>
<p>What interests me is how transactions are calculated in the following example. In the example, <strong>A</strong> and <strong>B</strong> are ancestors of <strong>C</strong>, but <strong>A</strong> is also an ancestor of <strong>B</strong>. If <strong>R</strong> replaces <strong>A</strong> and <strong>B</strong>, how is the number of transactions calculated in this case?</p>
<pre><code>   A  
 / |
 B |
 \ |
   C
</code></pre>
<p><strong>I would say the number of transactions is 6.</strong></p>
<p>I came to that conclusion (number) in the following way:</p>
<pre><code>1. start from A; count A (1)  
  1.1. from A go to B; count B (2)    
    1.1.1 from B go to C; count C (3)  
  1.2. from A go to C; count C (4)  
2. start from B; count B (5)  
  2.1. from B go to C; count C (6)  
</code></pre>
<p>Am I right?</p>
<p>Thanks!</p>

<replace-by-fee>
How is the total number of transactions that will be replaced calculated in this case?
LeaBit
# How is the total number of transactions that will be replaced calculated in this case?

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

One of the rule for the transaction replacement (RBF) is that the number of original transactions (directly conflicting transactions + their descendants) can't exceed 100. However, in presence of overlapping transactions, "wrong counting" of transactions may occur.

For example, consider situation where transactions **A**, **B** and **C** are ancestors of transaction **D**. If replacement transaction **R** replaces **A**, **B** and **C**, then, according to the rule/condition above, they count as 6 and not as 4.

```
A  B  C
\  |  /
 \ | /
   D

```

What interests me is how transactions are calculated in the following example. In the example, **A** and **B** are ancestors of **C**, but **A** is also an ancestor of **B**. If **R** replaces **A** and **B**, how is the number of transactions calculated in this case?

```
   A  
 / |
 B |
 \ |
   C

```

**I would say the number of transactions is 6.**

I came to that conclusion (number) in the following way:

```
1. start from A; count A (1)  
  1.1. from A go to B; count B (2)    
    1.1.1 from B go to C; count C (3)  
  1.2. from A go to C; count C (4)  
2. start from B; count B (5)  
  2.1. from B go to C; count C (6)  

```

Am I right?

Thanks!

**Tags:** replace-by-fee


---

## 2 answers

### Answer by username_2 on 2023-12-07. Score: 6 | Accepted answer

The rule implemented in Bitcoin Core today (as of version 26.0) is that the sum of the number of descendants, counted over all conflicted transactions, cannot exceed 100.

In your example, that number is 5. The descendant set of A is {A,B,C}. The descendant set of B is {B,C}. If R conflicts with A and B, then those set counts are added up, and 3+2=5.

Note that this overestimate *only* matters for determining the maximum conflict set size. Once the number is calculated and verified to not exceed 100, the exact (properly deduplicated) conflict set is calculated (set {A,B,C} in your example) and used for further checks (including fee-based conditions).

> **Comments:**
> **username_0**: So in each descendant set, each transaction can appear only once, and the descendant set is calculated for each directly conflicting transaction. The sum of the sizes of the descendant sets must not exceed 100. Did I understand correctly?  
> **username_1**: You look up each conflicting transaction’s mempool entry. You read the "descendant count" field from that entry. You sum those up across the direct conflicts of your replacement. That sum cannot be greater than 100. Basically, it is a potential overestimate, but that way you don’t have to look up all of the descendants and deduplicate.  
> **username_2**: Yes, descendants are calculated correctly (i.e., deduplicated) for transactions already in the mempool. They're just not re-deduplicated in the construction of the conflict set size.  
> **username_0**: @username_1 Thank you, now I understand why there is a potential overestimate. Just one more question. When it comes to the rule for fee calculation (the rule that says that the fee of the replacement transaction must be greater than the total fee of all transactions it replaces - direct conflicting transactions + their descendants), is each transaction in that case calculated only once or some overlaps may occur as in this case?  
> **username_0**: @username_2 Thanks. Are such overlaps possible when it comes to fee calculation?  
> **username_2**: @username_0 No, the actual conflict set is calculated exactly (and properly deduplicated) after counting its size, and further analysis is done using that exact conflict set. The "sum of descendant set sizes of conflicts cannot exceed 100" is just a quick check before actually constructing the set, to make sure it won't grow too big.  
> **username_0**: @username_2 So that check to see if it exceeds 100 is just a quick check based on the descendant fields of each direct conflicting transaction (as username_1 said). It must not exceed 100, although overlaps and overestimation may occur. In that case, the conflicting sets are {A, B, C} and {B, C}, and the sum is 5. However, when it comes to further checks, then the real conflicting set does not have any duplicates, so it is actually {A, B, C}. Further checks are being made on this conflicting set, including the calculation of the correct fee. Did I understand correctly?  
> **username_2**: @username_0 That is correct.  
> **username_0**: @username_2 And just one more question. It only matters that direct conflicting transactions signal replaceability (some nSequence smaller than 0xffffffff-1). If one of the direct conflicting transactions included in the replacement does not signal replaceability, replacement will not occur. Descendant transactions do not have to signal replaceability (all nSequence can be 0xffffffff), they will be replaced if one of their ancestors is replaced?  
> **username_2**: According to [BIP125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki), transactions are to be considered replaceable if they either explicitly signal replacement, or if they descend from an unconfirmed transaction that does (look for "inherited signalling").  
> **username_0**: I am asking because [here](https://bitcoin.stackexchange.com/questions/88813/is-inherited-replace-by-fee-signaling-implemented-as-described-in-bip125) they said that the inherited signalling is not implemented in Bitcoin Core.  
> **username_2**: That's possible, I'm not familiar with the details there.  
> **username_1**: I believe the implementation bug referenced there is that an attempt to replace a non-replaceable transaction descending from a replaceable transaction would fail, even though the descendant transaction would be supposed to inherit replaceability. It is possible to replace a descendant by conflicting with its ancestor, regardless of whether the descendant signals replaceability or finality, though.  
> **username_0**: @username_1 Thanks..  

---

### Answer by username_1 on 2023-12-07. Score: 5

> One of the rule for the transaction replacement (RBF) is that the number of original transactions (directly conflicting transactions + their descendants) can't exceed 100.

This is a non-equivalent restatement of the implementation description. Your (reasonable) misunderstanding appears to be that you expect every replaced transaction to be collected and then this deduplicated set to be counted.

Instead, the rule is that "the sum of the directly conflicting transaction’s descendant counts cannot exceed 100". Specifically, this prescribes a different behavior, namely only iterating over the direct conflicts, reading their "descendant count" fields, and summing those up. This may overestimate the count of replaced transactions but does **not** require actually enumerating all descendants in order to deduplicate them.

So, in your example, the direct conflicts are A and B. The descendant count of A is 3 (`{A, B, C}`), and the descendant count of B is 2 (`{B, C}`), therefore in the context of the check, they would count as 5 towards the 100 limit, even though the descendant sets overlap.

> **Comments:**
> **username_0**: Thanks for this nice explanation!!  

---

