Change estimate_mode default to "ECONOMICAL" in these RPC calls

[BullishNode]

The default fee estimate mode for the following RPC calls is set to "ECONOMICAL" rather than "CONSERVATIVE".

My observation running a Bitcoin non-custodial exchange and payment processor which creates a lot transactions is that Bitcoin Core on conservative mode consistently overpays transaction fees as compared to mempool's fee estimation algorithm. I have collected data on this, if anyone needs convincing, but I think this is common knowledge.

Since RBF, it is standard best practice for advanced Bitcoin users to "lowall" transaction fees instead and RBF later if their transaction. Unfortunately, Bitcoin Core users and wallets which use Bitcoin Core's fee estimation will probably use the default mode (as users always do) and this will lead them to "overpay" more often than not.

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

estimatesmartfee

send

sendmany

sendtoaddress

fundrawtransaction

Getting Started

walletcreatefundedpsbt

I would exclude this change from RBF related RPCs, where the user probably wants the RBF to be sucessful and is clearly willing to pay more for faster confirmation.

psbtbumpfee

bumpfee

I'm not a developer but am willing to financially support a developer willing to make a PR for this if there is interest.

[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

[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)