BIP-125 and maximum total of 100 transactions to be replaced

[citb0in]

The policy BIP-125 specifies two ways a transaction can signal that it is replaceable.

Explicit signaling: A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).
Inherited signaling: Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed.
Implementation Details
The initial implementation expected in Bitcoin Core 0.12.0 uses the following rules:

One or more transactions currently in the mempool (original transactions) will be replaced by a new transaction (replacement transaction) that spends one or more of the same inputs if,

The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section.
The replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions. (An unconfirmed input spends an output from a currently-unconfirmed transaction.)
The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.
The replacement transaction must also pay for its own bandwidth at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.
The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions.
The initial implementation may be seen in Bitcoin Core PR#6871 and specifically the master branch commits from 5891f870d68d90408aa5ce5b597fb574f2d2cbca to 16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).

I am not sure if I have understood this correctly. Can someone from the devs explain this to me in more detail? How was this implemented in the current bitcoin core versions? Does this mean that you can replace a transaction at most 100x?

Is this related to this maxDescendantsToVisit value or is this something completely different and not in the context of BIP-125?

src/main.cpp:

Code:

[...]
const int maxDescendantsToVisit = 100;
[...]

I wasn't able to find this directive in the /src folder of Bitcoin Core. Any insight to this much appreciated. What's the limit and how does eviction works? Thank you in advance.

[ranochigo]

The number of times your transaction is replaced is not tracked and cannot be accurately tracked. The descendants of a transaction would be the transactions created from the UTXO of previous transactions.

The commit in question is located here: https://github.com/bitcoin/bitcoin/pull/6871/commits/73d904009dc25ddfe5d6c4a91a13673c8f5cf87a. As noted, it can be an overestimate because it doesn't remove derived duplicates. Consistent with the criteria described, we consider the descendants of a transaction while including overlaps in the output. For example:

A -> B   B -> C  C.a -> E, you'll have 5 descendants from A. A -> B, A-> C, B -> C, C.a -> E, C.b -> E, or by set notation and simplifying (A, B, C) as individual transactions,
   -> C               C.b

A = {A, B, C}, B = {B, C}

P.s. Bitcoin Core's descendant limit was set to 25 by default. This doesn't invalidate the rule as stated.

[citb0in]

So there is absolutely no way of limiting transaction replacements, but you could do a million replacements as long as all requirements are met? Or are there any functions or possibilities to limit transaction substitutions in any way, completely independent of RBF signaling.

[hosseinimr93]

So there is absolutely no way of limiting transaction replacements, but you could do a million replacements as long as all requirements are met?

If by million replacements, you mean replacing a transaction million times, yes. There is no limit for that.
The limit we have is that the total number of transactions that should be removed from the mempool after replacement must not be bigger than 100.

[ranochigo]

So there is absolutely no way of limiting transaction replacements, but you could do a million replacements as long as all requirements are met? Or are there any functions or possibilities to limit transaction substitutions in any way, completely independent of RBF signaling.

You can possibly have a counter for it, but it is not implemented because it is a waste of space and it is accurate. There is no reason why you would need to limit the RBF counts, other than the DoS possibility, but it is handled by the (rather friendly) descendant limit and the minimum fee increment.

If by million replacements, you mean replacing a transaction million times, yes. There is no limit for that.
The limit we have is that the total number of transactions that should be removed from the mempool after replacement must not be bigger than 100.

The general limit for the maximum descendants of 25 for transactions would limit your ability to do so as well. Because of the double counting as stated, you probably can have less than 100 unique descendants for the limit to be reached as well.

[hosseinimr93]

The general limit for the maximum descendants of 25 for transactions would limit your ability to do so as well. Because of the double counting as stated, you probably can have less than 100 unique descendants for the limit to be reached as well.

But the 100 transactions don't have to be in a single chain.

I can make a transaction with 99 outputs and then spend those 99 outputs in separate transactions.
If I replace the transaction including 99 outputs with RBF, nodes would remove 100 transactions from their mempool.

[ranochigo]

The general limit for the maximum descendants of 25 for transactions would limit your ability to do so as well. Because of the double counting as stated, you probably can have less than 100 unique descendants for the limit to be reached as well.

But the 100 transactions don't have to be in a single chain.

I can make a transaction with 99 outputs and then spend those 99 outputs in separate transactions.
If I replace the transaction including 99 outputs with RBF, nodes would remove 100 transactions from their mempool.

Correct, the example that you've given is correct with exception in certain cases. Reference client's mempool has a maximum descendant limit of 25, and from what I understand (and previously experimented), the mempool limit also applies when the any of the ancestors transactions has reached the 25 descendant limit.

Other than that, because of the way the descendants are counted, it may be possible for transactions to be double counted as well. This would be the case with my example in the first post.

[citb0in]

So if I summarize your answers, it is possible for someone with knowledge of the private key to replace and change a transfer of a UTXO at any time and indefinitely (including inputs and outputs and the amounts to be transferred), provided that the UTXO is unconfirmed in the current one Blockchain.

[ranochigo]

So if I summarize your answers, it is possible for someone with knowledge of the private key to replace and change a transfer of a UTXO at any time and indefinitely (including inputs and outputs and the amounts to be transferred), provided that the UTXO is unconfirmed in the current one Blockchain.

Yes, provided that it is not included in the block. These transactions are not considered as final until they are included in a block.

RBF is purely implemented by the node's mempool policy and it comes with the reference client. As such, it would be dependent on the node's mempool policy to either "replace" or drop the transaction entirely. For the reference client which implements BIP125, the behavior of the client is outlined as per the proposal provided that no further modifications are done to it.