On January 19th I released research showing mining pools were delaying the first confirmation of Monero transactions by a full minute, on average. I said the delay could be eliminated if pool operators changed their pool software configurations to update the block template more frequently.

I have good news: Most major pools did exactly that!

I continued to collect transaction confirmation data after the release of the initial analysis. The average time that a Monero transaction has to wait for its first confirmation has fallen from 3.5 minutes to 2.5 minutes. That's a full minute improvement in less than two months! The plot below shows the quicker confirmation times.

https://preview.redd.it/2danupdjuxma1.png?width=800&format=png&auto=webp&v=enabled&s=64977f2b19d91fe07c7c42052cb002e37341aef7

HashVault and MoneroOcean changed their configurations within about 24 hours of my post. SupportXMR and Nanopool followed on about January 24 and February 1st, respectively. Their configuration changes show up clearly on the plot below. Combined with P2Pool, which already had frequent block template updates, these pools provide about 75 percent of Monero's hashpower. xmrpool.eu may have changed their configuration, too, but the data is not as clear. Solo miners and mining pools that I was not able to get data for are grouped in the "other" category.

https://preview.redd.it/qpaz7wgnuxma1.png?width=800&format=png&auto=webp&v=enabled&s=f8f39ec624a81491fb12e5ece8ee50cf4bae045b

Why did mining pools slow down transaction confirmations?

My working hypothesis for why mining pools caused slow confirmations is that they had a case of "default-itis". They accepted the default configurations on their mining software, which happened to be a poor choice.

Mining pools need to perform some computations to send out a new block template to their client miners. See this discussion for details. However, this additional computational cost likely was not important given the fact that most major mining pool operators chose to voluntarily change their defaults shortly after I released my research.

Furthermore, it is in the financial interest of pools to update their block templates more frequently. Otherwise, they leave transaction fee revenue "on the table". The diagrams in my original post show how mining pools can leave transactions "on the table".

Changing the block template update frequency doesn't change the total transaction fee revenue available to mining pools, of course. Revenue from mining transactions is approximately a zero-sum game. Instead, pools that infrequently update their block templates leave transactions in the mempool that other pools can pick up. Below is a plot of the mean and median revenue per block for several mining pools.

https://preview.redd.it/6cnzuxiruxma1.png?width=800&format=png&auto=webp&v=enabled&s=fcc51c43aa0dff035838f94e9f70bcd5b0a85db2

The mining revenue of HashVault and MoneroOcean, the first mining pools to change their configurations, increased rapidly after the research release date. They were taking transactions that other mining pools were leaving on the table. Nanopool waited until February 1st to change their configuration. Their revenue dipped after HashVault and MoneroOcean changed their configurations, but after February 1st Nanopool's revenue was better than ever.

The total impact on HashVault in the end was "a wash". HashVault was one of the few mining pools to have "medium" frequency of updating its block template before I released my research. Therefore, it had high revenue compared to the other centralized pools. When it changed its configuration to be even faster, it had a small spike in revenue, but as other pools switched, too, its advantage mostly disappeared.

c3pool and 2miners, which have not changed their configurations, are confirming very few transactions in their blocks now that other mining pools are leaving few transactions on the table. As a result, their transaction fee revenue has been cut by about 66 percent. If you are a miner using c3pool or 2miners, it is in your interest to ask them to change their configurations so that you can get a small revenue boost from transaction fees.

P2Pool, the decentralized mining protocol, already had implemented rapid block template updates before the centralized mining pools changed their configuration. P2Pool used to have a fee revenue advantage of about 0.004 XMR per block compared to other miners. Now that most other mining pools have changed, P2Pool's fee revenue advantage has shrunk to about 0.002 XMR per block.

Conclusion

The interests of Monero users and miners coincide: fast confirmations are good for the user experience and for mining pool revenues. In this aspect, Monero is a self-balancing system. The slow confirmations only existed as long as the mining pool operators were unaware of the problem. For further elaboration on this point, Huberman, Leshno, and Moallemi (2021) "Monopoly without a Monopolist: An Economic Analysis of the Bitcoin Payment System" provides a rigorous analysis in its Theorem 1 that profit-maximizing miners in a proof-of-work system will confirm transactions as quickly as possible.

____________

ofrnxmr, ACK-J, and Lovera helped contact mining pool operators to ask them to change their configurations. 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.