XmrBazaar (beta)

On September 14, 2025, a malicious mining pool successfully performed an 18-block "blockchain reorganization" of the Monero blockchain. Qubic, the mining pool, used its mining hashpower to generate an alternative blockchain history and replaced about 70 minutes of the honest chain's most recent history.

The main effect of the reorganization ("reorg" for short) was the invalidation of 115 transactions that had been included in the original honest chain. The coins in the transactions that were invalidated did not disappear. It is simply as if the transactions never occurred at all. The coins sent by the invalidated transactions returned to the sender's wallet and it is as if the recipients' wallets never received the coins.

Monero's protocol requires that users wait for 10 blocks before spending coins that they have just received. Since blocks are produced at a rate of one every 2 minutes on average, that's a 20 minute wait, on average. The wait is an annoyance for users, but it serves an important purpose.

In normal circumstances, Monero's "10 block lock" prevents transaction invalidation, but in this extreme case of an 18-block reorg, the 10 block lock was overwhelmed and did not prevent the 115 transactions from being invalidated. In this post, will see how the much-hated, but misunderstood, 10 block lock on spending newly-received Monero coins can prevent transaction invalidation on short reorgs and how things go wrong when the reorgs are deeper.

Due to forum post length restrictions, please continue reading this post on my blog.

I never bothered to look into the "reorg" thing because I trusted Monero Devs would solve the problem.

Thank you Ruck for this concise summary.

Hello, is there any ETA about selfish mining patch, solutions and deadlines ? I m interested in reading more about those discussions

Nice write up. The last bit is important. Nobody wants cancelled transactions, so hope they can firm up the reorg resistance.

Qubic's hashpower is lower now and they haven't attempted selfish mining in about a week. Of course, we want solutions deployed ASAP, but the problem doesn't seem quite as urgent as it did recently.

Many people have worked on getting DNS rolling checkpoints: https://github.com/monero-project/monero/issues/10064 working well. There is one outstanding issue where nodes can fail to sync new blocks if a specific sequence of events occurs. ofrnxmr and 0xfffc are working on it. jberman may join the effort to fix it soon. Once the fix is developed, the technical side should be finished, but some major mining pools have to adopt DNS rolling checkpoints for it to be effective.

On longer-term fixes: Selfish mining was first proposed in 2014 and many, many mitigations have been proposed. Most of them try to reduce the direct economic incentive to mine selfishly, i..e they reduce the share of the block reward that the selfish miner gets. Qubic isn't really motivated by the direct reward. In fact, they often earn less XMR when trying to selfish mine. Their motivation is probably more in the propaganda value of selfish mining. Something with more teeth is needed. tevador last week proposed Share or Perish, which could have a direct effect on the ability of a malicious miner to perform deep reorgs: https://github.com/monero-project/research-lab/issues/146 . This would not require a hard fork to implement.

Every Wednesday the issue is on the Monero Research Lab agenda: https://github.com/monero-project/meta/issues?q=is%3Aissue%20%22monero%20research%20lab%22 . You can join the IRC or Matrix channel to follow discussion or just look at the live log: https://libera.monerologs.net/monero-research-lab