Summary
Centralized mining pools are delaying the first confirmation of Monero transactions by a full minute, on average. This makes Monero confirmations slower than Litecoin even though Litecoin’s average block time is 2.5 minutes, compared to Monero’s 2 minutes flat. Mining pool operators could solve this issue by adding new transactions to their block templates more frequently, like P2Pool already does.
The Isabellas are getting kicked off the bus
txstreet.com is an animated visualization of the Monero transaction confirmation process.
When a Monero user submits a transaction to the Monero network, an “Isabella” character appears in the mempool of every node in the network. The mempool is the group of transactions waiting to be confirmed in a block by miners. The Isabellas get on the “bus” that represents a block template waiting to be mined.
When the light on txstreet turns from red to green, a miner has mined a block. The Isabellas on the bus can join the blockchain and become confirmed transactions. But wait! Just before the bus drives off into the blockchain, a bunch of Isabellas are kicked off the bus! What happened? Was the bus full?
No, the bus wasn’t full. txstreet assumes that the Isabellas in the mempool are on the bus. In technical terms, txstreet incorrectly assumes that every mining pool’s block template contains all the transactions in the mempool.
Mining pools delay transactions
When a block is mined, ideally all transactions in the mempool are confirmed as long as the total size (in kilobytes) of the transactions in the mempool does not exceed the dynamic block size limit. (Monero blocks rarely reach the block size limit.) The diagram below shows this ideal case.
Every block contained all the transactions that arrived in the mempool before the block was mined, even if the transactions arrived a few seconds before the block. Below is a diagram showing what most mining pools are actually doing. It is not the ideal case.
Most mining pools put transactions in their block templates only once: when the previous block has been mined. They never update their block templates. This decision causes long delays for users wanting their transactions to be confirmed quickly. In effect, users need to wait for two blocks to be mined rather than one block. The Isabellas are being kicked off the bus. Or, rather, they were never on the bus to begin with.
P2Pool, a decentralized mining protocol, only waits ten seconds to put a new transaction into its block template. When centralized pools and P2Pool are mining blocks, the transaction confirmation process looks like this:
P2Pool includes transactions in its block that arrived both before and after the red pool mined its block. Before, the average delay of transaction mined by the blue pool was 3.8 minutes. When P2Pool mines the block instead of the blue pool, the average delay is reduced to 2.1 minutes in this hypothetical example. P2Pool also includes more transactions in its block because it is capturing transactions over a longer period of time. Doesn’t this mean that P2Pool earns more transaction fee revenue per block than centralized pools? Yes! About 0.004 XMR more, on average. Multiplying by all the blocks that P2Pool has mined since beginning in September 2021 gives an estimated 72 XMR additional revenue for P2Pool miners. Currently, P2Pool is mining about 10 percent of Monero’s blocks.
Data
The blockchain data alone is not enough to measure transaction confirmation delays. The blockchain contains the approximate time of each transaction’s confirmation but has no data on when each user sent their transaction. Constant monitoring of a Monero node’s mempool contents is necessary. I collected data from five Monero nodes between December 21, 2022 and January 18, 2023. For comparison I did the same with several other payment-oriented proof-of-work coins: Litecoin (LTC), Bitcoin Cash (BCH), and Dogecoin (DOGE). I collected data from only two nodes each of these comparison coins to conserve computing resources. Bitcoin (BTC) is not a good comparison coin. The contents of its mempool usually exceed its block size limit, so a block confirmation would not empty the mempool no matter how often miners updated their block templates.
It is a good idea to collect data from multiple nodes because transactions will not arrive to all nodes at the same time. The position of each node in the network and the speed of communication between nodes will affect the recorded arrival time of transactions at any particular node. In practice, these differences turned out not to be big enough to matter much for this confirmation delay analysis. About 50 percent of all transactions arrived at all five Monero nodes within a two-second interval. 95 percent all transactions arrived at all five Monero nodes within a five-second interval. To reconcile these difference in arrival times, the median arrival time was computed.
Each Monero block contains a timestamp that is used to calculate mining difficulty adjustment. The timestamps only need to follow loose blockchain consensus rules and are not a precise metric of the actual time that a block was mined. Therefore, I also recorded the time that each block arrived at the Monero nodes and computed the median. There was less variance in the arrival time of blocks than transactions. About 80 percent of blocks arrived at all five Monero nodes within a one-second interval.
Analysis
Miners mining blocks and users sending transactions are both random processes. We cannot say exactly when a mining pool has updated its block template. The best guess is to take the difference between when a block was mined and the time when the youngest transaction in that block was sent to the network. This can be described as the time between transactions entering the mempool and becoming candidates for confirmation on the blockchain. Below is a boxplot of this time-to-eligibility for several centralized mining pools and P2Pool.
The edges of the boxes are the 25th and 75th percentiles of the data. The vertical line in the middle of the boxes is the median. The blue diamond is the mean. The ends of the long lines are the 5th and 95th percentiles.
P2Pool is a clear outlier. A transaction usually becomes a candidate for confirmation in under 30 seconds if it ends up being confirmed by P2Pool. Several pools have an average of about two minutes. This is no coincidence. It is the average time interval between Monero blocks. These mining pools are generally updating their block templates when the previous block has been mined.
If P2Pool’s average delay in including transactions in its block template were substituted for the delay of all Monero transactions, the average Monero transaction would confirm about 70 seconds faster. In other words, if centralized mining pools matched P2Pool’s block template update configuration, Monero users would see their transactions receive their first confirmation a full minute faster than now.
Below, a set of histograms provides another way to visualize block template update behavior. It shows the difference between the time of the youngest (the most recently sent) transaction confirmed in every block and the time that the previous block was mined.
The histogram for P2Pool is what we would expect if a pool were updating its block template frequently. The smooth black line is the theoretical probability of a block being mined with the passage of time. Block mining is a “memoryless” process so the time intervals between mined blocks is an exponential probability distribution. The P2Pool histogram roughly follows the exponential distribution: The youngest transaction in the mempool is usually confirmed by the P2Pool blocks, so the age of the youngest transaction in the block is roughly the same as the mined P2Pool block.
Most of the centralized pools have a single large spike at zero, which shows that they are updating their block templates only when the previous block has been mined. monero.hashvault.pro seems to update its block template every two minutes if a block hasn’t been mined before then. xmrpool.eu usually updates its templates when the previous block is mined, but occasionally it updates its templates after a random amount of time has passed.
Comparison with LTC, BCH, and DOGE
The same comparison between Monero pools can be done with payment-oriented proof-of-work blockchains like Litecoin (LTC), Bitcoin Cash (BCH), and Dogecoin (DOGE). Below is a boxplot comparing the transactions' time to become candidates for blockchain confirmation.
The bulk of all coins' transactions become candidates for confirmation in less than 60 seconds, except for Monero. Transactions confirmed by P2Pool become candidates at about the same time as Litecoin transactions.
The next graph show the actual delay between when a user sends a transaction and when it is confirmed on the blockchain. Each coin’s blockchain consensus rules aim for a different average time between mined blocks, so timing differences are expected. Monero’s target block time is 2 minutes; Litecoin’s is 2.5 minutes; Bitcoin Cash’s is 10 minutes; Dogecoin’s is 1 minute.
Monero’s average time to first transaction confirmation is actually 45 seconds longer than Litecoin’s.
Conclusion
Does Monero’s unnecessary one-minute delay in transaction confirmations matter? For users buying from merchants that require zero confirmations or 100 confirmations, probably not. For a user waiting in the checkout line of a physical store that requires a single confirmation, the extra minute would be hard to tolerate.
Why are centralized pools failing to update their block templates more frequently? They are losing money to P2Pool and degrading the Monero user experience. It is possible that they are trying to reduce the computer infrastructure costs needed to perform the database operations that happen when the hashes of new block templates are sent to the client miners. More likely, they have just accepted the defaults in their mining software.
The monero.hashvault.pro mining pool proves that it’s possible for centralized pools to update their block templates more frequently. Every 30 seconds is reasonable. Every 10 seconds would be nice if the database operations are not expensive.
DataHoarder contributed code to gather mined block data from centralized mining pools. plowsof and the Monero Research Lab’s research computing server contributed computing resources for mempool data gathering. SChernykh/sech1 helped me understand details of mining pool behavior.
Code to reproduce this analysis is available here. The data files are available here.
If you enjoyed this article, consider supporting my work with a donation of BCH, XMR, BTC, or WOW.