This issue is meant to be a general issue covering what fee bumping Core wallet does, and what it doesn't, and discussion of how to achieve future goals. I have not seen this all aggregated in any one place, and though it appropriate here. This is by no means exhaustive, and is to start a conversation after a couple personal false-starts on improving the situation.
What is supported today(through 0.16):
- Fee bumping through RBF when:
-- There are no descendants in the wallet or mempool(even if they're yours)
-- You control all inputs(
ISMINE_SPENDABLE) -- There is a change output in your transaction large enough to pay for the bump - Manual CPFP, using coin control -- Set new transaction feerate high enough to bump whole package
Scenarios I think are reasonable to attempt support:
- No change output (depending on utxo load and future optimization of coin selection this scenario can jump to quite a high %) -- Ideally run coin selection one more time with the original inputs required, residual required, selecting new inputs as needed -- Requires "effective value" framework to be sane but we should be doing that anyways. -- Change relay rules to allow sourcing an unconfirmed input for the bump(not bip125 issue, just Core implementation detail IIRC)
- Change output exists, but descendants exist -- These scenarios are trickier to me, as they involved much more unknowns to the user --- If wallet descendants only, replace all of them, pay the DoS fee, and likely end up saving overall due to cut-through change outputs. bip125 rules can make this cost more since replacement must have higher absolute fee of all the things you replaced, but a small enough feerate can make this worth it. --- CPFP via spend of unconfirmed change output, when descendants are in mempool. --- RBF with descendants in mempool that aren't yours. This can get expensive fast due to "pinning", or unconfirmed low-fee sweeps by your recipients.
My general thinking is that in the qt case as long as the resulting feerate of the wallet's package increases, the wallet should try a number of strategies to bump, and select the immediate cheapest, presenting the required fee to the user.
Far future thoughts: In future wallet functionality we can go further, where "optional sends" put destinations in a queue, and opportunistically send out with more immediate sends if it ends up being cheaper to do so. For example, someone RBF'ing a stuck transaction could also append on the bytes to send to optional destinations. CPFP'ing could also include the additional outputs. Optional sends also allow for much more aggressive change output-saving opportunities, but this is a bit sidetracking...
