We want to be able to estimate feerates or priorities that are needed on tx's to be included in a certain number of blocks.
More...
We want to be able to estimate feerates or priorities that are needed on tx's to be included in a certain number of blocks.
The BlockPolicyEstimator is used for estimating the feerate needed for a transaction to be included in a block within a certain number of blocks.
Every time a block is added to the best chain, this class records stats on the transactions included in that block
At a high level the algorithm works by grouping transactions into buckets based on having similar feerates and then tracking how long it takes transactions in the various buckets to be mined. It operates under the assumption that in general transactions of higher feerate will be included in blocks before transactions of lower feerate. So for example if you wanted to know what feerate you should put on a transaction to be included in a block within the next 5 blocks, you would start by looking at the bucket with with the highest feerate transactions and verifying that a sufficiently high percentage of them were confirmed within 5 blocks and then you would look at the next highest feerate bucket, and so on, stopping at the last bucket to pass the test. The average feerate of transactions in this bucket will give you an indication of the lowest feerate you can put on a transaction and still have a sufficiently high chance of being confirmed within your desired 5 blocks.
Here is a brief description of the implementation: When a transaction enters the mempool, we track the height of the block chain at entry. Whenever a block comes in, we count the number of transactions in each bucket and the total amount of feerate paid in each bucket. Then we calculate how many blocks Y it took each transaction to be mined and we track an array of counters in each bucket for how long it to took transactions to get confirmed from 1 to a max of 25 and we increment all the counters from Y up to 25. This is because for any number Z>=Y the transaction was successfully mined within Z blocks. We want to save a history of this information, so at any time we have a counter of the total number of transactions that happened in a given feerate bucket and the total number that were confirmed in each number 1-25 blocks or less for any bucket. We save this history by keeping an exponentially decaying moving average of each one of these stats. Furthermore we also keep track of the number unmined (in mempool) transactions in each bucket and for how many blocks they have been outstanding and use that to increase the number of transactions we've seen in that feerate bucket when calculating an estimate for any number of confirmations below the number of blocks they've been outstanding.
Definition at line 200 of file fees.h.
1.9.1