Table of Links
- Preliminaries
- Problem definition
- BtcFlow
- Bitcoin Core (BCore)
- Mempool state and linear perceptron machine learning (MSLP)
- Fee estimation based on neural network (FENN)
- Experiments
- Conclusion, Acknowledgements, and References
6 Mempool state and linear perceptron machine learning (MSLP)
MSLP [1] transforms the transaction fee problem into a classic binary classification problem, predicting whether a transaction can be confirmed within a specified timeframe based on its feerate. To be specific, MSLP first calculates an estimated confirmation time based on the mempool. The estimated confirmation time is then compared to the historical confirmation time in the blockchain. If the estimated confirmation time exceeds the recorded confirmation time, it means that this transaction can be confirmed earlier under this feerate. In other words, this charge assures that the transaction will be completed within the estimated confirmation time. Finally, MSLP uses the capabilities of a neural network to learn the confirmation result (success or failure). It focuses on transaction priority information in the mempool, as opposed to BtcFlow, which focuses on transaction feerate flow change in the mempool.
The prediction procedure can be formulated based on its data resources:
6.1 Estimation procedure
The estimation procedure as shown in Fig. 3 (and Algorithm 3) is composed of two phases: the training process and the estimation process. The training process is used to discover the inherent patterns among transaction confirmation time, current memepool, and the transaction feerate. In the estimation process, given the confirmation time, MSLP will return the transaction feerate to ensure confirmation based on the learnt patterns in the training process.
– Training process. In the mempool, unconfirmed transactions compete for confirmation in the blockchain. To highlight this competitiveness, MSLP coined the term ‘expectation confirmation time’ to represent the transaction processing priority. The unconfirmed transaction is treated by MLSP as a queue sorted by transaction feerate, and only a block of transactions (related to the fixed capacity of a block in the Bitcoin blockchain system) in this queue can be confirmed at a time. As a result, the expected confirmation time of a transaction is proportional to the number of blocks in the queue before it is processed. Meanwhile, certain other unseen elements may have an impact on the confirmation procedure. By training the model with history confirmation instances,
MSLP leaves the analysis of the intricate link between the expectation confirmation time, blockchain confirmation time, and transaction feerate to a neural network.
In fact, an unconfirmed transaction can generate several failure instances with hit = 0 before it is finally confirmed in the blockchain.
According to θ, after the testing instance is built, it will be transferred to the specific trained model. The feerate in this case is the estimated result from MSLP if the model returns hit = 1. Otherwise, MSLP will incrementally update feerate r′ in the testing instance until it returns hit = 1.
6.2 Algorithm analysis
MSLP achieves feerate estimation based on analysing the inherent patterns among the confirmation time, transaction ranking in the mempool, and the transaction feerate. Unfortunately, it fails to deliver an estimation result when the confirmation time exceeds the expected confirmation time, or when there are no previous training instances available for the associate training models.
These instances are common throughout the block generation process. Meanwhile, as the training process demonstrates, there is no clear differentiation between different block intervals. For example, cases with a block interval of 5 to 8 are used to train the same model ‘[5- 8]’. Another potential constraint is the use of block capacity in the assessment of expected confirmation time. Except for the geniue reward transaction from the Bitcoin blockchain system, a block in the blockchain can be empty with no unconfirmed transactions.
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