Abstract and 1. Introduction

  1. Preliminaries
  2. Problem definition
  3. BtcFlow
  4. Bitcoin Core (BCore)
  5. Mempool state and linear perceptron machine learning (MSLP)
  6. Fee estimation based on neural network (FENN)
  7. Experiments
  8. Conclusion, Acknowledgements, and References

5 Bitcoin Core (BCore)

BCore[3] is what the community calls the codebase used to control the currency. It gives an estimate of the transaction feerate for a given block interval. Similar to BtcFlow, BCore seeks out the lowest feerate to ensure that transactions are confirmed within the specified timeframe. The distinction is that BCore pays more attention to historical transactions that have been recorded in the blockchain. It argues that by combining the feerates of prior transactions confirmed within the same block interval, an expected feerate may be determined. Meanwhile, when computing the estimation, BCore considers the records in recent blocks to be more useful than those in previous blocks.

This prediction procedure can be formulated based on its data resources:

5.1 Estimation procedure

The estimation procedure illustrated in Fig. 2 (more details in Algorithm 2) is composed of two phrases: The preProcessing process in BCore is to collect transaction confirmation related to the transaction feerate. To be specific, BCore focuses on three parts of information when given a specific feerate and an expected confirmation time: overall historical confirmation in the entire blockchain, transaction confirmation related to this feerate and unconfirmed transactions that have been waiting longer than the given confirmation time. BCore returns the estimated feerate based on transaction records that meets the model requirements during the estimation procedure.

– PreProcessing process. When dealing with the historical confirmation information, BCore believes that recent blocks can provide more accurate information than older blocks. The influence is precisely described as an exponentially weighted moving trend. When a new block is formed, the old blocks’ impact fades at a set rate[9]. Considering that feerate values are continuous, BCore utilizes a feerate technique similar to BtcFlow, a trade-off between estimation precision and processing complexity. It uses the term ’bucket’ to define a feerate scale (starting at 1), and instead of examining each feerate value, it looks at the confirmation information for each feerate scale (bucket).

– Confirmed feerate (avg) is the weighted feerate of all confirmed transactions for each bucket u, which is related to txCtAvg.

– Overall unconfirmed counts (txUnCt), which is the number of transactions that have not been confirmed and have waited more than θ at the current block height.

– Estimation process. BCore will deliver the smallest feerate that ensures this feerate’s confirmation within the given time interval has a greater ratio throughout the whole confirmation time range.

To be specific, BCore will begin collecting transactions from the highest feerate bucket first, then add transactions from lower buckets until enough samples have been obtained. The success ratio of those selected transactions will then be calculated. If the ratio γ is greater than the success confirmation ratio p2, BCore will empty the current selected transaction collection and begin collecting sufficient samples from the next buckets (lower feerate bucket) until the ratio fails the test (p2 in Algorithm 2). BCore will examine the feerate in the last pass transaction collection if it fails the test. Finally, BCore will return the average feerate in the bucket u, which is where the median transaction count of the selected transaction collection is located.

5.2 Updates in Bitcoin Core post v0.15

There are four major changes in the algorithm after version 0.15:

– The feerate bucket interval is reduced to 5% from 10% to enable more accurate estimation.

– It can handle up to 1008 blocks of maximum expectation estimate interval. Meanwhile, the estimation process has become more complex. The estimation process is repeated over three time horizons: short history (targets up to 12 blocks), medium history

(targets up to 48 blocks), and long history (targets up to 1008 blocks).

– It provides two types of feerate estimate results. Conservative estimation use longer time horizons to produce an estimate which becomes less sensitive to sudden changes in fee conditions. Economical estimation use shorter time horizons and will focus more on the short-term changes in fee conditions.

– Transactions which leave the mempool due to eviction or other reasons are taken into account by the fee estimation logic in txUnCt.

5.3 Algorithm analysis

By examining the confirmation behavior of transactions in various feerate scales, BCore calculates the predicted feerate. When it comes to unconfirmed transactions in the mempool, however, it only considers those that have taken longer than expected. It ignores the competition from transactions with a lower wait time or that have just been submitted to the mempool. As a result, BCore may be oblivious of unexpected transaction fee change in the mempool, especially when a significant number of higher feerate transactions are submitted at once, resulting in severe confirmation competition.

Authors:

(1) Limeng Zhang, Swinburne University of Technology, Melbourne, Australia ([email protected]);

(2) Rui Zhou Swinburne, University of Technology, Melbourne, Australia ([email protected]);

(3) Qing Liu, Data61, CSIRO, Hobart, Australia ([email protected]);

(4) Chengfei Liu, Swinburne University of Technology, Melbourne, Australia ([email protected]);

(5) M.Ali Babar, The University of Adelaide, Adelaide, Australia ([email protected]).

This paper is available on arxiv under CC0 1.0 UNIVERSAL license.

[3] https://bitcoin.org/en/bitcoin-core/

[9] In Bitcoin Core prior to version 0.15, for example, the decay rate was set at 0.998.

[10] ϑmax = 24 in Bitcoin Core prior to version 0.15 and ϑmax = 1008 in the later version