[draft] 10 minute confirmation target

[kiminuo]

Fixes #11358
Depends on #12910

Introduction

The problem here is that conf_target in estimatesmartfee conf_target ( "estimate_mode" ) cannot be 1 because:

The request target will be clamped between 2 and the highest target fee estimation is able to return based on how long it has been running.

[Source]

Testing

Given that RegTest does not really have history and thus it is handles specially, we need to test RegTest as well.

Resources

• For anyone wondering why smart in estimatesmartfee. There used to be estimatefee which was superseded by estimatesmartfee in [rpc] deprecate estimatefee bitcoin/bitcoin#11031.
• Improving fee estimation accuracy bitcoin/bitcoin#27995 - Improving fee estimation accuracy
• https://bitcoin.stackexchange.com/questions/121384/why-does-bitcoin-cores-estimatesmartfee-return-a-higher-feerate-than-necessar

  The Bitcoin Core fee estimator does not aim to provide the minimum possible feerate to be included within N blocks. It aims to provide the minimum feerate such as one has a high degree of confidence the transactions will be mined within N blocks.

  It therefore tends to often give a higher estimate than appears to have been necessary on any particular transaction. But it also provides a guarantee that over time a high percentage of the transactions created with the recommended feerate will have been mined within the required N blocks.

• Improving fee estimation accuracy bitcoin/bitcoin#27995 - Improving fee estimation accuracy

  [The estimator] is solely based on historical data (looking at how long mempool transactions take to confirm), it cannot react quickly to changing conditions.

[turbolay]

I'm unsure of this concept. I think if we are doing something like this we should at least try to do it properly.

I like this approach of the problem by OXT: https://code.samourai.io/oxt/one_dollar_fee_estimator/-/blob/master/README.md
I think it produces great results. It is server side.

A simplification of this algorithm that keeps the same idea is what @MaxHillebrand suggested in the first issue to take 0.5 MB of the mempool.

I'm sorry to suggest a more complex approach, but an estimation you can't trust is an estimation you don't want to use. I see no value, and even harm, of multiplying by a random coefficient.

[kiminuo]

I just tried to do what seemed to be the request.

If there is an agreement on a better solution, we can certainly work on a better solution.

@molnard Do you have an opinion on this?

[molnard]

I like this approach of the problem by OXT:

The link is not available anymore :( I guess I know why. I cannot see how that should work.

The fundamental idea is to make sure to be in the next block. If I need to do this manually: I would look at the mempool, check the txs in the next expected block, find the minimum fee, and try to aim a bit above that.

Questions:

• Do we have the mempool on the client side? No, just partially. It is impossible to calculate this on the client side.
• Can we guess the next block? I am not aware of any functions that can do that in bitcoind. Let me know if there is.
• Even if we would have the expected block, aiming a bit above would result in using some kind of random coefficient.

to take 0.5 MB of the mempool.

Can work, it is coming from "above" (from the highest fee direction). The coefficient here is xMb. Take xMb of the mempool means, ordering txs in descending order according to FeeRate without any other logic (transaction chains, etc.)?