skip to main content
research-article
Open Access

On Optimizing Transaction Fees in Bitcoin using AI: Investigation on Miners Inclusion Pattern

Published:25 July 2022Publication History

Skip Abstract Section

Abstract

The transaction-rate bottleneck built into popular proof-of-work (PoW)-based cryptocurrencies, like Bitcoin and Ethereum, leads to fee markets where transactions are included according to a first-price auction for block space. Many attempts have been made to adjust and predict the fee volatility, but even well-formed transactions sometimes experience unexpected delays and evictions unless a substantial fee is offered. In this article, we propose a novel transaction inclusion model that describes the mechanisms and patterns governing miners decisions to include individual transactions in the Bitcoin system. Using this model we devise a Machine Learning (ML) approach to predict transaction inclusion. We evaluate our predictions method using historical observations of the Bitcoin network from a five month period that includes more than 30 million transactions and 120 million entries. We find that our Machine Learning (ML) model can predict fee volatility with an accuracy of up to 91%. Our findings enable Bitcoin users to improve their fee expenses and the approval time for their transactions.

Skip 1INTRODUCTION Section

1 INTRODUCTION

Blockchain protocols, like Bitcoin and Ethereum, secured in mid-2020 about 80% of the cryptocurrency market cap [55]. Most of the current blockchain implementations that use a permissionless Proof-of-Work (PoW)-based chain, come with some non-negligible side effects. Besides their substantial environmental impact [39], they suffer from a non-trivial scalability problem: the low throughput (transactions approved per second) [11, 30, 41, 43]. The substrate consensus protocol (Proof-of-Work (PoW)) limits the throughput upper bound with two important parameters: the block size (time constraint), and the interblock interval time (frequency constraint). Changes to either of those two parameters to improve throughput demand proportional improvement in the block-propagation time, which is limited by the current P2P network substrate [3, 30].

The Bitcoin system was intended to provide users with a low-cost payment scheme, with transaction fees close to or equal to zero [37]. In a tragedy of the commons, the cryptocurrency’s rising popularity made the physical throughput limitations of the underlying PoW scheme a key scalability bottleneck [13, 42]. The high cost of mining has led to an increased usage of transaction fees as a means for miners to make a profit.

Transaction fees and the behavior of miners became a relevant subject of study after the affirmation of Bitcoin as the primary cryptocurrency. The trend of a long-established PoW-based blockchain started to move towards a fee-oriented market [36], where a rational (or greedy) miner aims at optimizing its profits by following a certain norm while selecting new incoming transactions from its mempool. This is known as the fee-per-bytes dequeuing policy, where transactions are being scheduled for inclusion according to their feerate. While fee predictors still adopt the notorious fee-per-bytes dequeuing policy, miners somehow deviate from the norm [35]. This has some serious economic implications for users, fee-overpaying is rather the norm and first-price auction markets have failed to provide users with stable prices [7].

Deciding on a common static fee is impossible in practice [27, 36], and users are instead forced to either choose an appropriate payment dynamically or rely on current fee estimators when submitting their transactions, with no exact formula to optimize expenditure or to control the time it takes for a transaction to be confirmed [54]. Most users end up using their own estimator based on their own intuition [40]. This turns out to be a very difficult task, and in most cases expensive for users [6]. Furthermore, many existing estimators have the notorious problem of aggregate overpaying, while adopting a higher fee than necessary [19]. In 2017, poorly designed fee estimators contributed to driving up average Bitcoin fees to over $ 20 per transaction [40, 47].

The strategic behavior of miners and users over time made the role of transaction fees in Bitcoin change from a mining-based structure to a market-based ecology [16]. This makes PoW-based blockchain systems unpredictable at scale. Thus, their non-deterministic outcome for transaction fees induces blockchain-based cryptocurrencies to not be suited in the near future, as a global, shared, and decentralized currency. The outcome of such systems must be predictable, and the risk of overpaying should be reduced to zero.

Enhancing our knowledge of how Bitcoin’s first-price auction and transaction fee mechanisms work in practice is important to make such systems more useful and predictable under various network congestion circumstances or independently of the fees paid by other users. In this article, we, therefore, propose a novel transaction inclusion model that describes the fee-market mechanisms of the Bitcoin system. We show how the overpaying problem is a consequence of miners’ rational (and unexpected) behaviors, define the concept of fee market, and outline its main side effects. Using our transaction inclusion model we devise a Machine Learning (ML) approach based on Deep Neural Networks (DNNs) that can predict miners’ behavior while selecting new transactions for inclusion. We evaluate our prediction method using historical observations of the Bitcoin blockchain from a five month period that includes more than 30 million transactions and 120 million entries. Our findings enable Bitcoin users to improve their fee expenses and approval time for their transactions.

The main contributions of this article are as follows:

A formal definition of a transaction inclusion model (or pattern).

A dataset containing Bitcoin transactions sampled every month, from January 2021, until May 2021 [46].

A multi-layer Neural Network (NN) model to predict the pattern we formalize in this article.

The remainder of the article is organized as follows. In Section 2, we describe related works, including studies on transaction fees and miners’ behavior. We also analyze relevant works on ML models for pattern prediction. In Section 3, we describe the Bitcoin fee market, its purpose for the users, and how miners’ rational behavior relates to overpayment. Next, our transaction inclusion model is described in Section 4, its implementation is explained in Section 5, and the evaluation is presented in Section 6. Section 7 discusses our findings and Section 8 concludes.

Skip 2RELATED WORKS Section

2 RELATED WORKS

The high fee issue in Bitcoin is well known. Already in 2014 the study of Kaskaloglu [29] claims that an increase in transaction fees of Bitcoin is inevitable, and they identify the reasons to be: (1) cost of mining, (2) risk of 51% attack. The study also discusses the parameters affecting the problem of determining the right fee for Bitcoin, and it considers how these parameters are changing in a dynamic ecosystem of miners, investors, and users of the Bitcoin network. Later studies started to analyze miners’ behavior with respect to transaction fees. In 2015 Möser and Böhme [36] acknowledge the role of fees as a key aspect of the system’s stability. They provide empirical evidence of agents’ behavior concerning their payment of transaction fees, together with several regime shifts, caused by changes in the default client software. The study shows the trend of a long-established PoW-based blockchain, moving towards a fee-oriented market.

As fees increase, miner behavior become an interesting subject of study and research. In 2019, the study of Basu et al. [7] outlines that first-price auction markets have failed to provide users with stable prices for their services, and historical analysis shows that Bitcoin users could have saved $ 272,528,000 in transaction fees, while miners could have reduced the variance of fee income by an average factor of 7.4 times. Furthermore, the study of Messias et al. [35] shows that miners somehow deviate from the first-price auction norm, while fee predictors still adopt the notorious fee-per-bytes dequeuing policy. This has some serious economic implications for users; fee-overpaying is rather the norm, and Messias et al. [35] show that in June 2019 more than \( 30\% \) of transactions were offering a feerate two orders of magnitude higher than the minimum recommended.

Improving on the current first-price auction in the Bitcoin environment is neither a simple nor straightforward matter, and the study of Basu et al. [7] outlines how the design of such a mechanism is challenging. As a matter of fact, miners can use any criteria for including transactions and can manipulate the results of the auction after seeing the proposed fees. Basu et al. [7] introduce a mechanism inspired by a generalized second-price (GSP) auction which identifies a bidder willing to pay only more than the (K + 1)-th highest bid, where K is the number of transactions included in a block. Another version of the GSP auction model is presented by Li et al. [31], ,32], where they use a novel rank-by-cost rule to order transactions. The cost is calculated by the user-submitted fee and the waiting time. With this approach, they show that the daily saved fees for users are up to B 24.5985 on average. Our study will take the Generalized Second Price (GSP) approach into account since we include a relative time-bound notion of transaction, based on block-epoch, which tells how much a transaction is waiting to be approved.

Easley et al. [16] investigate the role that transaction fees play in the Bitcoin blockchain, changing from a mining-based structure, to a market-based ecology. They examine exogenous and endogenous features of Bitcoin. They show how waiting times arise and how they are influenced both by endogenous transactions fees and by exogenous dynamic constraints imposed by the Bitcoin protocol. Furthermore, they highlight how exogenous structural constraints influence the dynamics of user participation on the blockchain. Such features make a PoW-based blockchain system unpredictable at scale, the uncertainty of non-inclusion for transactions makes their issuers insecure, potentially causing overpaying. In their work, they argue that increasing transaction fees will increase the number of miners, but this, in turn, will trigger increases in the difficulty level to control the creation rate of new blocks, thereby raising the costs to miners. More revenue does not necessarily mean more profit, and in a competitive market, this would not lead to an overall increase in compensation. Finally, they argue that transaction fees alone are unlikely to solve the challenges facing the Bitcoin blockchain. This is the reason why our approach offers an alternative by considering fees as one of the means for transaction inclusion.

The use of ML models to predict patterns from large sets of data has been already adopted. From hydrology [14] to network attacks [38], and finally the work of Yazdinejad et al. [52] utilizes a large amount of data for hunting cryptocurrencies malware threats. When we analyze the pattern for transaction inclusion we deal with an enormous amount of heterogeneous data, and we need to establish an order out of it. A ML-based approach enables us to make predictions and decisions using sample data (training data). They are widely used by enterprises in different sectors, i.e., education [5, 33], business and marketing [8, 12], healthcare [9, 15], financial services [44, 49], and transportation [34, 53]. An important prerequisite to train an ML model is to have a large and diverse dataset. The public and well-established Bitcoin blockchain fits perfectly for this purpose.

Skip 3THE FEE MARKET IN BITCOIN Section

3 THE FEE MARKET IN BITCOIN

Bitcoin can transition from its current operational mode where transactions fees are, in practice, no more than a complementary tip to the miners, to a situation where a fee market effectively regulates all traffic. With such a fee market, low-fee transactions might potentially remain pending for hours, days, or even weeks waiting for approval and inclusion by a miner. As the energy demands of the Bitcoin network increase and mining becomes more expensive, a transition to such a fee market becomes more evident.

Bitcoin is highly energy inefficient by design. Its PoW scheme secures records in the blockchain only after a certain amount of computational work has been carried out by the prover (or miner). This mechanism is however essential as it prevents double-spending and Sybil attacks. This work must be hard—yet feasible—on the miner side, but easy to check for the verifier as a form of a nondeterministic polynomial time (NP) decision problem. In Bitcoin, the prospect of making profit via mining has built up the common interest in joining the PoW protocol. However, a set by-design parameter such as the interblock time interval,1 made any speed up in the mining process—which would cause more revenue—impossible, despite the network hashing power increasing. As a consequence, mining became more expensive and miners needed to reshape their way of making profits.

