fees: rpc: estimatesmartfee now returns a fee rate estimate during low network activity #32395

1. 
   ismaelsadeeq commented at 3:12 pm on May 1, 2025: member

   This PR fixes #32105 and related issues: #32178, #31116, and #31032.
   The main motivation is outlined in this comment).

   Bitcoin Core users have reported several issues where nodes are unable to provide fee rate estimates, despite having run long enough to do so for a given target. This typically occurs when there is low activity on the network.

   As a result, the issue primarily affects nodes running on test networks signet and testnetn.

   I think it is safe safe to return the maximum of mempoolminfee and minrelaytxfee but only after the node has run long enough to be able to provide an estimate for the target and still cannot.
   (This avoids the issue of returning an unreliable estimate too early, as described by glozow).

   The only potential downside is in scenarios where the user has very very poor peer connectivity and most incoming mempool transactions are not seen by the node.
   Even then, with the current full RBF support, txs can safely be fee bumped if needed.

   This PR includes two commits:

   • Bugfix for MaxUsableEstimate: It should not return 1 as a usable target, since this is effectively not usable.
   • Update to the estimatesmartfee RPC behavior: Now returns the maximum of minrelaytxfee and mempoolminfee when the estimator has recorded enough blocks for the requested confirmation target, but cannot produce an estimate.

   Additional Context:

   The fee estimator should be able of providing an estimate for a confirmation target n after observing at least n * 2 blocks from either historical or current stats. The method MaxUsableEstimate determines this.

   In the estimateSmartFee RPC method, the value shown as blocks in the result corresponds to the returnedTarget, which is the minimum of the user providedconf_target and the output of MaxUsableEstimate.

   Therefore, taking the maximum of mempoolminfee and minrelaytxfee when returnedTarget >= conf_target indicates that enough blocks have been recorded, but there is simply no activity on the network to provide estimate.
   In such cases, the mempool might be empty, and the transaction should pay enough to be relayed to peers making it likely to confirm since their is no demand.

   Note: The condition uses >= because, for example, a conf_target of 1 will result in a returnedTarget of 2 internally, so it is possible for returnedTarget to be > conf_target.

2. fees: bugfix: prevent returning 1 as usable estimate ffcc1c6567
3. fees: rpc: update `estimatesmartfee` to return an estimate during low network activity caa9f99b92
4. 
   DrahtBot commented at 3:12 pm on May 1, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32395.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #31664 (Fees: add Fee rate Forecaster Manager by ismaelsadeeq)
   • #30157 (Fee Estimation via Fee rate Forecasters by ismaelsadeeq)

   If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

   LLM Linter (✨ experimental)

   Possible typos and grammar issues:

   to able → to be able

Contributors
ismaelsadeeq DrahtBot