Allow specifying an alternative fee endpoint like mempool.space

[sethforprivacy]

While testing out Join Market via JAM, I ran into a (common) occurrence of Core's estimatesmartfee endpoint being WAY off in it's estimate:

Using bitcoin network feerate for 3 block confirmation target (randomized for privacy): 129639 sat/kvB (129.6 sat/vB)

While fees were at 10-12sats/vb, JM got an estimate of ~129sats/vb, overspending by 10x even though it was supposed to be doing the default 3-block estimate. Of course this could be 20% lower/higher than the fee estimate it received, but even then is egregiously high. This is a common and well-known issue with Bitcoin Core, and is normally solved by using a more smart fee estimation system like that of mempool.space. As mempool.space has a Tor endpoint for fees, is easy to self-host, and widely used in the ecosystem, that would be a fantastic place to start allowing users to specify in the config file if they prefer it over Bitcoin Core.

The fee API can be found here: https://mempool.space/api/v1/fees/recommended

[kristapsk]

While testing out Join Market via JAM, I ran into a (common) occurrence of Core's estimatesmartfee endpoint being WAY off in it's estimate

If Bitcoin node is not ruinning 24x7, fee estimates will be way off. As it works by looking at and computing averages how much blocks it took for transaction in various fee rate groups to confirm.

Mempool.space will not work for JM here, as it does not give results for individual block confirmation targets, but there is proposed draft PR to use Esplora (blockstream.info) - #1481. Although that will also not work in this situation, it currently is meant as a fallback when Core fee estimations is not working at all. But code to get fee estimations from Esplora is there.

[sethforprivacy]

While testing out Join Market via JAM, I ran into a (common) occurrence of Core's estimatesmartfee endpoint being WAY off in it's estimate

If Bitcoin node is not ruinning 24x7, fee estimates will be way off. As it works by looking at and computing averages how much blocks it took for transaction in various fee rate groups to confirm.

Mempool.space will not work for JM here, as it does not give results for individual block confirmation targets, but there is proposed draft PR to use Esplora (blockstream.info) - #1481. Although that will also not work in this situation, it currently is meant as a fallback when Core fee estimations is not working at all. But code to get fee estimations from Esplora is there.

My node runs 24/7 and is very well connected, FWIW.

When specifying a mempool.space instance, you could just have one additional arg that becomes required that allows you to choose the fee target between fastest, half hour, hour, economy, and minimum instead of the block target that is currently used.

[sethforprivacy]

An alternative approach would just be to compare the Core-provided fee estimate against the mempool.space targets and add a warning modal if they are something like >%10 different than the closest fee estimate (i.e. the default 3 blocks vs half-hour, which is the same target in time) provided by mempool.space.

This could be done over Tor in the background and be only an additional check to protect users from wasting thousands of sats on fees unnecessarily.

[kristapsk]

An alternative approach would just be to compare the Core-provided fee estimate against the mempool.space targets and add a warning modal if they are something like >%10 different than the closest fee estimate (i.e. the default 3 blocks vs half-hour, which is the same target in time) provided by mempool.space.

This could be done over Tor in the background and be only an additional check to protect users from wasting thousands of sats on fees unnecessarily.

After #1641 or something similar is added to RPC API, Jam (or any other JM RPC API client) itself could this.