Min suggested RBF bump fee not enough for BIP125 rule4

[nc50lc]

From: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

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.

Sometimes, Electrum's minimum suggested fee in the additional fee slider is lower than the default relay fee causing the server to reject the transaction if that value was used.

Bitcointalk report by user (ragnar dannesk gold): https://bitcointalk.org/index.php?topic=5155122.0

[SomberNight]

For the Qt GUI, the default suggested value should satisfy rule 4 since
d0a4366#diff-ab03512ed0ef54fb82da0ae481c462e4R3439.
(although the hardcoded +1 instead of using the relay fee is a bit ugly)

The kivy default in some cases will still not.

Note that e.g. rule 3 is practically impossible to check using a light wallet like Electrum (see e.g. RBF pinning).

[Coding-Enthusiast]

Note that e.g. rule 3 is practically impossible to check using a light wallet like Electrum (see e.g. RBF pinning).

3.The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.

Isn't the following possible:
Lets say the RBF transaction is R and it is spending A which is spending B. The wallet already has A (since it is the transaction it is spending!) so we know R's fee. To know how much A's fee was we need more information about B. Ore more precisely, all the inputs of transaction A.
There are two scenarios for B, it is either in the wallet (like being the "change" amount) in which case the wallet only has to check that to see how much fee it paid. Or it is not (like received from a third party), in which case it seems like the servers support getting a transaction with its ID, by fetching tx B from servers the wallet can now know the real amount and by deducting it from what it is spending, fee can be calculated.
This was assuming there is only 1 input, if there were more the wallet has to fetch more transactions from servers.

[SomberNight]

@Coding-Enthusiast You describe a scenario where B <- A <- R1, and the user wants to create an R2 that replaces R1. Note that A and B would not get replaced then.
Rule 3 is about the other direction; R1 has a few outputs, some of which are already spent by A1, A2, A3, ..., and these transactions in turn have a few outputs each, some of which are already spent by B1, B2, B3, ..., with up to 25 (?) depth of follow-up. Now the user wants to replace R1 with R2; and thus replacing all of An and Bn (etc).

it seems like the servers support getting a transaction with its ID, by fetching tx B from servers

Yes the servers support txid -> tx lookups, this is already what the client uses to populate its history.
But figuring out An and Bn would require not only txid lookups but subscriptions to corresponding scriptPubKeys (scripthashes) too and then going through that history etc. (Or maybe we could implement a new protocol method server-side that allows looking up the txid that spends a TXO)

In my view, this is not realistic for a light client to do. So currently we ignore the issue and optimistically assume only R1 is being replaced. If the fee set is too low as this assumption was false, the user can manually retry with a higher fee.