@@ -22,51 +22,6 @@ class CTxMemPoolEntry;
2222class CTxMemPool ;
2323class TxConfirmStats ;
2424
25- /* * \class CBlockPolicyEstimator
26- * The BlockPolicyEstimator is used for estimating the feerate needed
27- * for a transaction to be included in a block within a certain number of
28- * blocks.
29- *
30- * At a high level the algorithm works by grouping transactions into buckets
31- * based on having similar feerates and then tracking how long it
32- * takes transactions in the various buckets to be mined. It operates under
33- * the assumption that in general transactions of higher feerate will be
34- * included in blocks before transactions of lower feerate. So for
35- * example if you wanted to know what feerate you should put on a transaction to
36- * be included in a block within the next 5 blocks, you would start by looking
37- * at the bucket with the highest feerate transactions and verifying that a
38- * sufficiently high percentage of them were confirmed within 5 blocks and
39- * then you would look at the next highest feerate bucket, and so on, stopping at
40- * the last bucket to pass the test. The average feerate of transactions in this
41- * bucket will give you an indication of the lowest feerate you can put on a
42- * transaction and still have a sufficiently high chance of being confirmed
43- * within your desired 5 blocks.
44- *
45- * Here is a brief description of the implementation:
46- * When a transaction enters the mempool, we track the height of the block chain
47- * at entry. All further calculations are conducted only on this set of "seen"
48- * transactions. Whenever a block comes in, we count the number of transactions
49- * in each bucket and the total amount of feerate paid in each bucket. Then we
50- * calculate how many blocks Y it took each transaction to be mined. We convert
51- * from a number of blocks to a number of periods Y' each encompassing "scale"
52- * blocks. This is tracked in 3 different data sets each up to a maximum
53- * number of periods. Within each data set we have an array of counters in each
54- * feerate bucket and we increment all the counters from Y' up to max periods
55- * representing that a tx was successfully confirmed in less than or equal to
56- * that many periods. We want to save a history of this information, so at any
57- * time we have a counter of the total number of transactions that happened in a
58- * given feerate bucket and the total number that were confirmed in each of the
59- * periods or less for any bucket. We save this history by keeping an
60- * exponentially decaying moving average of each one of these stats. This is
61- * done for a different decay in each of the 3 data sets to keep relevant data
62- * from different time horizons. Furthermore we also keep track of the number
63- * unmined (in mempool or left mempool without being included in a block)
64- * transactions in each bucket and for how many blocks they have been
65- * outstanding and use both of these numbers to increase the number of transactions
66- * we've seen in that feerate bucket when calculating an estimate for any number
67- * of confirmations below the number of blocks they've been outstanding.
68- */
69-
7025/* Identifier for each of the 3 different TxConfirmStats which will track
7126 * history over different time horizons. */
7227enum class FeeEstimateHorizon {
@@ -130,7 +85,50 @@ struct FeeCalculation
13085 int returnedTarget = 0 ;
13186};
13287
133- /* *
88+ /* * \class CBlockPolicyEstimator
89+ * The BlockPolicyEstimator is used for estimating the feerate needed
90+ * for a transaction to be included in a block within a certain number of
91+ * blocks.
92+ *
93+ * At a high level the algorithm works by grouping transactions into buckets
94+ * based on having similar feerates and then tracking how long it
95+ * takes transactions in the various buckets to be mined. It operates under
96+ * the assumption that in general transactions of higher feerate will be
97+ * included in blocks before transactions of lower feerate. So for
98+ * example if you wanted to know what feerate you should put on a transaction to
99+ * be included in a block within the next 5 blocks, you would start by looking
100+ * at the bucket with the highest feerate transactions and verifying that a
101+ * sufficiently high percentage of them were confirmed within 5 blocks and
102+ * then you would look at the next highest feerate bucket, and so on, stopping at
103+ * the last bucket to pass the test. The average feerate of transactions in this
104+ * bucket will give you an indication of the lowest feerate you can put on a
105+ * transaction and still have a sufficiently high chance of being confirmed
106+ * within your desired 5 blocks.
107+ *
108+ * Here is a brief description of the implementation:
109+ * When a transaction enters the mempool, we track the height of the block chain
110+ * at entry. All further calculations are conducted only on this set of "seen"
111+ * transactions. Whenever a block comes in, we count the number of transactions
112+ * in each bucket and the total amount of feerate paid in each bucket. Then we
113+ * calculate how many blocks Y it took each transaction to be mined. We convert
114+ * from a number of blocks to a number of periods Y' each encompassing "scale"
115+ * blocks. This is tracked in 3 different data sets each up to a maximum
116+ * number of periods. Within each data set we have an array of counters in each
117+ * feerate bucket and we increment all the counters from Y' up to max periods
118+ * representing that a tx was successfully confirmed in less than or equal to
119+ * that many periods. We want to save a history of this information, so at any
120+ * time we have a counter of the total number of transactions that happened in a
121+ * given feerate bucket and the total number that were confirmed in each of the
122+ * periods or less for any bucket. We save this history by keeping an
123+ * exponentially decaying moving average of each one of these stats. This is
124+ * done for a different decay in each of the 3 data sets to keep relevant data
125+ * from different time horizons. Furthermore we also keep track of the number
126+ * unmined (in mempool or left mempool without being included in a block)
127+ * transactions in each bucket and for how many blocks they have been
128+ * outstanding and use both of these numbers to increase the number of transactions
129+ * we've seen in that feerate bucket when calculating an estimate for any number
130+ * of confirmations below the number of blocks they've been outstanding.
131+ *
134132 * We want to be able to estimate feerates that are needed on tx's to be included in
135133 * a certain number of blocks. Every time a block is added to the best chain, this class records
136134 * stats on the transactions included in that block
0 commit comments