The priority labels are based on nTxConfirmTarget, which seems to be confusing, as this makes the labels change when you move the slider. So change it to be based on fixed maxtarget(=25). Only the label-turns-red functionality is still based on nTxConfirmTarget.
Fixes #5552
The mining logic doesn't use fee estimates at all (wouldn't that be funny?), and I would expect the coin control logic to behave the same as the mining logic in this regard - is that no longer the case? Does this PR restore that expected behaviour?
No, with this PR coin control says estimatePriority(25) is equal to "normal" priority. The mining logic has a hardcoded "normal" priority instead. This means even after this PR, the priority labels change over time. Because the normal priority threshold floats.
The whole point of smartfee was to get rid of a hardcoded priority threshold (for the wallet, not miner), so coin control should probably reflect that. If we switch back to hardcoded priority for coin control, then you could theoretically select a "highest" priority, but you are still not allowed to send a zero-fee tx. Or you select a "lowest" and you are allowed to send it with zero-fee. Not sure if that would be less confusing.
(If you delete the fee_estimates.dat then coin control uses the hardcoded threshold, because this is the fallback, if smartfee does not have enough data yet)
384 | @@ -385,7 +385,7 @@ CTxMemPool::CTxMemPool(const CFeeRate& _minRelayFee) :
385 | // to wait a day or two to save a fraction of a penny in fees.
386 | // Confirmation times for very-low-fee transactions that take more
387 | // than an hour or three to confirm are highly variable.
Can this comment be moved to txmempool.h ?
Needs rebase, and comments addressed.
Closing due to inactivity.