I think we can kinda ignore rule 3 at the moment, since we don't support merging multiple unconfirmed transactions, so this:

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

For us basically means that we should just pay at least the previous fee.

I agree on rule 4 though, the FeeAmount branch should check for *amount < details.fees + _something_.

And now that I think about it, it's kind of a chicken-and-egg problem: rule 4 says that we should pay at least the size of the new transaction, but at this point we don't know it yet. So even the part above where required_feerate is computed is wrong.. Not sure what's the best way to handle this, I've gotta think about it a bit more..

Coin selection algorithms should take min_absolute_fee and target_feerate into consideration on the get-go (and only succeed when both constraints are satisfied).

bdk_core will solve this issue, WIP here: LLFourn/bdk_core_staging#21

We discussed it in the call and decided to close this issue. Please comment if you think it should be re-opened

Per discussion in dev call today this doesn't seem to be fixed yet.

Per @evanlinjin we can fix this issue by using the new bdk_coin_select crate.

More notes from @evanlinjin from discord chat:
"We already have the TxParams::bumping_fee field we just aren't checking them correctly. However, I am concerned about rule 4 not being enforced properly (since we are actually doing coin selection again for RBF). An easy policy (that would enforce rule 4) would be to say the new tx cannot be larger than the one we are replacing. However, this is not what we are doing with our RBF logic. We add all old inputs into TxParams::utxos which is inputs that must be spent.

Therefore, it is possible that our new transaction may be larger in weight than the old one
Right now, I'm very tempted to say let's use bdk_coin_select..."

I volunteer to try and fix RBF API with bdk_coin_select. Don't have an ETA yet.

Thanks @LLFourn , if you can fix with integration of bdk_coin_select that'd be great.

@LLFourn Since we're not going to have have a bdk_coin_select crate for 1.0 can I defer this issue to the 2.0 milestone?

Yes I'd like to make the extracted bdk_coin_select one of the priorities for 2.0 so if it's better to fix this together with that I'll update the milestone.

Sorry ACK I haven't had time to do this work so yes you can push it to 2.0.0. Thanks.

We can wait until we have the Psbt in hand, get the fee from the psbt and compute an estimated feerate based on the weight of the unsigned tx and the combined satisfaction weights, then proceed to check rules 3 and 4 by comparing the fee/feerate we calculate with the fee of the previous transaction assuming we're in bumping-fee mode.

I realize I should've probably checked in before starting to work on this, I hope this was up for grabs as Rob mentioned this in his list of possible things to work on!