Monero's 18-block reorg: What happened, why it matters, and what does it have to do with the annoying 10 block lock?

Rucknium

N/A (0)

Posts: 2

Earned: 0.06 XMR

Tipped: 0 XMR

Sep 26 17:52

(6)

(0)

#311

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.

Edited: Sep 26 17:56

Tipped 0.06 XMR by 2 users

Tip Monero to Rucknium

86PW2MA9m18bXWH4UcR1JL4gB2GL88yPE2HH2vAAxh2L44MA27qF3eS2hqTyyhQ5qGYRaED9RpietMCehN5t3x5B5DV4Xp1

Publish Tip to Rucknium

Please login to publish your tip

CharliePrime

N/A (0)

Posts: 22

Earned: 0 XMR

Tipped: 0 XMR

Sep 27 11:38

(1)

(0)

#315

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.

Tip Monero to CharliePrime

CharliePrime has not setup a {COIN} tip address yet.

Publish Tip to CharliePrime

CharliePrime has not setup a {COIN} tip address yet.

coincartstore

5 (7)

Posts: 2

Earned: 0 XMR

Tipped: 0 XMR

Sep 28 12:04

(1)

(0)

#321

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

Tip Monero to coincartstore

coincartstore has not setup a {COIN} tip address yet.

Publish Tip to coincartstore

coincartstore has not setup a {COIN} tip address yet.

crabrocket

N/A (0)

Posts: 9

Earned: 0 XMR

Tipped: 0 XMR

Sep 29 09:18

(1)

(0)

#333

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

Tip Monero to crabrocket

crabrocket has not setup a {COIN} tip address yet.

Publish Tip to crabrocket

crabrocket has not setup a {COIN} tip address yet.

Rucknium

N/A (0)

Posts: 2

Earned: 0.06 XMR

Tipped: 0 XMR

Oct 1 01:28

(4)

(0)

#344

Reply to post #321

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

Edited: Oct 1 01:29

Tip Monero to Rucknium

86PW2MA9m18bXWH4UcR1JL4gB2GL88yPE2HH2vAAxh2L44MA27qF3eS2hqTyyhQ5qGYRaED9RpietMCehN5t3x5B5DV4Xp1

Publish Tip to Rucknium

Please login to publish your tip

XmrBazaar

Monero's 18-block reorg: What happened, why it matters, and what does it have to do with the annoying 10 block lock?