# How is the total number of transactions that will be replaced calculated in this case?

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!

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).

• 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
Dec 7, 2023 at 18:35
• 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. Dec 7, 2023 at 18:36
• @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. Dec 7, 2023 at 18:43
• According to BIP125, 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"). Dec 7, 2023 at 18:57
• 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
Dec 7, 2023 at 19:33

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.

• Thanks for this nice explanation!! Dec 7, 2023 at 19:09