Each mined block has an expected profit \( \color{#005596}{\langle II\rangle} \) (Equation (1)), where \( \color{#005596}{\langle V\rangle} \) is the expected revenue for mining (Equation (2)), and \( \color{#005596}{\langle {C}\rangle} \) (Equation (3)) are the expenses, or cost of mining [42]. (1) \( \begin{align} \begin{split} \color{#005596}{\langle II\rangle} &= \color{#005596}{\langle V\rangle} - \color{#005596}{\langle {C}\rangle} , \end{split} \end{align} \) (2) \( \begin{align} \begin{split} \color{#005596}{\langle V\rangle} &= (R + M)\frac{h}{H}(1 - \color{#005596}{{\mathbb {P}}_{orphan}}), \end{split} \end{align} \) (3) \( \begin{align} \begin{split} \color{#005596}{\langle {C}\rangle} &= \color{#005596}{\eta}{h} \color{#005596}{{\cal T}}. \end{split} \end{align} \) Miners’ revenue \( \color{#005596}{\langle V\rangle} \) is inversely proportional to the total hashing power of the Bitcoin network H, but directly related to three main factors: the reward and transaction fees (\( R + M \)), the individual hashing power (h), and the probability of not orphaning2 the block just mined (\( 1 - \color{#005596}{{\mathbb {P}}_{orphan}} \)). The reward R for mining a block is, as of writing, B 6.25. The value M represents the sum of all the transaction fees included in the mined block. Increasing the number of miners will substantially increase H, and consequently it will reduce \( \color{#005596}{\langle V\rangle} \). Miners’ expenses \( \color{#005596}{\langle {C}\rangle} \) are directly proportional to the individual hashing rate (h), the cost per hash (\( \color{#005596}{\eta} \)), and the expected time to mine a block (\( \color{#005596}{{\cal T}} \)). It is evident that the system becomes more expensive for miners as the number of them scales up, and the inherent throughput limitation of the system causes new incoming transactions to compete for space in the blocks, as the number of transactions scales up. Because of that, miners can change their behavior for transaction inclusion, in a profit-oriented manner.

The nontrivial scalability problem in Bitcoin, and its scalability bottleneck, resides in the low throughput.3 It depends directly on two factors: (1) the block size Q, and (2) the interblock interval time \( \color{#005596}{{\cal T}} \), which allows approximately from three to seven transactions per second. This upper bound is hindered by an exogenous property known as difficulty (Equation (4)). The difficulty raises or drops in order to maintain a target block creation time of \( {\cal T}\simeq 600 \) sec, and it is normalized according to \( {\cal T}^{\prime } \), which is selected as the mean value of the past 2,016 block creation times. Equation (4) defines difficulty \( d_x \) at block height x. Because \( {\cal T} \) is fixed, in order to avoid this throughput bottleneck one remedy is to increase the block size Q. Unfortunately, the blockchain’s distributed nature does not allow to arbitrarily change either of these parameters [30], and miners have the hallowed power to unilaterally order and select transactions [28]. Furthermore, because the network is congested most of the time [35], this creates a competition for transaction inclusion, that escalates in a first-price auction market. (4) \( \begin{gather} d_x = {\left\lbrace \begin{array}{ll} 1 & \text{if } x=0\\ d_{x-1} \color{#005596}{{{\cal T}}}{\color{#005596}/{{\cal T}}^{\prime }} & \text{if } x \gt 0. \end{array}\right.} \end{gather} \) In Equation (2) we see that a miner’s profit depends on R and M. The block reward R is halved every 210,000 blocks, leaving M—the sum of transaction fees—the only reliable source of profit left in the long term. In a first-price auction market, a bidder tries to raise his bet in order to beat any other competitor. In absence of any other source of profit, transaction fees are competing with each other as bidders in a first-price auction market. The well-known adopted strategy by miners to choose a bidder, is the fee-per-bytes dequeuing policy, and it is widely considered to be the norm for prioritizing transactions [35]. In this policy, transactions are ordered by their feerate—transaction fee divided by its size in bytes (Equation (6))—and then included accordingly. However, Eyal and Sirer [18] show that the Bitcoin mining protocol is not incentive-compatible. Greedy miners can benefit from a first-price auction scheme while the burden is being borne by users. The individual competition of a first-price auction scheme is harmful for Bitcoin, where its market design engages K identical items to be sold—K number of transactions included in the next mined block—to bidders who each want one item at most. The study outlines how a GSP auction market could benefit user expenditures. In this scheme, the K highest bids each win an item (inclusion in a block) and bidders all pay the (K + 1)-th highest bid. If fee estimators use the first-price auction mechanism to calculate transaction fee then overpaying is likely to occur.

A first-price auction market is demonstrably unsuitable for large-scale blockchains based on PoW. The market does not provide a stable coin price, so transaction fees are unpredictable and their variance is enormous, capacity and demand do not always meet, forcing users to overpay for their space in the block, to avoid being left out. We consider two main issues coming from the fee market legacy: fees unpredictability, and users overpaying. Our purpose is to build a model which defines a transaction inclusion pattern, based on ML techniques such as multi-layer Neural Network (NN). The model wants to track both the block size and the mempool size, therefore it lies outside the group of first-price auction predictors. Furthermore, we include features which are not fee-based, so that the model does not rely its knowledge on a second-price auction scheme alone.

Our previous study shows that it is possible, using ML techniques, to analyze and define patterns in big data [48], and the public and well-established Bitcoin blockchain fits perfectly for our purpose. The new proposed model is able to make a binary decision on transaction inclusion—will a transaction be included in the next mined block?—thanks to some carefully chosen engineered features, based on assumptions we make in Section 4.

Skip 4TRANSACTION INCLUSION MODEL Section

4 TRANSACTION INCLUSION MODEL

Here we analyze, define and present our model for transaction inclusion. In Section 4.1, we explain how transaction data is treated, and why we base our observations on a time-series-like approach. Consequently, we analyze two main factors that can alter inclusion. We call them revenue (Section 4.2) and fairness (Section 4.3), and they serve to ensure an equilibrium of user’s and miner’s participation. These two definitions are complementary for an accurate study and prediction, therefore the holistic view for transaction inclusion is to be sought in both fairness and revenue concepts.

4.1 Observational Approach

Time-series data analyses have proven to be useful for predicting future trends [20, 21, 22, 24, 45, 51]. Our observational approach follows a methodology that strongly depends on time-series data collection, since we sample Bitcoin transactions monthly with a fixed interval, although we add a notion of relative time to it: the block creation. The idea is that a transaction carries different information throughout the time that it is pending, and therefore our approach follows a block-epoch-based collection, where a transaction changes part of its carried information every time there is a block creation. The relative time interval is then defined between two block creation epochs. Each record t (or transaction), at time x, is uniquely identified with the pair \( (\color{#005596}{ha_t}, \color{#005596}{be_x}) \), as the hash of t and the block time epoch at height x. We refer to a transaction t at height x as \( t^{(x)} \), and this represents an instance of the transaction t during the time slot \( [be_x, be_{x+1}] \). For this study, we want to track transactions over time to have information about network saturation and waiting time at each block epoch. In order to delineate the time slots used for the analysis, we define the timeline-set \( \color{#005596}{{\mathbb {T}}} \), which contains all the block time epochs. We consider a transaction lifespan \( \mathcal {L}(t) \) as the time in seconds that goes from the moment the first node sees t (\( \color{#005596}{ep_t} \)), until t is included in a mined block. If the mined block is at height x, then we define \( \mathcal {L}(t) \) as \( \color{#005596}{\mathcal {L}_t^x} \). A transaction \( t, \) therefore, has as many occurrences in our local dataset as the number of blocks it sees before being included. We define \( \color{#005596}{{\mathbb {T}}} \), \( \color{#005596}{\mathcal {L}_t^x} \), and the number of t occurrences in a dataset (\( \gamma \)) in Equation (5). (5) \( \begin{equation} \begin{split} \color{#005596}{{\mathbb {T}}} = \lbrace be_i | 0 \le i \le \color{#005596}{\xi} \rbrace , \quad & \text{where } \color{#005596}{\xi} = \text{max(block height)}, \\ \color{#005596}{\mathcal {L}_t^x} = [\color{#005596}{ep_t}, \color{#005596}{be_x}], \quad & \text{if $t$ is included at height } x, \\ \gamma = |\lbrace be| be \in \color{#005596}{{\mathbb {T}}} \cap \color{#005596}{\mathcal {L}_t^x}\rbrace |, \quad & \text{number of $t$ occurrences}. \end{split} \end{equation} \)

4.2 Revenue for Miners

Difficulty is an exogenous property of Bitcoin. It grows in relation with the total network hashing power H, and it makes scaling of miners extremely expensive.4 The blockchain is secure if a set of malicious miners has less computational power than the honest nodes together, putting Bitcoin security directly proportional to the growth of H. A high degree of security then hinders a low and cheap maintenance scheme for miners, low transaction fees, and therefore a deterministic outcome of the system. Consequently, we conjecture that a miner’s main purpose is its revenue.

Referring to Equations (2)–(3), revenues get lower as H increases. A miner then could either: (1) reduce its costs, (2) increase its hashing power h, (3) reduce chances of orphaning \( \color{#005596}{{\mathbb {P}}_{orphan}} \), (4) increase the amount of fee it gets (\( M+R \)). In order to reduce the miner’s costs, the exogenous properties \( \color{#005596}{{\cal T}} \) and \( \color{#005596}{\eta} \) cannot be changed,5 so that a miner should decrease its hashing power, which would conflict with point 2. The probability of block orphaning depends on the block propagation delay, which is affected by the block size [11]. A rational miner could make its blocks lighter in order to spread faster to reduce orphaning rate. However, this only partially increases the revenue, since fewer transactions means less fee as reward, besides decreasing the overall network throughput. Furthermore, orphaning rate has been calculated to occur only three times every 1,000 blocks,6 so it has little impact on miner revenue. If we now consider that R is halved every 210,000 blocks, then M is the only source of profit left. Most miners are assumed to behave rationally [2], implementing individualized and unknown policies for transaction inclusion that aim at maximizing their profit. Because miners can arbitrarily select transactions, revenue is their purpose and the sum of transaction fees is their main endogenous source of profit, we assume that a transaction is selected rationally, and its inclusion strongly depends on its fee.

Although we consider transaction fees to play a key role in inclusion, the concept of revenue does not refer exclusively to that. While inserting transactions into a block, every miner increases its possible revenue, but it also decreases his block propagation rate, which undermines the probability to earn any reward at all. In fact, the time needed for propagation in order to reach consensus among participants depends on block size [26]. If the block size Q is fixed to 1 MB, then a rational miner might attempt to optimize the number of transactions paying more fee within Q, by calculating the ratio between transaction fee \( \color{#005596}{\phi} \) and transaction size q, called feerate (\( \color{#005596}{\rho} \)) (Equation (6)). Dequeuing feerate policy is generally considered to be the norm [35] among miners, and we assume that feerate is the bedrock of miners’ revenue. (6) \( \begin{equation} \color{#005596}{\rho} = {\color{#005596}/{\phi} }\color{#005596}{{q}}. \end{equation} \) Despite many fee estimators include feerate in their evaluations,7 they still fail to avoid overpaying. Analyses show [35] that on average, \( 50\% \)–\( 70\% \) of transactions offer feerates two orders of magnitude higher than the recommended minimum,8 and that \( 88\% \) of all Bitcoin transaction inputs pay higher fees than necessary [17]. Because of this, we conjecture that revenue is not the only metric to study and analyze. We assume that a miner also needs to be fair and give space to those transactions that are waiting for a longer time, in order to maintain system sustainability.

4.3 Fairness for Users

The concept of fairness considers those transactions that, upon payment of a fee, are waiting unfairly long because some newer, higher-fee transactions joined the network. To explain this view we define the set \( \color{#005596}{\mathcal {P}} \) (Definition 4.2) as the set of relapsed pending transaction (RPT). We define the block-before-inclusion (\( \color{#005596}{\beta _t} \)) in respect of a transaction t, as the epoch of the last block, mined before t’s inclusion. If the latest block epoch is represented as \( \color{#005596}{be_\xi} \), where \( \xi \) is the last block height, this results in: (7) \( \begin{gather} \color{#005596}{\beta _t} = {\left\lbrace \begin{array}{ll} be_{x-1}, &\text{if } t \text{ is included in block at epoch } \color{#005596}{be_x}, \\ \color{#005596}{ be_\xi} , &\text{if } t \text{ is yet to be included.} \end{array}\right.} \end{gather} \) We also extend the block-before-inclusion concept to the block-epoch approach, and the \( \color{#005596}{\beta _t} \) at height x for a transaction \( t^{(x)} \) is \( \color{#005596}{\beta _t}^{(x)} = be_{x} \), where for height x we always refer to the time slot \( [be_x, be_{x+1}] \). It is important to define in our model the principle of fairness since a transaction cannot wait forever for approval, upon payment of a rightful expected fee.

Definition 4.1.

\( \color{#005596}{\mathbb {F}}[f] \) The expected fee value is the amount of fee a transaction should pay according to its size q, if we consider the minimum feerate requirements of 1 sat/byte. (8) \( \begin{equation} \color{#005596}{\mathbb {F}}[f] = \color{#005596}{\rho} ^{\prime } \color{#005596}{q}, \text{ where } \color{#005596}{\rho} ^{\prime } \ge 1 \text{ sat/byte}. \end{equation} \)

We now assume that if a rational miner is fair, it does not only include transactions with a high feerate, but it also considers those in the set \( \color{#005596}{\mathcal {P}} \).

Definition 4.2.

\( \color{#005596}{\mathcal {P}} \) We identify \( \color{#005596}{\mathcal {P}}^{(y)} \) as the set of relapsed pending transaction (RPT) at height y. The set contains transactions that in their lifespan (included at \( be_y \)), have seen at least one block creation, have not been included up until height y, and have a fee equal or greater than the expected one, such that: (9) \( \begin{equation} \begin{split} \mathcal {P}^{(y)} = \lbrace t|\color{#005596}{ep_t}& - \color{#005596}{\beta _t}^{(y)} \lt 0 \quad \wedge \\ & be_y \lt \color{#005596}{be_x},\text{ if } \mathcal {L}(t) = \color{#005596}{\mathcal {L}_t^x} \quad \wedge \\ &\color{#005596}{\phi _t} \ge \mathbb {E}[f_t]\rbrace . \end{split} \end{equation} \)

We say t is an relapsed pending transaction (RPT) transaction at height x, if \( t^{(x)}\in \color{#005596} {\mathcal {P}}^{(x)} \).

We consider a more generic definition of \( \color{#005596}{{\mathcal P}} \) as the union of all the block-epoch-based \( \color{#005596} {\mathcal {P}} \)-sets: \( \bigcup _{i=0}^{\xi }\color{#005596} {\mathcal {P}}^{(i)} \). Following this concept, we assume that, when a transaction appears multiple times in \( \color{#005596} {\mathcal {P}} \), it will have more chances of being included in the next mined block.

4.4 Model Formalization

An efficient transaction inclusion model should consider the aforementioned concepts and it should monitor, at the time of training and testing, the current network state. For this purpose, it is important to keep track, of each transaction analyzed, its moment of inclusion in a new block. The set \( \color{#005596}{{\cal A}} \) contains temporarily approved transactions (TATs) (Definition 4.3). The latter is useful in phases of training and testing, in order to have knowledge of when a transaction is about to be included, monitoring at the same time any other type of information carried by such a transaction.

Definition 4.3.

\( \color{#005596}{{\cal A}} \) We identify \( \color{#005596}{{\cal A}}^{(y)} \) as the set of TAT at height y. The set contains all the yet-to-be-included transactions that are selected for inclusion at height y, during \( [be_y, be_{y+1}] \) time slot, and included then at height \( y+1 \). We say t is a temporarily approved transaction (TAT) at height y if \( t^{(y)} \in \color{#005596}{{\cal A}}^{(y)} \). (10) \( \begin{equation} {\color{#005596}{\cal A}}^{(y)} = \big \lbrace t| \mathcal {L}(t) = \mathcal {L}_t^{y+1}\big \rbrace . \end{equation} \)

Figure 1 shows two instances of a block-epoch-based transaction, \( t_1 \) and \( t_2 \), initiated by User 1 and User 2, respectively. Transaction \( t_1 \) carries different information according to where it is located, and we name it differently, e.g., \( t_1^{(x-2)}, t_1^{(x-1)}, \) and \( t_1^{(x)} \). The belonging of \( t_1 \) and \( t_2 \) to sets \( \color{#005596}{{\cal A}} \) and \( \color{#005596}{\color{#005596} {\mathcal {P}}} \) changes over time, and we formalize it in Equations (11) and (12). Considering that lifespan for \( t_1 \) is \( \mathcal {L}(t_1) = \mathcal {L}_{t_1}^{x+1} \), then: (11) \( \begin{equation} \begin{split} t_1^{(x-2)} &\quad \notin \color{#005596} {\mathcal {P}}^{(x-2)} \wedge \notin \color{#005596}{{\cal A}}^{(x-2)}, \\ t_1^{(x-1)} &\quad \in \color{#005596}{\mathcal {P}}^{(x-1)} \wedge \notin \color{#005596}{{\cal A}}^{(x-1)},\\ t_1^{(x)} &\quad \in \color{#005596}{\mathcal {P}}^{(x)} \wedge \in \color{#005596}{{\cal A}}^{(x)}. \end{split} \end{equation} \) Similarly, since lifespan for \( t_2 \) is \( \mathcal {L}(t_2)=\mathcal {L}_{t_2}^{x} \), we have: (12) \( \begin{equation} t_2^{(x-1)} \quad \notin \color{#005596}{\mathcal {P}}^{(x-1)} \wedge \in \color{#005596}{{\cal A}}^{(x-1)}. \end{equation} \)

Fig. 1.

Fig. 1. Two different transactions, \( t_1 \) and \( t_2 \) , issued at time \( ep_{t_1} \) and \( ep_{t_2} \) , having different lifespan. \( t_1 \) will be included in the third block after its inception, at height \( x+1 \) , while \( t_2 \) will be immediately included at height x. The number of \( t_1 \) occurrences we represent is then \( \gamma = 3 \) , while \( t_2 \) has \( \gamma = 1 \) occurrence.

As can be observed in Section 4.2, each miner tries to optimize their profit by including transactions with a higher feerate first, and this is also widely accepted to be the norm. A rational miner will then order pending transactions by feerate (\( \color{#005596}{\rho} \)). Our transaction inclusion model must take that into account, so we define the ordered set of pending transactions S, formalized in Definition 4.4.

Definition 4.4.

S We define S at block height x as the set of ordered pending transactions, \( \color{#005596}{S^{}(x)} \). The set includes all non-approved transactions at time \( \color{#005596}{be_x} \), ordered by their feerate in ascending order, formally: (13) \( \begin{equation} \begin{split} \color{#005596}{S}^{(x)} = & \big \lbrace t|\mathcal {L}(t) = \mathcal {L}_t^y \wedge \color{#005596}{ep_t} \lt be_{x+1}\big \rbrace , \quad \forall y \gt x, \\ \color{#005596}{S}^{(x)}= & [t_1, t_2, \dots t_n] \quad \text{is an ordered set,} \\ \text{where }&\rho _{t_1} \le \rho _{t_2} \le \dots \le \rho _{t_n}. \end{split} \end{equation} \)

Our model uses information about sets \( \color{#005596}{\mathcal {P}} \), \( \color{#005596}{{\cal A}} \), and S to make decisions on transactions inclusion. Knowledge on revenue and fairness (Sections 4.24.3) from sets \( \color{#005596}{\mathcal {P}} \) and S is fundamental to determine whether or not a transaction belongs to the set \( \color{#005596}{{\cal A}} \) over time. The model uses information from the aforementioned sets, to obtain new features through a process of feature extraction (Section 5.2). Figure 2 shows how the \( \color{#005596}{\color{#005596}{\mathcal {P}}} \) \( \color{#005596}{{\cal A}} \) S ecosystem changes during time, and it considers five different transactions carrying contrasting feerate values. In the next section, we explain data retrieval, elaboration, and features engineering, and we finally build and test the model for transaction inclusion.

Fig. 2.

Fig. 2. We consider a subset of transactions, \( \lbrace t_1, \dots , t_5\rbrace \) , from time \( be_{x-3} \) to \( be_{\xi } \) , to graphically show their path towards inclusion and their belonging in \( \color{#005596}{\mathcal {P}} \) , \( \color{#005596}{{\cal A}} \) , and S sets. Transactions are inserted in the mempool upon their inception, they carry information about their feerate, and in different time-epochs they can belong or not to the sets we have defined. In S, transactions are ordered by feerate, \( \color{#005596}{\mathcal {P}} \) gives a relative time-view of how long they are waiting, and finally, they belong to \( \color{#005596}{{\cal A}} \) if they are about to be included.

Skip 5METHODOLOGY Section

5 METHODOLOGY

We store data locally to have an instance of the Bitcoin blockchain always accessible and save on average up to \( 68\% \)9 of the disk space required, by removing redundancies, keeping the essential information for predictions, and adding newly extracted features. We collect data using third-party Application Programming Interfaces (APIs)10 and gather information about money exchange prices with forex-python11 libraries. Furthermore, we collect information to verify data correctness by setting up our own node using Bitcoin Core.12 Once data is retrieved and relevant information based on revenue and fairness is stored, we extract new features, and we perform supervised classification using a Deep Neural Network (DNN) model, making it possible to analyze a considerable part of the blockchain with little up-front investment in computational resources. We divide this Section into Data Acquisition (Section 5.1), Feature Selection and Extraction (Section 5.2), and Prediction Model (Section 5.3).

5.1 Data Acquisition

Retrieving data from Bitcoin Core can often be cumbersome and time-consuming. The process of calculating transaction fees, for instance, is intricate and it requires checking all the spent outputs in different transactions, due to Bitcoin being based on the Unspent Transaction Outputs (UTXO) model. Using the procedure listed in Algorithm 1, it takes on average 30 seconds to fetch information about fees contained in a single block. We have developed our own system for data retrieval, Blockchain Analytics System (BAS), built over a Python back-end. In BAS, transaction fees are obtained using APIs from blockchain.com , which is faster than using Bitcoin Core13 and more convenient for our purpose. Blockchain Analytics System (BAS) fetches and stores only targeted data, which makes it faster than retrieving or querying the entire blockchain. Furthermore, it saves resources up-front, making data more accessible for future queries.

Figure 3 shows the data process in BAS from the blockchain to the ML model. Data is retrieved using third-party APIs10 and our Bitcoin Core node running on Azure. JavaScript Object Notation (JSON) messages compose most of the data exchange from data sources to the ingestion engine, and whenever data is missing, raw HyperText Markup Language (HTML) data is fetched and parsed. Data are then processed in the ingestion engine and saved locally in the data storage using Pandas [4]. While data are being processed, the ingestion engine/pre-processing is selecting/extracting features which are eventually stored locally as NumPy text files [50], and used as training sets for the ML model, which uses a TensorFlow [1] back-end with Keras [10] modules. We will discuss which features are selected and why in Section 5.2.

Fig. 3.

Fig. 3. Data flow in BAS, from the blockchain to the ML framework. \( \color{#005596}{\mathcal {R}} \) , \( \mathcal {C} \) , and \( \mathcal {X} \) represent different datasets. The first indicates raw data extracted from the blockchain, the second represents a complete, run-time only dataset, while the third one includes all training data.

Our local data view separates blocks and transactions, such that their information is stored in different datasets. This is to avoid redundancies and to save disk space, since some block information is deep-seated in every transaction, and therefore, repeated thousands of times in one single block. Hence, we consider \( \color{#005596}{\mathcal {D}_t} \) and \( \color{#005596}{\mathcal {D}_B} \) as datasets containing, respectively, raw transactions and raw blocks, meaning that information is stored as it was fetched, before being elaborated or engineered. Every transaction is linked to a block with a many-to-one relation using block hash (ha) as unique key, \( r : \color{#005596}{\mathcal {D}_t} \rightarrow \color{#005596}{\mathcal {D}_B} \) where \( \forall ha^{\prime }\in \color{#005596}{\mathcal {D}_t} \exists ha^{\prime \prime }\in \color{#005596}{\mathcal {D}_B} \text{ st } ha^{\prime } = ha^{\prime \prime } \). We then construct the raw dataset as \( \color{#005596}{\mathcal {R}} = \color{#005596}{\mathcal {D}_B} \bowtie \color{#005596}{\mathcal {D}_t} \). Each row of \( \color{#005596}{\mathcal {R}} \) represents an instance of a raw transaction t, at time of its approval. Each column in \( \color{#005596}{\mathcal {R}} \) identifies values of a specific feature, and a column key, represented as \( k_i \), is the feature name at i-th position. We consider \( K_{\mathcal {R}} \) (more generically K) to be the set containing all the keys in \( \color{#005596}{\mathcal {R}} \).

5.2 Feature Selection and Extraction

The feature engineering process is based on fairness and revenue concepts outlined in Section 4. We distinguish between feature selection and extraction and refer to the former as a subset of attributes already present at the time of fetching (e.g., transaction size), while the latter are generated during the pre-processing phase. They are intended to be informative and non-redundant, facilitating the subsequent learning and generalization steps in order to determine a transaction inclusion pattern. Ingestion engine and pre-processing create a local, run-time only, version of \( \color{#005596}{\mathcal {R}} \), which we call complete dataset \( \mathcal {C} \). Each row of \( \mathcal {C} \) represents an instance of a feature vector \( {\bf{\texttt{t}}} \), which identifies a transaction during a well-defined time slot. We define then T as the complete block-epoch-based representation of a transaction \( t \in \mathcal {R} \), since it contains information belonging to the same transaction for its entire lifespan \( \mathcal {L}(t) \).

Definition 5.1

(Feature Vector).

A feature vector \( {\bf{\texttt{t}}} \) is a list of keys (k) that identify a block-epoch-based transaction T in a specific time slot, and it is defined as \( {\bf{\texttt{t}}} = [k_1, k_2, \dots , k_n] \) with \( |K| = n \).

Definition 5.2

(Complete Transaction T)

A Multivariate Time Series (MTS) \( \color{#005596}{T} = [{\bf{\texttt{t}}} _1, {\bf{\texttt{t}}} _{2},\dots , {\bf{\texttt{t}}} _{\gamma }] \) is an ordered set of feature vectors \( {\bf{\texttt{t}}} \), and consists on \( \gamma \) different univariate time-series with \( {\bf{\texttt{t}}} \in \mathbb {R}^n, \forall {\bf{\texttt{t}}} \in \) T, and \( |K|=n \).

\( \mathcal {C} \) is used to create the training/test datasets \( \mathcal {X} \), where \( |\mathcal {C}| \gt |\mathcal {X}| \gt |\color{#005596}{\mathcal {R}}| \) and \( K_{\mathcal {X}}\subset K_{\mathcal {C}}\subset K \). To extract new features we apply a function to some values in the feature set K. Formally, to generate a new key \( k^{\prime } \) we define \( f : K^{\prime } \rightarrow \mathbb {R} \) st: \( K^{\prime } \subset K \). Pre-processing layer and ingestion engine exchange and update the information so that \( \color{#005596}{\mathcal {R}} \) contains newly generated features.

5.2.1 Fee-Functions: fϕ and fρ.

The fee-functions include revenue-based techniques which calculate transaction fee and feerate. Transaction fee is a relevant information for our model, and it is calculated using the function \( f_{\phi } \), which resembles Algorithm 1, and it is based on transactions’ inputs and outputs. If, a transaction t has n inputs and m outputs, we formalize Equation (14) for calculating transaction fee. (14) \( \begin{equation} \color{#005596}{\phi} = \sum _{i = 1}^{n}\color{#005596}{{in}}_i - \sum _{j = 1}^{m} \color{#005596}{{ou}}_j. \end{equation} \) We identify the fee-function \( f_{\phi } \) as: \( (\color{#005596}{{in}}, \color{#005596}{{ou}}) \mapsto \color{#005596}{\phi} = f_{\phi }(\color{#005596}{{in}}, \color{#005596}{{ou}}). \) Always based on the revenue principle, the feerate-function \( f_{\rho } \) wants to get information on transaction feerate. As outlined in Equation (6) represents the way feerate is calculated, formally, we define \( f_{\rho } \) as: \( (\\color{#005596}{phi} , \color{#005596}{q}) \mapsto \color{#005596}{\rho} = f_{\rho }(\color{#005596}{\phi} , \color{#005596}{q}). \)

5.2.2 Pending-txs-Function: fP.

This fairness-based function aims at quantifying the belonging of a transaction t to the set \( \color{#005596}{\mathcal {P}} \), to see whether such a transaction has chance of getting into \( {\cal \color{#005596}{A}} \) anytime soon. The function \( f_{\mathcal {P}} \) generates feature \( \color{#005596}{\Delta \mathcal {P}} \), described in Equation (15), and graphically explained in Figure 4. Specifically, \( \color{#005596}{\Delta \mathcal {P}}^{(x)} \) represents how much a transaction \( t^{(x)} \) is waiting, from its inception, until the nearer block epoch \( \color{#005596}{be_x} \). We note that if \( t^{(x)}\notin \color{#005596}{\mathcal {P}}^{(x)} \) then \( \color{#005596}{\Delta \mathcal {P}}^{(x)} \) has a negative value, which is the case of \( \color{#005596}{\Delta \mathcal {P}} \)\( ^{(x-1)} \) in Figure 4. (15) \( \begin{equation} \begin{split} \color{#005596}{\Delta \mathcal {P}}_t^{(x)} = \color{#005596}{\beta _t}^{(x)} -\color{#005596}{ep_t}, \\ (\beta , ep) \mapsto \color{#005596}{\Delta \mathcal {P}} = f_{\mathcal {P}}(\beta , ep). \end{split} \end{equation} \) In the case a transaction is not included yet, we calculate \( \color{#005596}{\beta _t} = \color{#005596}{be_\xi} \). With the feature \( \color{#005596}{\Delta \mathcal {P}} \), we assume that a transaction can not wait forever for approval if it has paid a fair amount of fee. Furthermore, since we know \( \gamma \) to be the number of \( {\bf{\texttt{t}}} \) instances in T, we can also quantify time, in relation to the number of blocks that T has seen before being approved, so to consider both, an absolute view of time in seconds, and a relative view in \( \gamma \)-occurrences. Consequently, a block-epoch-based transaction has \( \gamma \)-different instances of \( \color{#005596}{\Delta \mathcal {P}} \).

Fig. 4.

Fig. 4. A transaction \( t_1 \) submitted at time \( ep_{t_1} \) and yet-to-be included, such that \( \mathcal {L}(t_1) = \mathcal {L}_{t_1}^{\xi } \) , takes different \( \color{#005596}{{\Delta \mathcal {P}}} \) values over time. For instance, at height \( x+1 \) , \( \color{#005596}{\Delta \mathcal {P}} \) \( ^{(x+1)}=be_{x+1} - ep_{t_1} \) . Blue \( \color{#005596}{\Delta \mathcal {P}} \) represents a positive number, while the red \( \color{#005596}{\Delta \mathcal {P}} \) \( ^{(x-1)} \) indicates a negative value.

5.2.3 Offset-Function: fδ.

The offset-function \( f_{\delta } \) is a revenue-based solution. It orders pending transactions according to their feerate, taking into account block space limitations. This function generates a new feature, the offset, represented with \( \delta \). For each block-epoch-based transaction \( {\bf{\texttt{t}}} \), its offset value at height x, indicates the amount of bytes already occupied in the block space, from unapproved transactions with a higher feerate, and it is represented as \( \delta _t^{(x)} \). The offset then is relevant to give each transaction a place in the future block, greater is the offset and fewer are the chances that \( t \in {\cal \color{#005596}{A}}^{(x)} \). If we now consider the set S at height x, containing n transactions ordered by feerate, the offset value at any index i is given by (16) \( \begin{equation} \begin{split} &\delta _i^{(x)} = \sum _{i}^{n} q_i, \\ &\left(\color{#005596}{S}^{(x)}, \color{#005596}{q}\right) \mapsto \delta = f_{\delta }\left(\color{#005596}{S}^{(x)}, \color{#005596}{q}\right). \end{split} \end{equation} \) As with \( \color{#005596}{\Delta \mathcal {P}} \), for each block-epoch-based transaction, there are \( \gamma \) different occurrences of offset values. Algorithm 2 lists how to calculate the offset for transactions in \( \color{#005596}{S}^{(x)} \). If compared to other features, this one requires more computational overhead, and the procedure defineS in Algorithm 2 counts a time complexity of \( \mathcal {O}(n^2) \), where n is the number of transactions in \( S^{(x)} \). The offset execution time (Algorithm 2) is upper bounded to \( \mathcal {O}(n) \), the latter procedure gets executed n times, and consequently, the total number of operations is derived from \( \sum _{i=0, j=0}^{n}ij \sim \mathcal {O}(n^2) \). Figure 5 shows the offset trend over time, for five consecutive blocks. In each block-epoch time frame, from \( be_1 \) to \( be_5 \), transactions waiting to be approved are ordered in the mempool by feerate, and then their relative offset value is calculated. For instance, transaction \( t^{(x)} \) appears in the pool at height \( x=1 \) and \( x=2 \), with different offset values. Same transactions can then carry different information based on their block-epoch snapshot, thus, adding valuable knowledge about network status, at every block-epoch time slot.

Fig. 5.

Fig. 5. Data sampled for five consecutive blocks. In each block-epoch slot, transactions are ordered by feerate, then the offset is calculated. We see in this example that the offset value for transaction \( t^{(x)} \) changes according to the block-epoch. Offset value for \( t^{(1)} \) for instance, is higher than its offset at epoch \( x=2 \) , of \( t^{(2)} \) . Thus, \( \delta ^{(1)}_t \gg \delta ^{(2)}_t \) .

5.3 Prediction Model

The main purpose of the prediction model is to define whether or not a transaction t at height x is likely to be included in \( \color{#005596}{{\cal A}} ^{(x)} \). As explained in Section 5.2, the ML model gets as input a training/test set \( \mathcal {X} \), which is the set identifying both the training and the test datasets, respectively \( \color{#005596}{{\mathbf {X}}} \) and \( \color{#005596}{{\mathbf {X}te}} \). Following definitions of \( {\bf{\texttt{t}}} \) and T (5.15.2), we represent the training/test dataset \( \mathcal {X} \) as an M-dimensional MTS collection of pairs \( (\color{#005596}{T} {_i}, Y {_i}) \), represented as \( \mathcal {X} = \lbrace (\color{#005596}{T} {_1}, Y {_1}), (\color{#005596}{T} {_2}, Y {_2}),\dots , (\color{#005596}{T} {_M}, Y {_M})\rbrace \), where Y \( _i \) is the corresponding one-hot label vector to a certain transaction T \( _i \). For a value \( \gamma _i = |T {_i}| \), the one hot label vector Y \( _i \) is a vector of length \( \gamma _i \) where each element \( j \in [1, \gamma _i] \) is equal to 1 if \( {\bf{\texttt{t}}} _j \) represents the time slot of T ’s inclusion, and 0 otherwise.

The ML framework outputs a model for transaction inclusion. The latter will be used later on to predict whether or not a certain transaction will be included in the next mined block. Models need to be updated and trained/tested at least every week, in order for them to be accurate, and to have enough knowledge of the current network status. When the trained model gets a transaction t as input, it outputs a vector \( \color{#005596}{{\mathbf {\theta }}_t} \), which represents the confidence for each transaction to be included or not, in the next mined block. Since this is a binary classification, we represent \( \color{#005596}{{\mathbf {\theta }}_t} = [P_t(\color{#005596}{v_0}),\,P_t(\color{#005596}{v_1})] \), where \( \color{#005596}{v_0} \) is the class representing a non-inclusion in the next block, while \( \color{#005596}{v_1} \) represents an inclusion. In other words, \( {\mathbf \color{#005596}{{\theta }}_t} \) represents the probability, \( P(\upsilon _i) \), of t to fall in the class \( \upsilon _i \), with \( i \in \lbrace 0,1\rbrace \).

We perform a supervised classification, which means that we know a-priori the outcome of transactions in \( \color{#005596}{{\mathbf {X}}} \), and use this information to test the model accuracy during the training phase, which is the purpose of labels Y. Part of \( \mathcal {X} \) is then used for testing, and \( \color{#005596}{{\mathbf {X}te}} \) represents the respective testing set of \( \mathcal {X} \). In our model implementations, we dynamically change the number of hidden layers during the validation phase. We use a Rectified Linear Unit (ReLU) function for each node in the NN, except for the output layer where we use a Normalized Exponential Function (or softmax). The weights are initialized with He normalization, which takes into account Rectified Linear Unit (ReLU) and makes it easier for deep models to converge [25]. Parameters for data normalization are set before the training phase, the set \( \color{#005596}{{\mathbf {X}}} \) is normalized using its expected value and standard deviation, as showed in Algorithm 3. If we are in the testing phase, then the algorithm normalizes the testing set \( \color{#005596}{{\mathbf {X}te}} \), according to the mean and standard deviation of \( \color{#005596}{{\mathbf {X}}} \). In order to balance the set and be unbiased in the training phases, data normalization is a necessary measure to be adopted since features have different orders of magnitude.

Parameters of the DNN classifier which cannot be estimated from data, known as hyperparameters, are set manually by trial and error, including the number of hidden layers, the number of skip connections, the batch size, and the number of epochs for each model. The batch size controls the granularity or precision of gradient descent, so the model internal parameters are optimized for every batch size of tuples. The number of epochs instead represents the number of times that the learning algorithm will work through the entire training dataset, ideally getting closer to the optimal solution at every iteration. The model’s hyperparameters are configured in order to optimize the model performance and accuracy. In the next section we present experiments and evaluations of the ML model described so far.

Skip 6EVALUATION Section

6 EVALUATION

In this section we present the evaluation of our ML model. In Section 6.1, we describe the datasets used for both training and testing, and the selection of features. In Section 6.2, we list our evaluation metrics and what we define as model accuracy. Finally, in Section 6.3, we show the results of our analyses in terms of overall accuracy, the importance of the selected features, and model cyclicity, that is, how much information of the current network status can influence model prediction if the model is updated cyclically.

6.1 Experimental Setup

We conducted experiments on a large scale with data from the Bitcoin blockchain. We analyzed more than 30 million transactions across 15 thousand blocks between January 2021 and May 2021. In Sections 5.15.2, we introduced datasets \( \color{#005596}{\mathcal {R}} \), \( \mathcal {C} \), and \( \mathcal {X} \). Table 1 shows the required space on the disk of those three datasets, when they store information about 100 thousand to 5 million transactions. The raw dataset \( \color{#005596}{\mathcal {R}} \) contains information about blocks and transactions as it was collected from the blockchain. Nothing is added, and redundant or irrelevant information is discarded in order to save disk space. The dataset \( \mathcal {C} \) is used to generate the block-epoch-based training/test dataset \( \mathcal {X} \), and considering \( \mathcal {C} \)’s demanding storage requirements at scale, only a copy of the lighter dataset \( \mathcal {X} \) is stored locally. The dataset \( \mathcal {C} \) as can be observed, has a superlinear growth. This is as expected if we consider that \( \mathcal {C} \) stores all transactions in \( \color{#005596}{\mathcal {R}} \), plus it keeps track of block-epoch dependent features described in Section 5.2, and finally it has knowledge about \( \color{#005596}{\mathcal {P}} \) and S sets.

Table 1.
Disk space of different datasets
Dataset100k txs500k1M5M
\( \mathcal {R} \)\( \sim \)29 MB\( \sim \)145 MB\( \sim \)290 MB\( \sim \)1.2 GB
\( \mathcal {C} \)\( \sim \)40 MB\( \sim \)730 MB\( \sim \)1.6 GB\( \sim \)13.7 GB
\( \mathcal {X} \)\( \sim \)7 MB\( \sim \)130 MB\( \sim \)288 MB\( \sim \)2.4 GB
B\( \sim \)60 MB\( \sim \)300 MB\( \sim \)600 MB\( \sim \)3 GB
  • The last row shows the corresponding space taken by the same amount of transaction in the actual Bitcoin blockchain. The sizes reported in this table consider a worst-case scenario for our datasets and an optimal one for the Bitcoin blockchain.

Table 1. Disk Space Occupied by Instances of Different Sets if they Contain Information About 100k, 500k, 1M, and 5M Transactions

  • The last row shows the corresponding space taken by the same amount of transaction in the actual Bitcoin blockchain. The sizes reported in this table consider a worst-case scenario for our datasets and an optimal one for the Bitcoin blockchain.

We fetch data and store locally different \( \color{#005596}{\mathcal {R}} \) instances, one per each month of evaluation, and list them in Table 2. For each period we fetch the same number of blocks (3,010 in our analysis), and for every dataset \( \mathcal {R}^{i} \) we create a prediction model based on the inclusion pattern defined in Section 4. A \( \mathcal {C}^i \) dataset is generated at run-time, and from it, new information and features are extracted. Finally, data from \( \mathcal {C}^i \) are selected to form the training/test dataset of features \( \mathcal {X}^i \). For every period i, we train one model with the first \( 50\% \)-occurred transactions in \( \mathcal {R}^i \). Each tested set is labeled with hyperparameters defining how complete and new the considered set is. We define these hyperparameters as \( \alpha \) and \( \psi \). We identify \( \alpha = {|{\color{#005596}{\mathbf {X}te}}|}/{|{\color{#005596}{\mathbf {X}}}|} \), as the fraction of transactions used for testing over the total number of points used for training e.g., if \( \alpha = 0.5 \) the amount of transactions used for testing is half of the one used for training. This value is important to have an accurate prediction when live information is not available. In our case, we preferred to conduct experiments using millions of older transactions fetched and stored locally. In this way, we know a-priori their inclusion, and consequently, it is easier to evaluate large datasets quicker. As \( \alpha \rightarrow 1 \) the set becomes complete, and the offset value constructed for testing is close-enough to the one used for training, therefore we reduce false-positives points if \( \alpha \ll 1 \) or false negatives if \( \alpha \gg 1 \). We say that a complete set has an accurate view of the mempool size over time. The other hyperparameter, \( \psi \), represents the distance (time-wise) of test set from training. Let mo be the difference between the test month and the training month, the value \( \psi \) is normalized through a \( \operatorname{sigmoid} \) function so to have a bound of \( [0,1] \), such that: \( \psi = \operatorname{sigmoid}(\texttt {mo}) \). If we use training and test data from the same month, we have \( \psi = \operatorname{sigmoid}(0) = 0.5 \), and we consider the model new. If the test is done with an older model, we have \( \texttt {mo} \gt 0 \), and consequently \( \psi \rightarrow 1 \). On the other hand, if we train the model a-posteriori and want to test older data, \( \texttt {mo} \lt 0 \) and \( \psi \rightarrow 0 \). This parameter indicates how new the transactions tested are compared to the ones trained. Therefore \( \psi \) measures how updated the model is in relation to the current network status. Furthermore, information on \( \psi \) is useful later on, when model cyclicity is analyzed.

Table 2.
Raw dataset for each period
iDate\( |\mathcal {R}^{i}| \)\( \mathcal {R}^{i} \) sizeB price
1January6.5M1.09 GB$29 k–$35 k
2February6.7M1.12 GB$33 k–$56 k
3March6.2M1.05 GB$49 k–$58 k
4April6.2M1.04 GB$58 k–$56 k
5May5.2M877 MB$58 k–$36 k
  • 3,010 blocks are analyzed every month. \( |\mathcal {R}^i| \) is the number of transactions analyzed in each set, while \( \mathcal {R}^i \) size identifies the set’s space on disk. We also include the Bitcoin price at time of evaluation to discuss any correlation between model prediction and coin price at that time.

Table 2. Tests and Evaluations are Performed on these Raw Time-Series Datasets

  • 3,010 blocks are analyzed every month. \( |\mathcal {R}^i| \) is the number of transactions analyzed in each set, while \( \mathcal {R}^i \) size identifies the set’s space on disk. We also include the Bitcoin price at time of evaluation to discuss any correlation between model prediction and coin price at that time.

The features we select to be trained (from \( \mathcal {C} \) to \( \mathcal {X} \)), are partially fetched from the blockchain and some others are engineered as seen in Section 5.2. Following our assumptions, \( \mathcal {X} \) should contain information about fairness and revenue (Sections 4.24.3). We train our models with the following features: \( K_{\mathcal {X}} = [\color{#005596}{\phi}, \color{#005596}{q}, \color{#005596}{\rho}, \color{#005596}{\Delta \mathcal {P}}, \delta , \Delta \mathcal {P}_N, \delta _N] \), where \( \Delta \mathcal {P}_N \) and \( \delta _N \) are normalized values for respectively, \( \color{#005596}{\Delta \mathcal {P}} \) and \( \delta \). The first one represents the waiting time \( \color{#005596}{\Delta \mathcal {P}} \), as the number of created blocks a certain transaction \( {\bf{\texttt{t}}} _{\gamma } \) has seen from its inception (Equation (17)).} (17) \( \begin{equation} \begin{split} \Delta \mathcal {P}_N^{(\gamma)}=&\sum _{i=0}^{\gamma }\omega ^{(i)}\text{ with,} \\ \omega ^{(i)} = & {\left\lbrace \begin{array}{ll} 0, \text{ if } {{\bf{\texttt{t}}}}_i \notin \mathcal {P}^{(i)}, \\ 1, \text{ if } {{\bf{\texttt{t}}}}_i \in \mathcal {P}^{(i)}. \end{array}\right.} \end{split} \end{equation} \) The second one, \( \delta _N \), is the offset normalized with the maximum block space (\( \sim \)1.1 MB), so that \( \delta _N \) is a percentage which tells how much the mempool is already occupied by richer transactions (Equation (18)). (18) \( \begin{equation} \delta _N^{(x)} =\frac{\delta ^{(x)} \times 100}{\color{#005596}{{Q}}}. \end{equation} \)

6.2 Evaluation Metrics

Evaluating our ML model is an essential part of this study. While classification accuracy is still our main evaluation metric, sometimes it is not enough to truly judge our model. For this, we also consider a confusion matrix and area under curve (AUC) evaluation. We briefly describe them and then present our results in Section 6.3.

6.2.1 Classification Accuracy.

When we evaluate our model, we initially refer to its broad-accuracy-value as the so-called classification accuracy, which is the ratio of number of correct predictions to the total number of input samples: \( \begin{equation*} \text{Accuracy} =\frac{\text{Number of correct predictions}}{\text{Total number of predictions}}. \end{equation*} \) This metric is immediate and easy to calculate, and we use it as a general measure for comparing accuracy between different models. However, classification accuracy does not always represent an accurate model evaluation since it works well only when a homogeneous class distribution is studied. Our classes proved themselves to be quite unbalanced, and since we did not want to reduce the number of sampled data, we opted to include other metrics for evaluating the model.

6.2.2 Confusion Matrix.

Confusion matrix allows to visualize how accurate our model is to make predictions over the binary classification problem (\( \color{#005596}{v_0},\,\color{#005596}{v_1} \)). We refer to the following definition of confusion matrix \( {\bf CM} \), also formalized in Table 3: (19) \( \begin{equation} \begin{split} &{\bf CM} = {\bf Fr} ^{-1}\cdot \begin{bmatrix} a_{00} & a_{01}\\ a_{10} & a_{11} \end{bmatrix}, \\ \text{where} \quad &{\bf Fr} _{2,2}= [b_{ii}], \quad b_{ii} = \sum _j a_{ij}. \end{split} \end{equation} \) \( a_{ij} \) is the number of elements that truly belongs to i but were classified in j. The metrics we use, obtained from \( {\bf CM} \), are the recall and the precision. The recall \( R_i \) of a specific class \( \upsilon _i \), represents the number of \( t \in \upsilon _i \) which were correctly classified in class \( \upsilon _i \), while the precision \( P_i \) for class \( \upsilon _i \) represents the number of data points classified in \( \upsilon _i \) which actually belongs to \( \upsilon _i \). (20) \( \begin{align} \begin{split} R_i = \frac{a_{ii}}{\sum _{j=0}^{1}a_{ji}},\quad P_i = \frac{a_{ii}}{\sum _{j=0}^{1}a_{ij}}. \end{split} \end{align} \)

Table 3.

Table 3. Confusion Matrix Model

6.2.3 Area Under Curve.

AUC is a widely used metric for binary classification problems. Area Under Curve (AUC) represents the probability that our model will rank a randomly chosen \( t \in \upsilon _1 \) higher than a randomly chosen \( t \in \upsilon _0 \). AUC has a range value of \( [0, 1] \), and the greater the value, the better is the classifier performance. If AUC \( =1 \) then the classifier is able to perfectly distinguish between the two classes, if AUC \( =0.5 \) the model is not able to distinguish between \( \color{#005596}{v_0} \) and \( \color{#005596}{v_1} \) class points, while if AUC \( =0 \), the classifier would be predicting all \( \color{#005596}{v_0} \) as \( \color{#005596}{v_1} \) and vice-versa. Area Under Curve of Receiver Operator Characteristic (AUC-ROC) is a very important metric for our evaluations, and specifically, we calculate Area Under Curve of Receiver Operator Characteristic (AUC-ROC) following the scheme in Table 3, and according to (21) \( \begin{align} \begin{split} {\it TPR}= \frac{{\it TP}}{{\it TP}+ {\it FN}}, \quad {\it FNR}= \frac{{\it FN}}{{\it TP}+ {\it FN}}, \\ {\it TNR}= \frac{{\it TN}}{{\it TN}+ {\it FP}}, \quad {\it FPR}= \frac{{\it FP}}{{\it TN}+{\it FP}}. \end{split} \end{align} \) True Positive Rate (\( {\it TPR} \)) identifies \( R_1 \), or Sensitivity, True Negative Rate (\( {\it TNR} \)) represents the Specificity, so what proportion of the negative class \( \color{#005596}{v_0} \) was correctly classified. False Positive Rate (\( {\it FPR} \)) is equal to \( 1 - \text{Specificity} \), and it represents the proportion of \( \color{#005596}{v_0} \) that was incorrectly classified. Finally, False Negative Rate (\( {\it FNR} \)) indicates what proportion of the positive class was incorrectly classified. The representation of the Receiver Operator Characteristic (ROC) curve and its consequent AUC, has \( {\it FPR} \) on x-axis and \( {\it TPR} \) on y-axis.

6.3 Analyses

In Section 6.3.1, we present the overall classification accuracy of our classifier, following the evaluation metrics defined in Section 6.2. We list classification accuracy for each month of the evaluation, from January 2021 until May 2021, with an optimal scenario of \( \alpha =1 \) and \( \psi =0.5 \). A confusion matrix representing the whole period is also presented. In Section 6.3.2, we discuss the importance of selecting the right features, how accuracy changes with or without certain information, and how the results might diverge if the wrong assumptions are made. Also in these experiments, hyperparameters are set as an optimal case scenario. Finally, Section 6.3.3 outlines the importance of keeping the model updated. Different hyperparameters are evaluated and an AUC-ROC score for each of them is presented and compared.

6.3.1 Overall Accuracy.

We present here the overall classification accuracy for each month of training, by setting hyperparameters with their optimal values of \( \alpha =1 \), \( \psi =0.5 \). We show the overall classification accuracy for each month in Table 4, while the \( {\bf CM} \) for all the points analyzed from January until May, of over 30 million transactions, is represented in Table 5. We observe that during the whole training/test period, the overall accuracy of the model is above \( 90\% \) for three out of five months, while the model struggles between April and May, during the coin price plunge (discussed in Section 7). Despite that, the model appears to be solid even in our worst-case scenarios, and the confusion matrix in Table 5 shows that the model correctly classifies \( 91\% \) of transactions in \( \color{#005596}{v_0} \), and \( 88\% \) in \( \color{#005596}{v_1} \).

Table 4.
Classification accuracy
\( \alpha \)\( \psi \)JanuaryFebruaryMarchAprilMayOverall
10.590.07%90.9%91.08%85.52%88.29%89.17%
  • The overall accuracy represents the average classification accuracy for the whole period of analysis. The optimal case scenario for hyperparameters \( \alpha \) and \( \psi \) is presented, in this way the model is complete and updated in relation to the data tested.

Table 4. Classification Accuracy for each Month, from January Until May

  • The overall accuracy represents the average classification accuracy for the whole period of analysis. The optimal case scenario for hyperparameters \( \alpha \) and \( \psi \) is presented, in this way the model is complete and updated in relation to the data tested.

Table 5.
Overall \( {\bf CM} \) score
\( v_0 \)\( v_1 \)
\( v_0 \)0.910.09
\( v_1 \)0.120.88
  • This matrix shows how the 30+ million transactions were classified using five different models, one for each month, with a complete and updated view. False negative transactions represents \( 9\% \) of the negative ones, while false positive \( 12\% \) of the positive ones.

Table 5. Overall \( {\bf CM} \) Score for Test Ran between January 2021 and May 2021, with Parameters \( \alpha = 1 \) and \( \psi = 0.5 \)

  • This matrix shows how the 30+ million transactions were classified using five different models, one for each month, with a complete and updated view. False negative transactions represents \( 9\% \) of the negative ones, while false positive \( 12\% \) of the positive ones.

6.3.2 Selected Features.

In order to validate our assumptions, we verify and test how important some features are in predicting transaction inclusion. In the following results we show the classification accuracy and confusion matrix for trained models with only a specific subset of features \( K_{\mathcal {X}}^n\subset K_{\mathcal {X}} \). We evaluate four different sets of features where \( n=[1,2,3,4] \), and each number identifies a different type of evaluation: (1) Primitive information, the set \( K_{\mathcal {X}}^1 \) identifies only fetched features such as transaction size and fee. This information is used by many fee predictors, with poor results about fee overpaying, \( K_{\mathcal {X}}^1 = [\\color{#005596}{phi} , \color{#005596}{q}] \); (2) Fairness assumptions, the set \( K_{\mathcal {X}}^2 \) excludes features based on the revenue principle, so a miner needs to only be fair in order to include transactions in the next block, \( K_{\mathcal {X}}^2 = [\\color{#005596}{phi}, \color{#005596}{q}, \color{#005596}{\Delta \mathcal {P}}, \Delta \mathcal {P}_{N}] \); (3) Revenue assumptions, the set \( K_{\mathcal {X}}^3 \) excludes features based on the fairness principle, to monitor how much revenue impacts the transaction inclusion pattern, \( K_{\mathcal {X}}^3= [\\color{#005596}{phi}, \color{#005596}{q}, \color{#005596}{\rho}, \delta , \delta _N] \); (4) Assumptions-based, the set \( K_{\mathcal {X}}^4 \) includes only extracted features, this evaluation aims at verifying the reliability of our initial assumptions, including both, fairness and revenue concepts, \( K_{\mathcal {X}}^4= [\\color{#005596}{rho} , \color{#005596}{\Delta \mathcal {P}}, \Delta \mathcal {P}_{N}, \delta , \delta _N] \).

The experiments performed for this purpose have a set up of \( \alpha = 1 \) and \( \psi =0.5 \), classification accuracy results are shown in Table 6, and the related plot is presented in Figure 6. The DNN classifier struggles when the Bitcoin price drops drastically over the month, e.g., in April. In fact, we observe that when only primitive information is used, the accuracy drops \( 15\% \) from the previous month, while with complete information the accuracy drop is \( 5\% \) only. The impact of our assumptions on predicting transaction inclusion is relevant. The model can perform from \( 12\% \) to \( 14\% \) better on average, if fairness and revenue principles are applied separately, to data that most fee predictors use, and up to \( 23\% \) if they are combined. To be noted is the variance of \( K_{\mathcal {X}}^2 \) classification accuracy since it appears to be smaller than the one of \( K_{\mathcal {X}}^3 \). This highlights the importance of the fairness concept in order to delineate transaction inclusion. In the month of April, we observe an inversion of the Bitcoin price uptrend, and miner revenue was at its all-time-high. This outlines how miners are deviating from the revenue principle more than the fairness one.

Fig. 6.

Fig. 6. Classification accuracy results for each one of our assumption sets, from primitive to complete, for each month of analysis from January 2021 until May 2021. The model accuracy increases considerably if a complete feature set is used, compared to the basic idea of using only transaction size and transaction fee as features.

Table 6.
Classification accuracy for \( K_{\mathcal {X}}^n \)
n : typeJanuaryFebruaryMarchAprilMayOverall
1 : Primitive75.13%78.54%77.77%62.52%69.97%72.78%
2 : Fairness84.57%86.24%84.63%83.64%82.11%84.23%
3 : Revenue88.24%87.73%89.4%80%86.21%86.31%
4 : Complete89.51%90.36%90.04%85.35%88.23%88.69%
  • Each set of selected features represents a different assumption we made in the analysis phase. From the concept of inclusion as merely transaction fee and transaction size, to the concepts of fairness and revenue we explained.

Table 6. Classification Accuracy for Different \( K_{\mathcal {X}} \) Sets

  • Each set of selected features represents a different assumption we made in the analysis phase. From the concept of inclusion as merely transaction fee and transaction size, to the concepts of fairness and revenue we explained.

6.3.3 Model Cyclicity.

In this paragraph, we deviate from the optimal hyperparameter settings used so far, in order to highlight how much model classification accuracy could benefit if well-formed data are used for training. Well-formed data creates what we call an updated model, or a model trained cyclically over time, and this information should be complete (\( \alpha =1 \), for a correct offset value) and new (\( \psi =0.5 \), transactions should be tested with a relatively recent model). We note that, if we deviate from the mean value of \( \psi =0.5 \) towards 1, the test sets occur after the training, while if the value \( \psi \) tends to 0, the model used is newer than the transactions tested. Despite this being an unrealistic scenario, we want to monitor the model’s behavior with both, older and newer transactions. We test for each month, all the possible combinations between the values \( \alpha = [0.05, 0.1, 0.5, 1] \), and \( \psi = [0.01, 0.05, 0.12, 0.26, 0.5, 0.73, 0.88, 0.95, 0.98] \). Results are showen in Figure 7, where each point represents the average classification accuracy over five months if hyperparameters are changed according to \( \alpha \) (x-axis) and \( \psi \) values (y-axis). The plot shows that the accuracy is higher (yellow) when \( \psi \rightarrow 0.5 \) and \( \alpha \rightarrow 1 \), but as the offset precision diminishes (lower \( \alpha \)), then model cyclicity (\( \psi \)) becomes less important. Here is outlined how much the combination of both hyperparameters is significant, \( \psi \) becomes relevant when it has the right information about the mempool size, provided by the right choice of \( \alpha \). In this way, the offset contextualizes the model over time, and without an accurate calculation of it, the model would just predict according to the fairness concept, which seems to be less time-dependent than offset (Figure 6, Fairness bar).

Fig. 7.

Fig. 7. Classification accuracy value (z-axis) for various models, tested with different hyperparameters setup. The y-axis, with the \( \psi \) parameter, represents how much a certain model is updated, while the x-axis indicates the model’s completeness ( \( \alpha \) parameter). The importance of model cyclicity is highlighted in order to improve classification accuracy.

Figure 8 shows the AUC-ROC curves for five tests performed with different hyperparameter values, chosen to be representative for optimal-, average-, and worst-case scenarios. The parameters chosen are represented in Table 7. We identify two average cases, and two worst cases, describing if the testing occurred before (–) or after (+) the training. In the optimal case, the model can distinguish between classes with an area under the curve of 0.97, which is a solid classification result. Even if we accept an \( {\it FPR} \) of \( 10\% \), the \( {\it FNR} \) does not go higher than \( 10\% \), and if we accept an \( {\it FPR} \) of \( 20\% \), the \( {\it FNR} \) is kept below \( 5\% \).

Fig. 8.

Fig. 8. Five tests to measure AUC-ROC in an optimal, average, and worst-case. The optimal test is run with \( \alpha =1 \) and \( \psi =0.5 \) , identified with a green continuous line. The two average tests are run with \( \alpha =0.2 \) and \( \psi = [0.12, 0.88] \) , represented with a dot-dashed light blue lines. The two worst-case tests are run with \( \alpha = 0.04 \) , \( \psi =[0.02, 0.98] \) , and they are represented with dotted yellow and red lines. When AUC \( =0.5, \) the classifier is not able to distinguish anymore between positive and negative class points.

Table 7.
Evaluations on model cyclicity
type\( \alpha \)\( \psi \)AccuracyAUC-ROC
Worst-0.040.0278.63%0.82
Average-0.20.1284.71%0.92
Optimal10.591.08%0.97
Average+0.20.8881.250.89
Worst+0.040.9870.250.8
  • The optimal evaluation is the one having a \( 100\% \) complete model, and the test is performed within the same month of training. An average evaluation model is \( 20\% \) complete and there is a two months deviation from training and testing. The worst evaluation case is when the model is only \( 4\% \) complete and there is four months deviation between training and testing.

Table 7. AUC-ROC Results for Different Hyperparameters

  • The optimal evaluation is the one having a \( 100\% \) complete model, and the test is performed within the same month of training. An average evaluation model is \( 20\% \) complete and there is a two months deviation from training and testing. The worst evaluation case is when the model is only \( 4\% \) complete and there is four months deviation between training and testing.

Skip 7DISCUSSION Section

7 DISCUSSION

The extensive analysis we performed on Bitcoin, outlined difficulties in ensuring a low-payment scheme for users. We explained in Section 3 how the interblock interval time and the block size constraints negatively affect the system’s throughput. Fee markets emerge as a means to provide a stable income for miners. This leads fee estimators to overprice transaction fees in order to guarantee an immediate inclusion in the blockchain. However, this results in users having to pay a fee two orders of magnitude higher than the recommended one. To optimize user expenditure we define our view of a transaction inclusion model and then save data locally for the analysis. The inclusion model formalized and described in Sections 45 is fundamental to extract the right features for an accurate classification. With this, if models are cyclically trained at least once a month, it is possible to collocate new incoming transactions in classes \( \color{#005596}{v_0} \) and \( \color{#005596}{v_1} \), with an accuracy score on average of \( 89\% \).

As Table 1 shows, the dataset we generate is efficient in terms of disk space even in the worst-case scenario for our datasets (Table 2 lists the actual dataset sizes for our analysis). If the raw dataset (\( \color{#005596}{\mathcal {R}} \)) size is compared to the actual blockchain size, then \( \color{#005596}{\mathcal {R}} \) saves on average \( 54\% \) of disk space. Furthermore, we notice that the training set \( \mathcal {X} \) containing block-epoch-based information, is \( 54.4\% \) lighter on average than the blockchain original size, with \( 89\% \) of disk space saved, if smaller datasets are taken into account. For dataset evaluation, we set a 3,000 blocks threshold (\( \sim \)20 days, or \( \sim \)6 million transactions) because the DNN models we produce are for short-term prediction and, therefore, are more accurate if generated cyclically. The complete set \( \color{#005596}{\langle {C}\rangle} \) is the heavier one, although we never store it locally and it is used only to generate its lighter version \( \mathcal {X} \) for the model’s training. In Table 2, we represent time-series observational data of the raw datasets \( \color{#005596}{\mathcal {R}}^i \), and we observe that the size on disk is \( 71.5\% \) lower than the corresponding Bitcoin blockchain size.

Results of our experiments are presented in Section 6, highlighting the importance of selecting and generating the right set of features. Building a model using only data fetched from the blockchain, which is the solution adopted by many fee estimators, is trivial. We label this as the primitive solution. During the five months of analysis, we test models with the set of engineered features based on our intuition. We call it a complete solution, and then we compare it with the primitive one. On average, we obtain an improvement in the accuracy score of \( 16\% \). Most importantly, we notice the downtrend of our model accuracy score during the months of April and May. We conjecture that this is caused by a series of events that occurred during these months. Initially, there was a Bitcoin price inversion-trend and its price dropped \( 46\% \).14 Following, more transactions saturated the mempool15 and transaction fees reached a new all-time-high.16 Miners revenue reached an all-time-high between April 14th and May 10th,17 leading us to consider that revenue stopped being miners’ main means of inclusion. However, despite relevant and unpredictable exogenous events, our complete solution never fell below \( 85.35\% \) of accuracy score.

Another fundamental aspect that boosts classifier accuracy score is model cyclicity. Figure 7 shows the importance of keeping the information in the model complete and new, especially when unexpected events occur. We can evince from the plot that classification accuracy drops when older models are used to classify more recent data, \( \psi \rightarrow 1 \), or when information in the test set is not complete, \( \alpha \rightarrow 0 \). Also, the accuracy score drops considerably if models prior to the price inversion trend are used to classify more recent data. For instance, Table 8 shows confusion matrices of two different tests. Both represent data fetched in April 2021 and classified with a model from January 2021. One dataset is complete (\( \alpha =1 \)), while the other one is not (\( \alpha = 0.5 \)). Despite data completeness, the all-time-high fees in April make the model incorrectly classify \( 26\% \) of transactions in \( \color{#005596}{v_1} \) while they belonged to \( \color{#005596}{v_0} \) (false positive). That means the model classifies more transactions as included, while they are not. If we then reduce \( \alpha \) to 0.5 the false positives increase to \( 41\% \), while the false negative represents only \( 5\% \). When such events occur, the model ought to be trained more frequently than once per month. This will reduce the number of misclassified transactions due to some deviations from the previous inclusion pattern. In Figure 6 we show that our intuitions on the selected features are correct, and they are crucial for an accurate classification. Both hyperparameters resulted to be fundamental for boosting the accuracy score. A complete set is needed to have the right information on the mempool size in order to correctly calculate the offset value. An updated (or new) dataset helps to have knowledge of the current miner inclusion trend.

Table 8.
Overall \( {\bf CM} \) score, \( \psi =0.95 \)
\( \alpha \)0.51
\( v_0 \)\( v_1 \)\( v_0 \)\( v_1 \)
\( v_0 \)0.950.050.890.11
\( v_1 \)0.410.590.260.74
  • Information of two \( {\bf CM} \) tables is represented, the \( \psi \) is kept at 0.95 while two different values of \( \alpha \) are evaluated, 0.5 and 1. This table shows the importance of having a complete dataset during training, and how classification accuracy can benefit from it.

Table 8. Overall \( {\bf CM} \) Score for April 2021 Data, using the January 2021 Model

  • Information of two \( {\bf CM} \) tables is represented, the \( \psi \) is kept at 0.95 while two different values of \( \alpha \) are evaluated, 0.5 and 1. This table shows the importance of having a complete dataset during training, and how classification accuracy can benefit from it.

Despite the fact that we obtain a good classification accuracy score, we note that the model could be biased towards a specific range of transaction fees. In fact, bias gets into the model through the data that is used for building the ML model [23]. We carry out a supervised approach, thus our model only knows the outcome for transactions that occurred in the blockchain. If most users pay a fee greater than the optimal value, the model lacks samples for small transaction fee values. Figures 9 and 10 show the fee and feerate Cumulative Distribution Function (CDF) during the period of analysis. We observe that after the price drop occurred in late April 2021, fees were considerably lower (May 2021), and that transaction fees between \( 10^4 \) and \( 10^5 \) sat18 represent nearly the \( 75\% \) of the total. The recommended feerate should be 1 sat/byte, however, we notice that nearly \( 0\% \) of transactions have a feerate that low. Consequently, an educated guess is that our model is biased and it is not accurate when predicting transactions with 1 sat/byte of feerate. However, the overall fee trend of approved transactions delineates a pattern itself, meaning that a too low fee will rarely end up in an inclusion, which is in line with our model’s outcome. In fact, lower fee transactions are evicted from the network and never included. Our model optimizes expenditure within the range of the already approved transactions and its scope is not to detect possible evicted transactions but to determine an inclusion in the next block. Information about eviction is not of particular relevance. Finally, any transaction issuer could consult the model’s output in order to tradeoff its probability of inclusion with more, or less fee to pay.

Fig. 9.

Fig. 9. CDF of transaction fees in our dataset.

Fig. 10.

Fig. 10. CDF of transaction feerate in our dataset.

7.1 Future Work

We are currently working on expanding this work with some experiments related to user’s expenditure. The goal is to measure how much an issuer can lower its given fee, by keeping the output confidence of the inclusion model high. By doing so, we can quantify the actual overspending of the Bitcoin network, and we can contribute to improving the overall user experience.

The inclusion model we refer to might change during time. It is useful then to keep on observing blockchain data in order to make new conjectures on inclusion pattern, if we want to use PoW-based systems without overpaying for transaction space in the blocks. We are currently working on a modified version of the aforementioned inclusion model which aims at boosting accuracy score. This approach includes a holistic view of new block alternatives, and considers transaction offset level being penalized if they fall in the > 1 MB space of the mempool. In this way the model has a stronger second-price auction orientation. Furthermore, we aim to organize transactions at every block epoch into ranks, and include transaction rank as a feature for the prediction model. Finally, to reduce training data bias from high-fee transactions, a big enough number of low-fee transactions can be added to the actual blockchain and their latency registered by the model.

Skip 8CONCLUSION Section

8 CONCLUSION

The unpredictable fee market in PoW-based blockchains, like Bitcoin and Ethereum, leads to unexpected transaction delays and evictions unless a substantial fee is offered. This has serious economic implications for the end users, as overpaying transaction fees and unstable prices become the norm.

In this article, we present a systematic study of the transaction fee mechanism in Bitcoin and show that the generic information available is not sufficient to delineate a pattern for transaction acceptance. By analyzing the blockchain data for mechanisms and patterns governing miners’ decisions to include individual transactions, we devise a novel formal transaction inclusion model that is based on fairness and revenue principles. We show the applicability of our formal model by using it to construct a DNN prototype that predicts transaction inclusion. Despite the limitations of delineating a pattern when the block creation time is a randomized process and the miner’s policies of inclusion are unknown, we obtained promising results. When training on more than 30 million transactions over a five months period, we obtained an overall average accuracy of \( 89\% \), in spite of the price inversion trend and with peaks up to \( 91\% \). The model is therefore capable of predicting transaction inclusion with a notable precision, enabling Bitcoin users to better select a suitable fee paid and probability of transaction inclusion.

Skip ACKNOWLEDGMENTS Section

ACKNOWLEDGMENTS

We thank Christian Cachin and Ignacio Amores of the Cryptology and Data Security group at the University of Bern for their helpful comments and feedback.

Footnotes

  1. 1 The average time required for the system to mine a new block.

    Footnote
  2. 2 Detached or Orphaned blocks are valid blocks that are not part of the main chain. They can occur when two miners produce blocks at similar times, and one block gets discarded because of a higher propagation delay.

    Footnote
  3. 3 Transactions committed per second (t/s).

    Footnote
  4. 4 Difficulty increases/decreases because the pool of miners solves the PoW puzzle faster/slower. So if the number of miners increases, they are consuming more while producing the same amount of blocks.

    Footnote
  5. 5 Normally distributed with a fixed known mean (600 seconds in Bitcoin).

    Footnote
  6. 6 0.31% is the probability of orphaning on data collected from blockchain.com for every block occurred from 18th March 2014 to 14th June 2016, and stored at https://cutt.ly/YvUvMz5.

    Footnote
  7. 7 E.g., bitcoin fees https://bitcoinfees.earn.com.

    Footnote
  8. 8 Recommended minimum feerate is \( 10^{-5} \) BTC/kB \( \equiv 1,000 \) sat/kB \( \equiv 1 \) sat/byte, according to Bitcoin Core.

    Footnote
  9. 9 For instance, we manage to store 1.3 GB of information from the actual Bitcoin blockchain, in only 0.4 GB. See Table 1 and 2 for more information.

    Footnote
  10. 10 https://www.blockchain.com.

    FootnoteFootnote
  11. 11 https://pypi.python.org/pypi/forex-python.

    Footnote
  12. 12 https://bitcoin.org/en/bitcoin-core/.

    Footnote
  13. 13 More than 10x faster. In 30 seconds, using APIs from blockchain.com , we fetch information on transactions included in 10 blocks.

    Footnote
  14. 14 Bitcoin price dropped from $ 63,000 to $ 34,000 starting on April 17th https://www.coindesk.com/price/bitcoin.

    Footnote
  15. 15 Mempool count https://www.blockchain.com/charts/mempool-count.

    Footnote
  16. 16 With an average of $ 60 per transaction on April 21st. https://www.blockchain.com/charts/transaction-fees-usd.

    Footnote
  17. 17 Miners revenue reached 80 million per day https://www.blockchain.com/charts/miners-revenue.

    Footnote
  18. 18 1 satoshi = 0.00000001 Bitcoin.

    Footnote

REFERENCES

  1. [1] Abadi Martín, Agarwal Ashish, Barham Paul, Brevdo Eugene, Chen Zhifeng, Citro Craig, Corrado Greg S., Davis Andy, Dean Jeffrey, Devin Matthieu, Ghemawat Sanjay, Goodfellow Ian, Harp Andrew, Irving Geoffrey, Isard Michael, Jia Yangqing, Jozefowicz Rafal, Kaiser Lukasz, Kudlur Manjunath, Levenberg Josh, Mané Dandelion, Monga Rajat, Moore Sherry, Murray Derek, Olah Chris, Schuster Mike, Shlens Jonathon, Steiner Benoit, Sutskever Ilya, Talwar Kunal, Tucker Paul, Vanhoucke Vincent, Vasudevan Vijay, Viégas Fernanda, Vinyals Oriol, PeteWarden, MartinWattenberg, Wicke Martin, Yu Yuan, and Zheng Xiaoqiang. 2015. TensorFlow: Large-Scale Machine Learning on Heterogeneous Systems. (2015). Retrieved April 2021 from https://www.tensorflow.org/. Software available from tensorflow.orgGoogle ScholarGoogle Scholar
  2. [2] Aiyer Amitanand S., Alvisi Lorenzo, Clement Allen, Dahlin Mike, Martin Jean-Philippe, and Porth Carl. 2005. BAR fault tolerance for cooperative services. In Proceedings of the 20th ACM Symposium on Operating Systems Principles. ACM, New York, NY, 4558. DOI:Google ScholarGoogle ScholarDigital LibraryDigital Library
  3. [3] Apostolaki Maria, Zohar Aviv, and Vanbever Laurent. 2017. Hijacking bitcoin: Routing attacks on cryptocurrencies. In Proceedings of the 2017 IEEE Symposium on Security and Privacy. 375392. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  4. [4] Augspurger Tom, Bartak Chris, Cloud Phillip, Hayden Andy, Hoyer Stephan, McKinney Wes, Reback Jeff, She Chang, Horikoshi Masaaki, Bossche Joris Van den, et al. 2012. Pandas: Python Data Analysis Library. software v0.21.0. Pandas community. Retrieved from http://pandas.pydata.org/.Google ScholarGoogle Scholar
  5. [5] Baker RSJD et al. 2010. Data mining for education. International Encyclopedia of Education 7, 3 (2010), 112118.Google ScholarGoogle ScholarCross RefCross Ref
  6. [6] Basu Soumya, Easley David, O’Hara Maureen, and Sirer Emin Gün. 2019. The old fee market is broken, long live the new fee market. Hacking Distributed (2019). Retrieved from https://bit.ly/3gUQaLc.Google ScholarGoogle Scholar
  7. [7] Basu Soumya, Easley David, O’Hara Maureen, and Sirer Emin. 2018. Towards a functional fee market for cryptocurrencies. CoRR abs/1901.06830. http://arxiv.org/abs/1901.06830.Google ScholarGoogle Scholar
  8. [8] Bose Indranil and Mahapatra Radha K.. 2001. Business data mining—a machine learning perspective. Information & Management 39, 3 (2001), 211225.Google ScholarGoogle ScholarCross RefCross Ref
  9. [9] Chen Min, Hao Yixue, Hwang Kai, Wang Lu, and Wang Lin. 2017. Disease prediction by machine learning over big data from healthcare communities. IEEE Access 5 (2017), 88698879. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  10. [10] Chollet François et al. 2015. Keras. Retrieved April 2021 from https://github.com/fchollet/keras.Google ScholarGoogle Scholar
  11. [11] Croman Kyle, Decker Christian, Eyal Ittay, Gencer Adem Efe, Juels Ari, Kosba Ahmed, Miller Andrew, Saxena Prateek, Shi Elaine, Sirer Emin Gün, Song Dawn, and Wattenhofer Roger. 2016. On scaling decentralized Blockchains. In Financial Cryptography and Data Security.Springer, Berlin, 106125. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  12. [12] Dean Jared. 2014. Big Data, Data Mining, and Machine Learning: Value Creation for Business Leaders and Practitioners. John Wiley & Sons.Google ScholarGoogle ScholarCross RefCross Ref
  13. [13] Decker C. and Wattenhofer R.. 2013. Information propagation in the Bitcoin network. In Proceedings of the IEEE P2P 2013. 110. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  14. [14] Diez-Sierra Javier and Jesus Manuel del. 2020. Long-term rainfall prediction using atmospheric synoptic patterns in semi-arid climates with statistical and machine learning methods. Journal of Hydrology 586 (2020), 124789. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  15. [15] Dua Sumeet, Acharya U. Rajendra, and Dua Prerna. 2014. Machine Learning in Healthcare Informatics. Springer.Google ScholarGoogle ScholarCross RefCross Ref
  16. [16] Easley David, O’Hara Maureen, and Basu Soumya. 2019. From mining to markets: The evolution of bitcoin transaction fees. Journal of Financial Economics 134, 1 (2019), 91109. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  17. [17] Erhardt Mark. 2021. 88% of all BTC transfers are overpaying transaction fees. Retrieved February 11, 2021 from https://bit.ly/32CJE73.Google ScholarGoogle Scholar
  18. [18] Eyal Ittay and Sirer Emin Gün. 2014. Majority is not enough: Bitcoin mining is vulnerable. In Proceedings of the International Conference on Financial Cryptography and Data Security. Springer, 436454.Google ScholarGoogle ScholarCross RefCross Ref
  19. [19] Fadilpašić Sead. 2019. Stop Overpaying Bitcoin Transaction Fees. (2019). Retrieved July 23, 2020 from https://bit.ly/2Cy5VtH.Google ScholarGoogle Scholar
  20. [20] Farmer J. Doyne and Sidorowich John J.. 1987. Predicting chaotic time series. Physical Review Letters 59 (1987), 845848. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  21. [21] Foster George. 1977. Quarterly accounting data: Time-series properties and predictive-ability results. The Accounting Review 52, 1 (1977), 121. Retrieved from http://www.jstor.org/stable/246028.Google ScholarGoogle Scholar
  22. [22] Fuller Wayne A.. 2009. Introduction to Statistical Time Series. John Wiley & Sons.Google ScholarGoogle Scholar
  23. [23] Gu Jindong and Oelke Daniela. 2019. Understanding bias in machine learning. arXiv:1909.01866. Retrieved from https://arxiv.org/abs/1909.01866.Google ScholarGoogle Scholar
  24. [24] Hamilton James Douglas. 2020. Time Series Analysis. Princeton University Press.Google ScholarGoogle ScholarCross RefCross Ref
  25. [25] He Kaiming, Zhang Xiangyu, Ren Shaoqing, and Sun Jian. 2015. Delving deep into rectifiers: Surpassing human-level performance on imagenet classification. In Proceedings of the IEEE International Conference on Computer Vision. 10261034.Google ScholarGoogle ScholarDigital LibraryDigital Library
  26. [26] Houy Nicolas. 2014. The Bitcoin mining game. Available at SSRN 2407834 (2014).Google ScholarGoogle Scholar
  27. [27] Houy Nicolas. 2014. The Economics of Bitcoin Transaction Fees. Working Papers 1407. Groupe d’Analyse et de Théorie Economique (GATE), Université Lyon 2. Retrieved May 2021 from http://EconPapers.repec.org/RePEc:gat:wpaper:1407.Google ScholarGoogle Scholar
  28. [28] Jules Ari, Eyal Ittay, and Kelkar Mahimna. 2021. Miners, Front-Running-as-a-Service Is Theft. Retrieved April 28, 2021 from https://bit.ly/3a8UPZs.Google ScholarGoogle Scholar
  29. [29] Kaskaloglu Kerem. 2014. Near zero bitcoin transaction fees cannot last forever. In the International Conference on Digital Security and Forensics (DigitalSec’14). 91–99.Google ScholarGoogle Scholar
  30. [30] Kuzmanovic Aleksandar. 2019. Net neutrality: Unexpected solution to blockchain scaling. Communications of the ACM 62, 5 (2019), 5055.Google ScholarGoogle ScholarDigital LibraryDigital Library
  31. [31] Li Juanjuan, Ni Xiaochun, Yuan Yong, and Wang Feiyue. 2020. A novel GSP auction mechanism for dynamic confirmation games on Bitcoin transactions. IEEE Transactions on Services Computing (2020), 1–1. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  32. [32] Li Juanjuan, Yuan Yong, and Wang Fei-Yue. 2019. A novel GSP auction mechanism for ranking Bitcoin transactions in blockchain mining. Decision Support Systems 124 (2019), 113094.Google ScholarGoogle ScholarDigital LibraryDigital Library
  33. [33] Lykourentzou Ioanna, Giannoukos Ioannis, Nikolopoulos Vassilis, Mpardis George, and Loumos Vassili. 2009. Dropout prediction in e-learning courses through the combination of machine learning techniques. Computers & Education 53, 3 (2009), 950965. DOI:Google ScholarGoogle ScholarDigital LibraryDigital Library
  34. [34] Ma Xiaolei, Yu Haiyang, Wang Yunpeng, and Wang Yinhai. 2015. Large-scale transportation network congestion evolution prediction using deep learning theory. PloS one 10, 3 (2015), e0119044.Google ScholarGoogle ScholarCross RefCross Ref
  35. [35] Messias Johnnatan, Alzayat Mohamed, Chandrasekaran Balakrishnan, and Gummadi Krishna P.. 2020. On blockchain commit times: An analysis of how miners choose Bitcoin transactions. The 2nd International Workshop on Smart Data for Blockchain and Distributed Ledger (SDBD’20).Google ScholarGoogle Scholar
  36. [36] Möser Malte and Böhme Rainer. 2015. Trends, tips, tolls: A longitudinal study of Bitcoin transaction fees. In Proceedings of the Financial Cryptography and Data Security: FC 2015.Springer, Berlin, 1933. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  37. [37] Nakamoto Satoshi et al. 2008. Bitcoin: A peer-to-peer electronic cash system. Decentralized Business Review (2008).Google ScholarGoogle Scholar
  38. [38] Nanda Saurav, Zafari Faheem, DeCusatis Casimer, Wedaa Eric, and Yang Baijian. 2016. Predicting network attack patterns in SDN using machine learning approach. In Proceedings of the 2016 IEEE Conference on Network Function Virtualization and Software Defined Networks. 167172. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  39. [39] O’Dwyer Karl J. and Malone David. 2014. Bitcoin mining and its energy footprint. (2014). Retrieved April 2021 from http://karlodwyer.com/publications/pdf/bitcoin_KJOD_2014.pdf.Google ScholarGoogle Scholar
  40. [40] Qureshi Haseeb. 2019. Blockchain fees are broken. Here are 3 proposals to fix them.Hacker Noon (2019). Retrieved from https://haseebq.com/blockchain-fees-are-broken/.Google ScholarGoogle Scholar
  41. [41] Ren Zhijie, Cong Kelong, welse Johan Pou, and Erkin Zekeriya. 2017. Implicit consensus: Blockchain with unbounded throughput. Retrieved June 29, 2017 from https://bit.ly/34VEzcD.Google ScholarGoogle Scholar
  42. [42] Rizun Peter R.. 2015. A transaction fee market exists without a block size limit. Block Size Limit Debate Working Paper (2015), 2327–4697.Google ScholarGoogle Scholar
  43. [43] Rizun Peter R.. 2016. Subchains: A technique to scale bitcoin and improve the user experience. Ledger 1 (2016), 3852. Retrieved from https://www.bitcoinunlimited.info/resources/subchains.pdf.Google ScholarGoogle ScholarCross RefCross Ref
  44. [44] Stolfo Salvatore, Fan David W., Lee Wenke, Prodromidis Andreas, and Chan P.. 1997. Credit card fraud detection using meta-learning: Issues and initial results. In Proceedings of the AAAI-97 Workshop on Fraud Detection and Risk Management.Google ScholarGoogle Scholar
  45. [45] Tahmassebpour Mahmoudreza. 2017. A new method for time-series big data effective storage. IEEE Access PP (2017), 11. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  46. [46] Tedeschi Enrico. 2022. Bitcoin blockchain optimized for machine learning prediction model. (2022). DOI:Google ScholarGoogle ScholarCross RefCross Ref
  47. [47] Tedeschi Enrico, Johansen Håvard D., and Johansen Dag. 2018. Trading network performance for cash in the bitcoin blockchain. In Proceedings of the 8th International Conference on Cloud Computing and Services Science.643650. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  48. [48] Tedeschi Enrico, Nordmo Tor-Arne S., Johansen Dag, and Johansen Håvard D.. 2019. Predicting transaction latency with deep learning in proof-of-work blockchains. In Proceedings of the 2019 IEEE International Conference on Big Data. IEEE, 42234231.Google ScholarGoogle ScholarCross RefCross Ref
  49. [49] Trafalis Theodore B. and Ince Huseyin. 2000. Support vector machine for regression and applications to financial forecasting. In Proceedings of the IEEE-INNS-ENNS International Joint Conference on Neural Networks. IJCNN 2000. Neural Computing: New Challenges and Perspectives for the New Millennium, Vol. 6. IEEE, 348353.Google ScholarGoogle ScholarCross RefCross Ref
  50. [50] Virtanen Pauli, Gommers Ralf, Oliphant Travis E., Haberland Matt, Reddy Tyler, Cournapeau David, Burovski Evgeni, Peterson Pearu, Weckesser Warren, Bright Jonathan, Walt Stéfan J. van der, Brett Matthew, Wilson Joshua, Millman K. Jarrod, Mayorov Nikolay, Nelson Andrew R. J., Jones Eric, Kern Robert, Larson Eric, Carey CJ, Polat İlhan, Feng Yu, Moore Eric W., erPlas Jake Vand, Laxalde Denis, Perktold Josef, Cimrman Robert, Henriksen Ian, Quintero E. A., Harris Charles R, Archibald Anne M., Ribeiro Antônio H., Pedregosa Fabian, Mulbregt Paul van, and Contributors SciPy 1. 0. 2019. SciPy 1.0–fundamental algorithms for scientific computing in python. Nature Methods 17 (2020). DOI:Google ScholarGoogle ScholarCross RefCross Ref
  51. [51] Wei William W. S.. 2006. Time series analysis. In Proceedings of the Oxford Handbook of Quantitative Methods in Psychology: Vol. 2.Google ScholarGoogle Scholar
  52. [52] Yazdinejad Abbas, HaddadPajouh Hamed, Dehghantanha Ali, Parizi Reza M., Srivastava Gautam, and Chen Mu-Yen. 2020. Cryptocurrency malware hunting: A deep recurrent neural network approach. Applied Soft Computing 96 (2020), 106630.Google ScholarGoogle ScholarDigital LibraryDigital Library
  53. [53] Zheng Yu, Liu Like, Wang Longhao, and Xie Xing. 2008. Learning transportation mode from raw gps data for geographic applications on the web. In Proceedings of the 17th International Conference on World Wide Web. ACM, 247256.Google ScholarGoogle ScholarDigital LibraryDigital Library
  54. [54] Zhu Y., Guo R., Gan G., and Tsai W.. 2016. Interactive incontestable signature for transactions confirmation in bitcoin blockchain. In Proceedings of the 2016 IEEE 40th Annual Computer Software and Applications Conference.443448. DOI:Google ScholarGoogle ScholarCross RefCross Ref
  55. [55] Zur Roi Bar, Eyal Ittay, and Tamar Aviv. 2020. Efficient MDP analysis for selfish-mining in blockchains. In Proceedings of the 2nd ACM Conference on Advances in Financial Technologies. 113–131.Google ScholarGoogle Scholar

Index Terms

  1. On Optimizing Transaction Fees in Bitcoin using AI: Investigation on Miners Inclusion Pattern

          Recommendations

          Comments

          Login options

          Check if you have access through your login credentials or your institution to get full access on this article.

          Sign in

          Full Access

          • Article Metrics

            • Downloads (Last 12 months)641
            • Downloads (Last 6 weeks)63

            Other Metrics

          PDF Format

          View or Download as a PDF file.

          PDF

          eReader

          View online with eReader.

          eReader

          HTML Format

          View this article in HTML Format .

          View HTML Format
          About Cookies On This Site

          We use cookies to ensure that we give you the best experience on our website.

          Learn more

          Got it!