![]() Please see PR 10199 Under the hood improvements There is a required number of data points per bucket before doing the evaluation and you will just combine successive fee rate buckets to achieve that. If you pass the threshold you check the next highest fee rate bucket and keep going, returning the last bucket that met the threshold before the first bucket which fails it. Txs-confirmed-in-target-or-less / (all-confirmed-txs + txs-still-in-mempool-for-at-least-target) > threshold (0.95 in 0.14). To calculate an estimate you look only at the counters corresponding to your desired confirmation target and you start at the highest fee rate bucket and evaluate for txs in that fee rate bucket whether: All counters are decayed by 0.998 every block. So if a block includes a specific transaction T, when you look up its mempool entry and see it entered the mempool 12 blocks ago, you then increment the counters for targets 12-25 for its fee rate bucket and increment the total tx count for that bucket. You also keep an overall counter of all transactions of that fee rate. The implementation conceptually is that for each fee rate bucket you keep a counter for each possible confirmation target (1-25 in 0.14) of how many transactions in that bucket were confirmed in the target or less. Only transactions which had no unconfirmed parents at the time they entered the mempool are considered. In 0.14 this decay is 0.998 or a half-life of 346 blocks. The recent history is defined as an exponentially decaying moving average with the data point counted at the time of transaction confirmation. A fee rate bucket represents a range of fee rates within which the algorithm treats all transactions as having approximately the same fee rate and the answer the algorithm returns is actually the lowest fee rate bucket such that transactions in that bucket and all higher buckets were confirmed within the target over the recent history. Transactions can occur with a nearly continuous range of fee rates and so in order to avoid tracking every historical transaction independently, they are grouped into fee rate "buckets". It only looks at some recent history of transactions and returns the lowest fee rate such that in that recent history a very high fraction of transactions with that fee rate were confirmed in the block chain in less than the target number of blocks. The algorithm is conceptually very simple and does not attempt to have any predictive power over future conditions. It returns a fee rate that you should use on your transaction in order to achieve this. The algorithm takes as input a target which represents a number of blocks within which you would like your transaction to be included in the blockchain. High level description Bitcoin Core's fee estimation algorithm ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |