Crate bitcoin_blockpolicy
source ·Structs
- | \class BlockPolicyEstimator | | The BlockPolicyEstimator is used for estimating | the feerate needed for a transaction to be | included in a block within a certain number of | blocks. | | ––––––––––– | 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 | 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. All further calculations are | conducted only on this set of “seen” | transactions. | | 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. We convert from | a number of blocks to a number of periods Y’ | each encompassing “scale” blocks.
| | This is tracked in 3 different data sets each | up to a maximum number of periods. Within each | data set we have an array of counters in each | feerate bucket and we increment all the | counters from Y’ up to max periods representing | that a tx was successfully confirmed in less | than or equal to that many periods. | | 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 of the periods or less for | any bucket.
| | We save this history by keeping an | exponentially decaying moving average of each | one of these stats. This is done for | a different decay in each of the 3 data sets to | keep relevant data from different time | horizons.
| | Furthermore we also keep track of the number | unmined (in mempool or left mempool without | being included in a block) transactions in | each bucket and for how many blocks they have | been outstanding and use both of these numbers | 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. | | –––––––––– | We want to be able to estimate feerates that | are needed on tx’s to be included in 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
Constants
- | Require greater than 95% of X feerate | transactions to be confirmed within | 2 * Y blocks |
- | Spacing of FeeRate buckets | | We have to lump transactions into buckets | based on feerate, but we want to be able | to give accurate estimates over a large | range of potential feerates | | Therefore it makes sense to exponentially | space the buckets |
- | Require greater than 60% of X feerate | transactions to be confirmed within | Y/2 blocks |
- | Track confirm delays up to 1008 blocks | for long horizon |
- | Decay of .99931 is a half-life of 1008 | blocks or about 1 week |
- | Track confirm delays up to 48 blocks | for medium horizon |
- | Decay of .9952 is a half-life of 144 blocks | or about 1 day |
- | Minimum and Maximum values for tracking | feerates | | The MIN_BUCKET_FEERATE should just | be set to the lowest reasonable feerate | we might ever want to track. Historically | this has been 1000 since it was inheriting | DEFAULT_MIN_RELAY_TX_FEE and changing | it is disruptive as it invalidates old | estimates files. So leave it at 1000 | unless it becomes necessary to lower | it, and then lower it substantially. |
- | Historical estimates that are older | than this aren’t valid |
- | Track confirm delays up to 12 blocks | for short horizon |
- | Decay of .962 is a half-life of 18 blocks | or about 3 hours |
- | Require greater than 85% of X feerate | transactions to be confirmed within | Y blocks |
- | Require an avg of 0.1 tx in the combined | feerate bucket per block to have stat | significance |
- | Require an avg of 0.5 tx when using short | decay since there are fewer blocks considered |