Add rpcestimateconservativefees

juanmigdr commented at 11:19 am on April 23, 2025: none

Summary

This PR introduces a new configuration option: -rpcestimateconservativefees. When enabled, it forces the default behavior of the estimatesmartfee RPC to use conservative mode fee estimation.

Motivation

Bitcoin Core v28.0 changed the default fee estimation mode for estimatesmartfee from conservative to economical ([#30275](https://github.com/bitcoin/bitcoin/pull/30275)). While this change reduces fee over-estimation for most users, it may not be ideal in all environments.

In my case, I maintain a long-running node (since v24.0) with multiple clients depending on the legacy conservative behavior. This flag allows operators like myself to preserve that behavior without requiring client-side changes.

Usage

Can be added to bitcoin.conf or used as a command-line flag:

0rpcestimateconservativefees=1

Impact

This feature allows node operators to opt back into conservative fee estimation by default, offering a smoother upgrade path and preserving expected behavior for dependent systems.

rpc: add -rpcestimateconservativefees option for fee estimation 570bd443e8

fix: refactor estimatesmartfee to use default estimate mode variable to fix failing pipeline 218a7b07c0

fix: include common/args.h in fees.cpp for fee estimation functionality 69c593af83

DrahtBot commented at 11:19 am on April 23, 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/32329.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept NACK	ismaelsadeeq, glozow, stickies-v

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

fix: remove unnecessary whitespace in estimatesmartfee function 712f93f8eb

Merge branch 'add-rpcestimateconservativefees' of https://github.com/juanmigdr/bitcoin into add-rpcestimateconservativefees 839465624f

DrahtBot added the label CI failed on Apr 23, 2025

DrahtBot commented at 11:27 am on April 23, 2025: contributor

🚧 At least one of the CI tasks failed. Debug: https://github.com/bitcoin/bitcoin/runs/41006893423

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

ismaelsadeeq commented at 12:12 pm on April 23, 2025: member

Bitcoin Core v28.0 changed the default fee estimation mode for estimatesmartfee from conservative to economical ([#30275](https://github.com/bitcoin/bitcoin/pull/30275)). While this change reduces fee overestimation for most users, it may not be ideal in all environments.

You can easily opt in to the conservative mode by passing a parameter to estimatesmartfee.

In my case, I maintain a long-running node (since v24.0) with multiple clients depending on the legacy conservative behavior. This flag allows operators like myself to preserve that behavior without requiring client-side changes.

It was determined that the conservative mode is not needed by most users and in some cases, even harmful as explained in #30275, supported by empirical research and user report #30009 . Hence the switch.

Since there is already a runtime parameter for estimatesmartfee that enables the behavior you’re proposing. Shouldn’t this be the other way around i.e clients that truly need conservative mode can opt in. I don’t think it’s necessary to introduce a startup option for this. Hence, NACK.

I’m also curious what clients or applications specifically require the conservative behavior of estimatesmartfee?

fix: refactor estimatesmartfee to use a separate variable for conservative default 4e26f2880e

test: add test for default estimate mode with rpcestimateconservativefees flag 18ad3c6fd5

juanmigdr commented at 12:35 pm on April 23, 2025: none

Bitcoin Core v28.0 changed the default fee estimation mode for estimatesmartfee from conservative to economical ([#30275](#30275)). While this change reduces fee overestimation for most users, it may not be ideal in all environments.

You can easily opt in to the conservative mode by passing a parameter to estimatesmartfee.

In my case, I maintain a long-running node (since v24.0) with multiple clients depending on the legacy conservative behavior. This flag allows operators like myself to preserve that behavior without requiring client-side changes.

It was determined that the conservative mode is not needed by most users and in some cases, even harmful as explained in #30275, supported by empirical research and user report #30009 . Hence the switch.

Since there is already a runtime parameter for estimatesmartfee that enables the behavior you’re proposing. Shouldn’t this be the other way around i.e clients that truly need conservative mode can opt in. I don’t think it’s necessary to introduce a startup option for this. Hence, NACK.

I’m also curious what clients or applications specifically require the conservative behavior of estimatesmartfee?

Thank you for your feedback @ismaelsadeeq.

I manage a hosted node that has been used by multiple clients for years. After upgrading to Bitcoin Core v28.0, some of these clients reported unexpected changes in the fee estimation behavior and expressed a desire to keep using the “conservative” fee estimation mode. While I do not have specific details on their reasons, the key issue is that they did not anticipate this change in behavior, and they do not wish to modify their source code to accommodate the new default behavior.

Since they do not want to send the parameter to enable the conservative mode in the RPC request, I thought this flag could offer a solution. The motivation behind the upgrade was to support clients who wanted to use testnet4, and I expected the transition to be smoother, but the fee estimation change has caused some issues for these clients.

I understand the rationale behind making the “economical” mode the default, but for some long-running nodes with multiple clients depending on the legacy behavior, this change has led to complications. Adding this configuration flag allows operators like myself to maintain backward compatibility without requiring client-side changes.

I hope this clarifies the reasoning for this request.

refactor: remove redundant test for default estimate mode with rpcestimateconservativefees flag 8ee82a828c

fix: remove rpcestimateconservativefees command-line argument from test cases cd068a3630

glozow commented at 1:44 pm on April 23, 2025: member

Concept NACK - even if there are good reasons to use conservative fee estimation, using a config option instead of the RPC parameter is more rigid, requires coordination with the node runner, wouldn’t be available for another 6 months, and further complicates the current mess of config options. Passing a ‘conservative’ arg should be a one-line change to their source code and is already supported by all maintained versions of Core.

While I do not have specific details on their reasons, the key issue is that they did not anticipate this change in behavior,

While I sympathize with the frustration of things breaking due to changes upstream, it was very clearly described in the v28.0 release notes.

and they do not wish to modify their source code to accommodate the new default behavior.

That’s exactly what this pull request is doing, except asking Bitcoin Core to do it to accommodate a small set of users.

stickies-v commented at 2:16 pm on April 23, 2025: contributor

Concept NACK, for reasons outlined by @glozow and @ismaelsadeeq - this seems like way too niche of a use case to add the maintenance burden and UX confusion of a new RPC/startup option into Bitcoin Core.

I think you can easily solve this by running a small JSON-RPC proxy that listens on the usual RPC port, injects a estimate_mode argument if none is provided and forwards that to the bitcoind instance? Then your clients won’t need to make any changes for as long as you’re willing to maintain backwards compatibility.

furszy commented at 2:19 pm on April 23, 2025: member

I think you can easily solve this by running a small JSON-RPC proxy that listens on the usual RPC port, injects a estimate_mode argument if none is provided and forwards that to the bitcoind instance? Then your clients won’t need to make any changes for as long as you’re willing to maintain backwards compatibility.

Or.. while the clients adapt, simpler to just downgrade or compile the binaries yourself.

fanquake commented at 3:00 pm on April 23, 2025: member

Agree with the other comments here. Closing for now.

fanquake closed this on Apr 23, 2025

juanmigdr commented at 3:09 pm on April 23, 2025: none