More economical fee estimates for opt-in-RBF transactions #10586
Conversation
GetMinimumFee now passes the conservative argument into estimateSmartFee. Call CalculateEstimateType(mode) before calling GetMinimumFee or estimateSmartFee to determine the value of this argument. CCoinControl can now be used to control this mode.
Fee estimates will default to be non-conservative if the transaction in question is opt-in-RBF.
morcos
force-pushed
the
aggressiveEstimates
branch
from
029282f to
2c0d546
Compare
|
Rebased due to conflict with #10422 |
|
Nice! |
TheBlueMatt
left a comment
TheBlueMatt
left a comment
There was a problem hiding this comment.
I really have no ability to review the Qt changes here, but generally looks awesome.
| return ::AcceptToMemoryPool(mempool, state, tx, true, NULL, NULL, false, nAbsurdFee); | ||
| } | ||
|
|
||
| bool CalculateEstimateType(FeeEstimateMode mode, bool opt_in_rbf) { |
There was a problem hiding this comment.
A more descriptive name here may be useful - ShouldEstimateBeConservative or something?
There was a problem hiding this comment.
I think it makes more sense to let it be generic and ideally estimatesmartfee would take a FeeEstimateMode and this functions purpose would be to take any requested mode and other wallet parameters and use wallet logic to determine a final mode. Rather than make all those changes now while not yet needed though, I think I'll just change the RPC interface to conservative estimates to take a string as per #10589 (review)
|
Closing this since it's contained in #10589. |
4 participants
This PR takes advantage of the new fee estimation feature that will potentially give lower estimates if recent market conditions warrant it. The logic used here is that any time a transaction signals opt-in-RBF and uses automatic fee estimation then it will use the non-conservative estimate. Transactions which do not signal opt-in-RBF will still use the default conservative estimate.
In a nutshell conservative estimates require that your fee rate would meet the necessary confirmation threshold for double your target at longer time horizons as well. This reduces the likelihood that you place a transaction just as the market is starting to get busy again that ends up being stuck for a very long time.
I'm working on a follow-on PR which will allow the specification of transaction confirmation target and whether the estimate should be conservative or not on a per-RPC call basis for sendtoaddress, sendmany, and fundrawtransaction.
I'd love it if someone else working on the QT ability to force estimates to be conservative or not (overriding the RBF implied default).
The first commit is #10582 which is a pre-existing bug fix