4

RBF (Full RBF, Opt-in Full RBF, FSS-RBF) is applied to a transaction when one of its inputs "matches" one of the inputs in the replacement transaction.

However, what happens if the inputs of a replacement transaction "hit" the inputs of two (three or more) different transactions?

  1. Does the replacement transaction then replace all those "hit" transactions (transactions covered by replacement)?

  2. In order for replacement to occur, does the fee of replacement transaction have to be greater than the largest fee among all "covered" transactions, or perhaps the fee of replacement transaction must be greater than the sum of the fees of all "covered" transactions (or something else)?

  3. What would happen if the node works in Opt-in Full RBF mode and some of the transactions "included" in replacement do not accept the possibility of replacement (nSequence of all inputs is 0xffffffff)? I assume that the replacement then will not even occur and the replacement transaction will be just rejected.

LeaBit
  • 930
  • 1
  • 13

1 Answers1

6

For a replacement to be accepted into the mempool, it has to improve the mempool for miners. Therefore, it has to pay more fees than all the ousted transactions, additionally must pay for its own relay, and finally cannot oust too many transactions at once. Specifically:

  • If the node works in Opt-in Full RBF mode, the directly conflicting transactions must all signal replaceability, otherwise the replacement attempt fails.
  • The replacement transaction must pay at least as much fees as all replaced transactions (including the descendants of the directly conflicting transactions!) plus its own vsize times the node’s incremental relay feerate.
  • The replacement transaction does not spend any new unconfirmed inputs that were not already spent by one of the directly conflicting transactions.
  • The replacement transaction must pay a greater feerate than each directly conflicting transaction
  • The sum of the conflicting transactions' descendant counts doesn’t exceed 100.

You can read more about this topic for example in the policy documentation for Mempool Replacements for Bitcoin Core, and in glozow’s gist collecting her thoughts on RBF Improvements.

This answer omits FSS RBF, because I am not aware of any nodes implementing that policy on the network.

Murch
  • 75,206
  • 34
  • 186
  • 622
  • I have 2 small questions. 1) Isn't 5th condition redundant/unnecessary since with 3rd condition you already satisfy it? 2) In last, 6th, condition you only mentioned that the sum of all descendant of all confliction transactions can't exceed 100. However, you didn't mention the conflicting transactions themselves. In the material you linked they say The number of original transactions does not exceed 100. and by original transaction they denote conflict transaction + its descendants, so I would say that the sum of all confliction transaction + their descendants can't exceed 100? – LeaBit Dec 05 '23 at 23:04
  • I just saw that glozow's gist collection doesn't even mention the 5th condition, only the 3rd one. I guess then the answer to my first question is yes, i.e., it is redundant/unnecessary. – LeaBit Dec 05 '23 at 23:14
  • A transaction’s descendant count always includes the transaction itself. So, the sum of multiple transactions descendant count is potentially an overestimate, if they have overlapping descendants. What do you mean with "3rd and 5th condition"? My list has only five bulletpoints, but what you call "6th condition" appears to refer to the last bulletpoint. If you are referring to the rule about absolute fees and the rule about feerates, you should consider how things play out when transactions have differing sizes, i.e. what if the replacement is larger or smaller than the originals? – Murch Dec 06 '23 at 01:06
  • If two (three or more) directly conflicting transactions have some same/overlapping descendants, that descendants will be count as 2 (3 or more), not just as 1?
    • – LeaBit Dec 06 '23 at 01:48
  • Sorry, I did not denote it good. By this question I actually refer to 2nd and 4th bulletpoints (conditions). If I understood correctly, you want to say that even if the fee of the replacement transaction (calculated by rules from 2nd bulletproof) is bigger than the sum of all fees (directly conflicting transaction + their descendants), in case when replacement transaction is too big it can still have smaller feerate than some of directly conflicting transaction. So 5th bulletproof is also required.
    • – LeaBit Dec 06 '23 at 01:48
  • 1
    Yes, if the transactions A, B, and C are all ancestors of a transaction D, and R replaces A, B, and C, their sum of descendant counts would be 6 in context of this check. You got it right: If R is bigger than A+B+C+D, even if it pays a total higher fee than A+B+C+D + vsize(R)×incrementalRelayFeeRate, R's feerate may still be lower than one of A, B, or C—so both the absolute fee and the feerate criteria are needed to ensure that the mempool is getting more attractive to miners. – Murch Dec 06 '23 at 02:40
  • All clear, thanks – LeaBit Dec 06 '23 at 09:07