BtcFlow: Modeling Bitcoin’s Mempool Dynamics to Predict Optimal Feerates

Table of Links

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

4 BtcFlow

BtcFlow[2] infers the transaction fee based on analysing the rate of transaction entering the mempool and transaction confirmation leaving the mempool within a given time interval. Specifically, it models the blockchain mempool as a container with an inflow pouring in (transaction submission) and an outflow flowing out at at a specified rate (transaction confirmation is assumed following a specific poisson distribution). The ultimate aim is to empty the container within the given time (the mempool is emptied with no unconfirmed transactions left). During the procedure, the estimated transaction feerate serves as a valve to regulate the input flow so that the container can be emptied within the given time.

\ In terms of data sources, the future inflow is simulated using the confirmed transactions in the Bitcoin blockchain, the outflow is calculated through a specified function, and the container begins with the unconfirmed transactions in the current mempool. Thus, the general estimation procedure of BtcFlow can be formulated as:

\

4.1 Estimation procedure

BtcFlow works under the assumption that transaction confirmation follows the rules that higher feerate transactions always have priority to be confirmed earlier than the lower ones. It means that when estimating the transaction fee, BtcFlow only needs to focus on estimating the minimum boundary feerate transactions which can ensure the unconfirmed transactions with higher feerates ( equal to or larger than the minimum fee rate) can be drained within the given time. The estimating process can be divided into two parts: The modelling process, which is designed to analyse the inflow stream, current container state, and the outflow stream of all feerate-range transactions in the given expected time interval, and The estimation process, which is used to generate the target transaction feerate based on the simulated data streams. The process is illustrated in Fig. 1 (and Algorithm 1).

\ – Modeling process. In this process, BtcFlow monitor three data streams of transactions in terms of their transaction feerates: (1) the submitted transactions entering the mempool (the inflow), (2) the unconfirmed transactions in the current mempool (the current container state), and (3) the confirmed transactions leaving the mempool (the outflow). Considering that the value of feerate is continuous, it is impractical to compare the transaction flow at each feerate scale. As a result, Btcflow makes

\

\

\ a trade-off between the accuracy of its estimations and the complexity of its computations. For simplicity, BtcFlow discretizes the original feerate scales into different integer scales (rounding up the original feerate value to the nearest integer). It means that BtcFlow models each flow on an integer scale.

\

\

\ – Estimation process. The estimation process is to find the minimum feerate to ensure the outflow stream of transactions with higher feerates exceeds (or equals) the input stream and current mempool states of the mempool. BtcFlow’s simulation on transaction confirmation in Equation (4) shows that the outflow confirmation is simply dependent on variables p and ϑ. In other words, the outflow O is constant for a given p and ϑ as shown in Equation (4). As Btcflow tests on lower feerate results, the inflow stream and mempool states involve more lower feerate transactions. The inflow and mempool states will eventually exceed the outflow. The feerate next to this border feerate will be returned by BtcFlow.

\ Basically, the transaction inflow volume I can be calculated as:

\

\ , which represents the increase volume in the mempool coming from higher feerates. The current mempool volume of higher feerates M is:

\

\

\

4.2 Algorithm analysis

By simulating newly submitted transactions entering the mempool, transactions in the mempool and transaction confirmation in the blockchain, BtcFlow returns the smallest feerate to ensure that the confirmation exceeds the inflow submission and current transactions in the mempool within the expected time interval. However, this model is faced with several limitations in its outflow modeling:

\ – It assumes that a size of BLOCK of higher-feerate transactions will be confirmed within a block interval. In fact, in the blockchain system, some smaller feerate transactions can also be confirmed in a block due to some reasons. In addition, the size of a block can be various in the blockchain and BLOCK is the upper bound of a block.

\ – The possibility parameter p can fail to work. BtcFlow calculates block generation using three different confidence intervals: ‘optimistic’, ‘standard’ and ‘cautious’ with the possibility parameter p ∈ {0.5, 0.8, 0.9}. In some cases, p may not work. According to the result for ϑ = 10 in Table 3, the estimated block count cϑ = 0 under p = 0.8 and p = 0.9, which means that p fails to control the accuracy of block generation as effectively as it should be.

\ – The assumption of a 10-minute block generation interval may be incorrect. In the Bitcoin blockchain system, the time it takes to generate a block varies.

\

\

:::info Authors:

(1) Limeng Zhang, Swinburne University of Technology, Melbourne, Australia ([e-mail]);

(2) Rui Zhou Swinburne, University of Technology, Melbourne, Australia ([e-mail]);

(3) Qing Liu, Data61, CSIRO, Hobart, Australia ([e-mail]);

(4) Chengfei Liu, Swinburne University of Technology, Melbourne, Australia ([e-mail]);

(5) M.Ali Babar, The University of Adelaide, Adelaide, Australia ([e-mail]).

:::

---

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

:::

[2] https://bitcoiner.live/