bumpfee.TotalFee removed without replacement

[maflcko]

#15996 (comment)

[instagibbs]

confTarget? Or you mean more like #16203 ?

If we think it's a mistake to remove a feature, then it shouldn't matter if there's a direct feerate replacement anyways, and it should be reverted.

[instagibbs]

Probably the best point in favor of not removing it: #15996 (comment)

to which I responded essentially "power users don't need that RPC call at all if they're manually calculating package rates"

[maflcko]

Probably the best point in favor of not removing it: #15996 (comment)

This overlaps a bit with

• Implement auto-fee leveling when spending unconfirmed outputs Implement auto-fee leveling when spending unconfirmed outputs #15553

I'd say it can be solved by an optional flag, that indicates if the target fee rate should be for the tx that is bumped or for the package

[Sjors]

I'm fine with removing totalFee once feeRate is there, see #16203.

Note that totalFee is deprecated, but not removed. Though I agree it's also odd to deprecate something before there's a replacement.

[maflcko]

At the very least it should be possible to switch back and forth between two major releases without having to re-adjust the API every time. Deprecating something without replacement is breaking that.

[instagibbs]

I'll try to push to get #16492 in master then to avoid any issues or need for reversion.

[instagibbs]

#16727 is pretty much sitting there waiting for more review. Probably a little late for feature freeze, maybe not though? Might be able to get the band together to squeeze it in.

[instagibbs]

This has been resolved by #16727 which is now merged