One of the responses from the getblockstats RPC is feerate_percentiles, which returns the following:
0"feerate_percentiles": [ (json array, optional) Feerates at the 10th, 25th, 50th, 75th, and 90th percentile weight unit (in satoshis per virtual byte)
1 n, (numeric) The 10th percentile feerate
2 n, (numeric) The 25th percentile feerate
3 n, (numeric) The 50th percentile feerate
4 n, (numeric) The 75th percentile feerate
5 n (numeric) The 90th percentile feerate
6]
Currently, the implementation simply appends the fee rates of all transactions in a block along with their corresponding weights to a vector, and then returns the percentile fee rates. https://github.com/bitcoin/bitcoin/blob/ffe4261cb0669b1e1a926638e0498ae5b63f3599/src/rpc/blockchain.cpp#L2027-L2030
However, the fee rate of a transaction at a given percentile may not reflect its effective fee rate, as it could be fee-bumped by some descendant transactions.
To address this, transactions within a block that are not independent should first be linearized using an ancestor-based linearization algorithm, for example using MiniMiner. This approach would be similar to what’s done in #30079.
Note: MiniMiner will change alot due to #30289, which introduces a new form of linearization. While I assume linearization will still be supported in MiniMiner for mempool transactions, I’m unsure about support for linearizing non-mempool transactions.
A more efficient approach would be to persist previous block package data. With this approach, I don’t see any reason to support linearizing non-mempool transactions in MiniMiner for now. While this would increase resource usage, I believe the trade-off is justified when compared to the complexity of linearizing clusters on the fly.
Having this package data available from disk would be very helpful for both this issue and #30079.