More economical fee estimates for opt-in-RBF transactions #10586

1. 
   morcos commented at 3:16 pm on June 14, 2017: member

   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

2. remove default argument from GetMinimumFee 349f283733
3. Introduce a fee estimate mode.

   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.

   bb014427ff
4. remove default argument from estimateSmartFee c54a9acd0f
5. Change default fee estimation mode.

   Fee estimates will default to be non-conservative if the transaction in question is opt-in-RBF.

   2c0d5464e2
6. morcos force-pushed on Jun 18, 2017
7. 
   morcos commented at 12:15 pm on June 18, 2017: member

   Rebased due to conflict with #10422
8. MarcoFalke added the label TX fees and policy on Jun 18, 2017
9. 
   laanwj commented at 1:20 pm on June 22, 2017: member

   Nice!
10. in src/wallet/wallet.cpp:4152 in 2c0d5464e2

    4147@@ -4145,3 +4148,15 @@ bool CMerkleTx::AcceptToMemoryPool(const CAmount& nAbsurdFee, CValidationState&
    4148 {
    4149     return ::AcceptToMemoryPool(mempool, state, tx, true, NULL, NULL, false, nAbsurdFee);
    4150 }
    4151+
    4152+bool CalculateEstimateType(FeeEstimateMode mode, bool opt_in_rbf) {
    

    ---

    ---

    

    TheBlueMatt commented at 10:09 pm on June 22, 2017:

    A more descriptive name here may be useful - ShouldEstimateBeConservative or something?

    ---

    

    morcos commented at 7:17 pm on June 27, 2017:

    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#pullrequestreview-45713269
11. 
    TheBlueMatt commented at 11:50 pm on June 22, 2017: member

    I really have no ability to review the Qt changes here, but generally looks awesome.
12. 
    morcos commented at 7:18 pm on June 27, 2017: member

    Closing this since it’s contained in #10589.
13. morcos closed this on Jun 27, 2017

    ---

14. MarcoFalke locked this on Sep 8, 2021

Contributors
morcos laanwj TheBlueMatt

Labels
TX fees and policy