[Enhancement] Add real fee estimation to Floresta core and expose it via libfloresta APIs

[4xvgal]

Describe the enhancement
Floresta currently returns a hardcoded value (0.0001 BTC/kB) for the Electrum blockchain.estimatefee RPC call. This enhancement proposes adding a real fee estimation mechanism to Floresta core, derived from either the mempool or recent block fee rates, and exposing it through libfloresta APIs so downstream consumers can query it.

Use case
Downstream projects such as bdk-floresta and wallets built on top of it need accurate fee rates for transaction building, RBF, and fee bumping. With this feature, bdk-floresta can expose Node::estimate_fee() to wallet applications, replacing the current hardcoded or fallback fee rates.

Additional context
The current hardcoded value is documented in crates/floresta-electrum/src/electrum_protocol.rs with a // TODO: Ask Backend for fees comment. A possible starting point is the existing FeeRateIndexer example in crates/floresta/examples/indexer.rs, which demonstrates tracking the minimum fee rate from recently validated blocks using BlockConsumer::on_block with spent_utxos.

[moisesPompilio]

Ideally, the project should finish the mempool implementation and provide estimate_fee based on that data. However, as a temporary solution, it could estimate fees using the most recent block, since fee rates usually do not vary significantly from one block to its predecessor.

[4xvgal]

Ideally, the project should finish the mempool implementation and provide estimate_fee based on that data. However, as a temporary solution, it could estimate fees using the most recent block, since fee rates usually do not vary significantly from one block to its predecessor.

1 block works, but if the mempool implemantion takes longer than expected, we could extend it slightly - make verify_block_transactions return Amount, Store the last 6 or n blocks fee rates, and compute a percentile.

1 block approach will add ~20 lines of code, n block percentile will add ~50 lines of code. it's only ~30 more lines than 1 block approach, but it handles much.

how do you think?

[Davidson-Souza]

I think the median for past few blocks ought to be fine. Core uses it in -blocksonly mode IIRC.

[4xvgal]

I think the median for past few blocks ought to be fine. Core uses it in -blocksonly mode IIRC.

Guess it's bitcoin/bitcoin#18766
What if we store all fee rates from the last 6–18 blocks and use percentiles: P75 for fast, P50 for normal, P25 for slow?

[moisesPompilio]

Guess it's bitcoin/bitcoin#18766
What if we store all fee rates from the last 6–18 blocks and use percentiles: P75 for fast, P50 for normal, P25 for slow?

I think following Bitcoin Core's approach is the ideal solution. We just shouldn't store the full blocks. Instead, we could compute the average fee rate paid in each block (or a similar metric) and store it alongside the block hash and height. That would be enough to identify the processed block. In the event of a reorg, we would simply replace the processed block at the affected height and recompute the averages.

[4xvgal]

Guess it's bitcoin/bitcoin#18766
What if we store all fee rates from the last 6–18 blocks and use percentiles: P75 for fast, P50 for normal, P25 for slow?

I think following Bitcoin Core's approach is the ideal solution. We just shouldn't store the full blocks. Instead, we could compute the average fee rate paid in each block (or a similar metric) and store it alongside the block hash and height. That would be enough to identify the processed block. In the event of a reorg, we would simply replace the processed block at the affected height and recompute the averages.

Yeah that solution looks good instead of storing full block