Change estimate_mode default to "ECONOMICAL" in these RPC calls about bitcoin

[ajtowns]

This code suggests it does, but I haven't tested:

estimatesmartfee rpc defaults to conservative, even if all the wallet stuff defaults to economical via defaulting to rbf-enabled.
(#10589 might be worth looking at for context)

[BullishNode]

Another option would be to have a config for default estimate mode but in that case also the default should be "ECONOMICAL" and not "CONSERVATIVE"

[ismaelsadeeq]

Therefore, I suggest changing the default fee estimation mode to "ECONOMICAL" in the following RPCs

Unfortunately even "economic" mode still overestimate so changing default mode to "economic" does not fix this issue.

There is an ongoing effort "see delving post" where contributors are discussing the challenges of CBlockPolicyEstimator which is the fee estimation strategy used by all those RPC's.

Yes this is a known issue and there is a work in progress to resolve it.

[dupontcy]

Unfortunately even "economic" mode still overestimate so changing default mode to "economic" does not fix this issue.

Maybe it does not fix it all together, but it makes it overestimate less.

The difference between ECONOMICAL and CONSERVATIVE for a confirmation target of 2 to 12 blocks is HUGE (by a factor of 7)
Here is recent data from our node with a confirmation target of 2 blocks
ECONOMICAL: 0.00020106
CONSERVATIVE: 0.00141359

The CONSERVATIVE mode uses the long stats for the 95% confirmation target, they have a half-time of 1008 blocks!
Any spike in fees and number transaction will get into the long stats and decay only very very slowly.

[BullishNode]

Agreed that switching to economical is not a long-term fix for fee estimation, but it's still a notable improvement. Implementing this change would likely lead to a very noticeable reduction in fees paid by Bitcoin Core users, and users of Bitcoin Core fee estimation, and Bitcoin users as a whole.

To give an idea of how much this affects a business which does a lot of Bitcoin transaction, we actually created software that will pull the recomended fees from the mempool api and we feed that to Bitcoin Core as feerate instead of using the confirmation target.

Not everybody has the technical capacity to do that, switching to economical as default would provide much needed relief without any additional complexity added to the fee estimation algorithm.

[Symphonic3]

Willing to create a PR for this if desired!

[Sjors]

Are you sure this isn't already happening?

This code suggests it does, but I haven't tested:

bitcoin/src/wallet/fees.cpp

Lines 52 to 53 in 9d1a286

	// By default estimates are economical iff we are signaling opt-in-RBF
	bool conservative_estimate = !coin_control.m_signal_bip125_rbf.value_or(wallet.m_signal_rbf);

cc @achow101