What is incremental relay feerate?

Question

In an answer to my previous question, Murch used the term: incremental relay feerate.

On first, I thought that's the same as minimum relay fee (minRelayTxFee) - minimum feerate (sat/VB) that transaction must have in order to be included in mempool and relayed. My conclusion was based on the fact that BIP125 is using that term. Cite:

The replacement transaction must also pay for its own bandwidth at or above the rate set by the node's minimum relay fee setting.

However, the Bitcoin Core documentation related to RBF uses the term incremental relay feerate for the same condition. Cite:

The additional fees (difference between absolute fee paid by the replacement transaction and the sum paid by the original transactions) pays for the replacement transaction's bandwidth at or above the rate set by the node's incremental relay feerate.

Same documentation also mentioned:

The incremental relay feerate used to calculate the required additional fees is distinct from -minrelaytxfee...

So, my question is what is the incremental relay feerate and how is that tied (if it is) with the minimum relay fee?

Thanks!

Answer 1

minRelayTxFee was used for a few different notions of minimum feerates until these concepts got separated out in 2017. Although all these variables end in …Fee, they actually refer to a fee for one kilovbyte of transaction data, so they should be thought of as feerates.

• minRelayTxFee (default: 1 ṩ/vB) sets the minimum feerate required by the node to accept transactions to its mempool (and relay them)
• blockMinTxFee (default: 1 ṩ/vB) sets the minimum feerate for transactions to be selected into the block template
• incrementalRelayFee (default: 1 ṩ/vB) sets the feerate a replacement transaction has to at least pay on-top of paying at least as much fees absolutely as all transactions it replaces
• dustRelayFee (default: 3 ṩ/vB) sets the feerate used to calculate a node’s dust limits

Arguably, both minRelayTxFee and incrementalRelayFee enforce a cost for relaying transaction data on the network, except the former only applies to transactions replacing nothing, while the latter only applies to transactions replacing other transactions, so it has been questioned whether they should have been split at all. However, having separate values allows a user for example to set a minimum feerate for unconfirmed transactions they keep track of in the first place, while allowing replacements to follow the same rules as every other node.