Table of Links
CHAPTER 1: INTRODUCTION
CHAPTER 2: BACKGROUND
2.1 Blockchains & smart contracts
2.2 Transaction prioritization norms
2.3 Transaction prioritization and contention transparency
2.5 Blockchain Scalability with Layer 2.0 Solutions
CHAPTER 3. TRANSACTION PRIORITIZATION NORMS
CHAPTER 4. TRANSACTION PRIORITIZATION AND CONTENTION TRANSPARENCY
-
Transaction Prioritization and Contention Transparency
4.2 On contention transparency
CHAPTER 5. DECENTRALIZED GOVERNANCE
CHAPTER 6. RELATED WORK
6.1 Transaction prioritization norms
6.2 Transaction prioritization and contention transparency
CHAPTER 7. DISCUSSION, LIMITATIONS & FUTURE WORK
7.3 Voting power distribution to amend smart contracts
Appendices
APPENDIX A: Additional Analysis of Transactions Prioritization Norms
APPENDIX B: Additional analysis of transactions prioritization and contention transparency
APPENDIX C: Additional Analysis of Distribution of Voting Power
3 Transaction Prioritization Norms
In this chapter, we delve into the research questions, methodology, and the implications of analyzing and comprehending the norms employed by miners when prioritizing transactions for inclusion. Understanding these prioritization norms is key to enable transaction issuers to determine the appropriate fees for their transactions to be included within an expected number of blocks.
The order in which miners select transactions for inclusion have significant implications for the ultimate outcome of the transaction execution. As a result, we aim to audit the Bitcoin blockchain to address the following research questions.
▶ RQ 1: Which transactions are allowed or transmitted over the public P2P network? This research question pertains to the norm III, as described in §2.2. It assumes that transactions with fee rate below a minimum threshold are discarded and never committed to the blockchain. If miners are considering transactions with incentives below the established threshold, their view of available transactions for inclusion may differ.
▶ RQ 2: How do miners select transactions for inclusion in a block once they enter the miners’ Mempool? This research question pertains to norm I, which states that miners select transactions for inclusion, from the Mempool, based solely on their fee rates. However, if some miners accept additional incentives to accelerate the transaction confirmation such as dark or opaque fees, the miners’ view of the offered fees may vary. As a result, transaction issuers may struggle to estimate the appropriate fees needed for their transaction to be prioritized, as the fees’ distribution may differ based on individual miner’s view of the system.
▶ RQ 3: In what order do miners include transactions within a block? This question aligns with norm II, where higher fee rate transactions are prioritized and placed before lower fee rate transactions during the block construction. If miners misplace transactions within a block, it can result in different outcomes for those transactions when the miner’s block is selected as the next block. Transaction issuers may be susceptible to well-known
attacks such as front-running (Daian et al., 2020; Torres et al., 2021) or even sandwich attacks (Qin et al., 2021; Zhou et al., 2023).
Addressing these research questions is crucial for understanding how miners actually prioritize transactions for inclusion. Hence, accurate knowledge of the order in which miners include transactions can assist in estimating appropriate fees that issuers need to offer to prioritize their transactions. Next, we discuss our methodology for gathering the necessary data sets and detecting accelerated or highly prioritized transactions.
Relevant publication
The results presented in this chapter have been published in (Messias et al., 2020, 2021).
3.1 Methodology
To understand the importance of transaction ordering to issuers and to investigate when and how miners violate the transaction prioritization “norms,” we resort to an empirical, data-driven approach. Below, we briefly describe three different data sets that we curated from Bitcoin and highlight how we use the data sets in different analyses in the rest of this thesis. Furthermore, we present our methodology for detecting transaction acceleration, which can be applied to any fee-based incentive blockchains.
3.1.1 Data set collection
Data set A. To check miners’ compliance to prioritization norms in Bitcoin, we analyzed all transactions and blocks issued in Bitcoin over a three-week time frame from
February 20 through March 13, 2019 (see Table 3.1). We obtained the data by running a full node, a Bitcoin software that performs nearly all operations of a miner (e.g., receiving broadcasts of transactions and blocks, validating the data, and re-broadcasting them to peers) except for mining. The data set also contains a set of periodic snapshots, recorded once per 15 seconds for the entire three-week period, where each snapshot captures the state of the full node’s Mempool. We plot the distribution of the count of blocks and transactions mined by the top-20 MPOs for data set A in Figure 3.1a. If we rank the MPOs in data set A by the number of blocks (B) mined (or, essentially, the approximate hashing capacity h), the top five MPOs turn out to be BTC.com (B: 536; h: 17.18%), AntPool (B: 399; h: 12.79%), F2Pool (B: 352; h: 11.29%), Poolin (B: 344; h: 11.03%), and SlushPool (B: 279; h: 8.94%). We use this data for checking whether miners adhere to prioritization norms when selecting transactions for confirmation or inclusion in a block.
Data set B. Differences in configuration of the Bitcoin software may subtly affect the inferences drawn from data set A. A full node connects to 8 peers, for instance, in the default configuration, and increasing this number may reduce the likelihood of missing a transaction due to a “slow” peer. The default configuration also imposes a minimum fee rate threshold of 1 sat/B (or 1 satoshi-per-byte) for accepting a transaction. We instantiated, hence, another full node to expand the scope of our data collection. We configured this second node, for instance, to connect to as many as 125 peers. We also removed the fee rate threshold to accept even zero-fee transactions. B contains Mempool snapshots of this full node, also recorded once per 15 s, for the entire month of June 2019 (refer Table 3.1). We notice that 99.7% of the transactions received by our Mempool were included by miners. Figure 3.1b shows the distribution of the count of blocks and transactions mined by the top-20 MPOs for data set B. The top five MPOs are BTC.com (B: 889; h: 19.67%), AntPool (B: 577; h: 12.77%), F2Pool (B: 523; h: 11.57%), SlushPool (B: 438; h: 9.69%), and Poolin (B: 433; h: 9.58%).
Data set C. The insights derived from the above data motivated us to shed light on the aberrant behavior of mining pool operators (MPOs). To this end, we gathered all (53,214) Bitcoin blocks mined and their 112,542,268 transactions from January 1st to December 31st 2020. These blocks also contain one Coinbase transaction per block, which the MPO creates to receive the block and the fee rewards. This data set, labeled C, contains 112,489,054 issued transactions (see Table 3.1). MPOs typically include a signature or marker in the Coinbase transaction, probably to claim their ownership of the block. Following prior work (e.g., (Judmayer et al., 2017; Romiti et al., 2019)), we use such markers for identifying the MPO (owner) of each block. We failed to identify the owners of 703 blocks (or approximately 1.32% of the total), albeit we inferred 30 MPOs in our data set. In this thesis, we consider only the top-20 MPOs whose combined normalized hash-rates account for 98.08% of all blocks mined. Figure 3.1c shows the count of blocks mined by the top-20 MPOs according to C. The top five MPOs in terms of the number of blocks (B) mined are F2Pool (B: 9326; h: 17.53%), Poolin (B: 7876; h: 14.80%), BTC.com (B: 6381; h: 11.99%), AntPool (B: 5832; h: 10.96%), and Huobi (B: 3990; h: 7.5%).
3.1.2 Detecting accelerated transactions.
Given the high fees demanded by acceleration services, we anticipate that accelerated transactions would be included in the blockchain with the highest priority, i.e., in the first few blocks mined by the accelerating miner and amongst the first few positions within the
block. We would also anticipate that without the acceleration fee, the transaction would not stand a chance of being included in the block based on its publicly offered transaction fee. The above two observations suggest a potential method for detecting accelerated transactions in the Bitcoin blockchain: An accelerated transaction would have a very high signed position prediction error (SPPE) (refer to §3.3.1), as its predicted position based on its public fee would be towards the bottom of the block it is included in, while its actual position would be towards the very top of the block.
To test the effectiveness of our method, we analyzed all 6381 blocks and 13,395,079 transactions mined by BTC.com mining pool in data set C. We then extracted all transactions with SPPE greater or equal than 100%, 99%, 90%, 50%, 1% and checked what fraction of such transactions were accelerated, according to the BTC.com transaction accelerator API (BTC.com, 2022).
Author:
(1) Johnnatan Messias Peixoto Afonso
This paper is
