Change estimate_mode default to "ECONOMICAL" in these RPC calls

BullishNode commented at 10:48 pm on April 30, 2024: none

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

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 added the label Feature on Apr 30, 2024

BullishNode commented at 10:54 pm on April 30, 2024: none

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 commented at 8:42 am on May 1, 2024: member

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 commented at 4:22 pm on May 1, 2024: none

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 commented at 5:14 pm on May 1, 2024: none

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 commented at 9:41 pm on May 1, 2024: none

Willing to create a PR for this if desired!

Sjors commented at 10:21 am on May 2, 2024: member

Are you sure this isn’t already happening?

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

https://github.com/bitcoin/bitcoin/blob/9d1a286f20b8a602ffe72928bcd79be09fdbf9d0/src/wallet/fees.cpp#L52-L53

cc @achow101

ajtowns commented at 4:55 am on May 3, 2024: contributor

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)

bitcoin deleted a comment on Jun 12, 2024

glozow commented at 11:05 am on July 18, 2024: member

This code suggests it does, but I haven’t tested: @Sjors that code is for wallet getting an estimate when it’s making a BIP125-signaling tx.

People on this thread may want to review #30275

fanquake closed this on Jul 25, 2024

fanquake referenced this in commit f7ab3ba404 on Jul 25, 2024

Change estimate_mode default to “ECONOMICAL” in these RPC calls #30009