Monero Under Attack: How the Community Responds to Selfish Mining Attacks
## **The September 14th Nightmare**
On September 14th, 2025, merchants and exchanges woke up to discover that 55 transactions they believed to be confirmed had simply disappeared from the Monero network. Money that was "guaranteed" in their wallets had vanished. Already processed payments were invalidated. Transfers that seemed complete never happened.
bitmonero.log on my own node
This wasn't a casual bug or technical glitch. It was the result of a coordinated and devastating attack that shook one of the world's most respected privacy-focused cryptocurrencies.
**What happened technically:** An 18-block "reorg" (reorganization) hit the Monero network - meaning that 18 blocks the entire network believed to be valid and permanent were suddenly discarded and replaced by an alternative version of history. To put this in perspective, reorganizations of more than 2-3 blocks are extremely rare in established blockchain networks.
**The financial outcome:** 55 confirmed double spends (the same money spent twice) and 115 transactions completely invalidated. While we cannot know whether these were merchants, exchanges, or individuals transacting, this matters little in the face of real double spending scenarios - someone lost real money.
This situation forced the Monero developer community into an emergency meeting to discuss urgent solutions. What emerged from this discussion were four controversial proposals, each with their own trade-offs between security, decentralization, and practicality.
## **Watch on Youtube (pt-BR)**
## **Understanding the Attack Mechanics**
### **How Selfish Mining Works**
Before diving into the proposed solutions, it's crucial to understand how the Qubic entity managed to execute this attack. [Selfish mining is a theoretical concept known since 2014](https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf?ref=eddieoz.com), but rarely seen in action at significant scale.
**The Qubic Scheme:**
1. **Artificial Incentive**: The Qubic pool created its own token and rewards miners with this additional token beyond normal Monero rewards. This makes mining on their pool artificially more profitable.
2. **Secret Parallel Mining**: With concentrated hashrate, they mine a parallel chain in secret, keeping blocks without transmitting them to the network.
3. **Strategic Accumulation**: While the main network continues normally, they accumulate an increasingly larger sequence of valid blocks.
4. **Devastating Release**: At the strategic moment, they release the entire secret chain at once. Since it's longer than the main chain, Bitcoin/Monero consensus rules force the network to accept this new chain as the "true" one.
5. **Catastrophic Result**: All blocks from the original chain are discarded, making "confirmed" transactions disappear and enabling double spending.
[https://x.com/torrents/status/1967273551070974382/photo/1](https://x.com/torrents/status/1967273551070974382/photo/1?ref=eddieoz.com)
### **Why Monero Was Vulnerable: The Decentralization Paradox**
It's important to clarify that Monero's vulnerability doesn't come from a technical "weakness" compared to Bitcoin. Monero uses the RandomX algorithm (CPU-based), while Bitcoin uses SHA-256 (ASIC-based) - **these are completely incompatible technologies**. Bitcoin's hashrate cannot be used to attack Monero, just as Monero's hashrate cannot be used against Bitcoin.
The real problem reveals a philosophical paradox in Monero's approach:
#### **The CPU-Only Mining Philosophy**
Since 2014, Monero has undergone multiple algorithm changes to maintain "egalitarian mining" - the idea that anyone with a regular computer can mine. RandomX, implemented in 2019, was designed to be "a final attempt to block specialized mining hardware."
**The Promise:** Preventing ASICs would ensure decentralization, since anyone could mine with common CPUs.
**The Reality:** Even without ASICs, mining still concentrated in pools. Currently, 2-3 pools control the majority of Monero's hashrate.
#### **The ASIC vs CPU Debate: Two Visions of Decentralization**
**Pro-CPU Arguments (Monero's Current Position):**
- **Accessibility**: "Practically everyone in the world now has a smartphone in their pocket with a CPU and memory capable of mining RandomX"
- **Monopoly Prevention**: ASICs create entry barriers through high costs and limited suppliers
- **Democratic Control**: Prevents geographical concentration of mining farms
**Pro-ASIC Arguments (Controversial Position):**
- **The Decentralization Paradox**: ASIC defenders argue that once ASICs become widely available and cheap, anyone can buy them and mine - potentially creating more participants than current CPU mining. The current problem is that only a few pools dominate, even with "accessible" CPUs.
- **Development Centralization**: Critics of ASIC resistance argue that maintaining this philosophy creates dangerous dependence on developers. Since Monero has changed its algorithm 5 times since 2014 to combat ASICs, the network becomes totally dependent on developers' capacity and willingness to implement constant changes. This may decentralize mining, but centralizes decision-making power over the network's future in a small group of technical developers.
- **Stability vs Agility**: With established ASICs, the protocol wouldn't need to change constantly. Miners would have dedicated hardware with long-term interest in network security, instead of CPUs that can easily migrate to other projects (as seen in the Qubic attack).
- **Economic Reality**: ASIC resistance may be fundamentally impossible long-term, especially if Monero's value grows significantly, making specialized hardware development economically viable.
#### **How the Qubic Attack Exploited This Vulnerability**
The attack wasn't about ASIC vs CPU technology - it was about **concentration through economic incentives**:
1. **Artificial Rewards**: The Qubic pool created its own token, offering extra rewards to miners
2. **Hashrate Concentration**: They managed to go from 10% to over 40% of total hashrate
3. **Philosophy Exploitation**: They used the ease of pool switching (advantage of CPU mining) against the network itself
#### **The Paradox Revealed**
The Qubic attack exposed a fundamental contradiction:
- **CPU mining** was designed to prevent hardware concentration
- But **doesn't prevent pool concentration**, which is where the attack actually happened
- Miners with **dedicated hardware have greater economic interest** in long-term network security, as they made significant investments that only pay off if the network remains healthy and valuable
- CPU miners can easily stop mining Monero and use their computers for other activities, while ASICs only serve one specific cryptocurrency
#### **The Question of Dedicated Investment**
Some in the community argue that miners with substantial investments in specialized hardware have economic incentives more aligned with network security:
- **Long-term Interest**: ASIC miners made investments that only recover over years, creating strong incentive to keep the network secure and valuable
- **Financial Commitment**: Unlike CPU miners who can easily migrate to other activities, ASIC miners have "skin in the game" - their investment is only valuable if Monero prospers
This isn't a critique of RandomX or Monero's philosophy - it's recognition that **decentralization is a complex problem** that goes beyond mining algorithm choice.
## **The Four Solutions Under Debate**
The Monero developers' emergency meeting generated four distinct proposals to combat selfish mining attacks. Each solution represents a unique trade-off between security, decentralization, and technical viability.
**Note on the Discussion:** While four solutions were identified as options, the [September 17, 2025 meeting](https://github.com/monero-project/meta/issues/1268?ref=eddieoz.com#issuecomment-3313805186) focused predominantly on DNS Checkpoints, with Publish or Perish and Lucky Transactions being mentioned only briefly. The detailed analysis of these proposals comes from their technical specifications in GitHub repositories.
### **1. DNS Checkpoints: The Controversial Solution**
**The Proposal:**
The DNS checkpoints system uses 4-7 distinct DNS domains to store "checkpoints" - references that identify the correct version of the blockchain at specific moments. When a suspicious reorganization is detected, nodes consult these domains to verify which chain should be considered legitimate. ([https://github.com/monero-project/monero/issues/10064](https://github.com/monero-project/monero/issues/10064?ref=eddieoz.com))
**How it Works:**
- Trusted entities maintain specific DNS domains
- Blocks mined by known pools are authenticated and registered in these domains
- During reorganizations, nodes consult at least 5 of the 7 domains
- The version approved by the majority of domains is considered legitimate
**Advantages:**
- **Quick Implementation**: The code already exists in Monero, needing only to be activated
- **Proven Effectiveness**: Worked against Bitmain's attacks in 2018
- **Low Impact**: Doesn't require a hard fork, only client-side changes
**The Devastating Criticisms:**
During EddieOz's analysis and community discussions, fierce criticisms emerged against this proposal:
- **Unacceptable Centralization**: As kayabanerve put it in the meeting: "I have objections to it, I just don't see value in voicing them. The concept is so centralizing I'd say it's unacceptable." The proposal essentially places final authority over the blockchain state in the hands of some internet domains.
- **Massive Attack Surface**: As spher_cosmo pointed out, this "increases attack surface". It's much easier to DDoS domains, hack web servers, or force legal takedowns than to attack a distributed blockchain.
- **Privacy Issues**: As user A8 astutely observed: "Whoever queries leaves a trace." Each checkpoint query can be logged, tracked, and potentially used to map the Monero network.
- **Dangerous Precedent**: As rbrunner warned: "I just want to warn about the alarming tendency of band-aids becoming permanent."
**EddieOz's Position:**
"I don't think that's the way. You're placing trust in blockchain history in four internet domains. That's not what it was created for, right? To function alone, without you needing to trust anyone."
### **2. Publish or Perish (POP): The Technical Favorite**
**The Proposal:**
"Publish or Perish" represents an elegant approach to the problem: force miners to publish blocks immediately or lose the chance to include them in the main chain. This solution specifically targets selfish mining attacks when the attacker possesses between 25-50% of the hashrate.
**Technical Functioning:**
The proposal [monero-project/research-lab#144](https://github.com/monero-project/research-lab/issues/144?ref=eddieoz.com) presents two variants:
**Soft Fork Version:**
- Introduces concept of "late blocks"
- Blocks arriving >5 seconds after another block of the same height are considered "late"
- Late blocks don't contribute to chain weight
- Uses "uncle blocks" to track information from alternative chains
- Requires attacker to mine 3 more blocks than the honest chain to cause reorg
- Reduces attacker's potential rewards from \~88% to \~64%
**Hard Fork Version (More Robust):**
- Reduces block time to 60 seconds
- Increases coinbase maturity to 1,440 blocks (1 day)
- Implements "Reward Splitting" - divides rewards between current miners and uncle block miners
- Aims to completely eliminate economic incentives for selfish mining
**Why It Works:**
This solution attacks the core of the selfish mining strategy. If you can't accumulate blocks in secret, you can't execute the attack. It's like forcing all poker players to show their cards as they receive them.
**Technical Parameters:**
- `k = 3` (blocks more than honest chain)
- `D = 5` seconds (propagation delay)
- Reward reduction to 0.3 XMR
**Honest Limitations:**
- **Doesn't Solve 51%**: Only effective against attackers with <50% hashrate
- **Implementation Complexity**: Especially the hard fork version
- **Network Synchronization**: May penalize miners with poor connectivity
- **Still Theoretical**: Awaits simulations and deeper analysis
**EddieOz's Approval:**
"Publish or Perish I found most interesting among them. More than putting a probabilistic layer."
### **3. Lucky Transactions: The Probability System**
**The Proposal:**
This solution [monero-project/research-lab#145](https://github.com/monero-project/research-lab/issues/145?ref=eddieoz.com) adds a sophisticated mathematical mechanism to transaction inclusion, creating different security thresholds against 51% attacks.
**Technical Mechanics:**
A transaction is considered "lucky" if it meets the mathematical condition:
```
H(checkpoint_hash || key_image) < target * amount * (checkpoint_height - input_height)
```
**How It Works:**
- **Smart Prioritization**: Transactions with older outputs or larger values have higher probability of being "lucky"
- **Zero Fee**: Lucky transactions can be included without fees
- **New Block Weight**: `block_weight = (included_lucky_diff + current_lucky_diff / M) * pow_diff`
- **Miner Incentive**: Including lucky transactions becomes economically attractive
**Scalable Security:**
The system creates different security thresholds based on the percentage of lucky transactions:
- **0% lucky transactions**: Attacker needs >80% hashrate
- **50% lucky transactions**: Attacker needs >50% hashrate
- **100% lucky transactions**: Attacker needs only >20% hashrate
**Philosophy Behind:**
The idea is that "established" transactions (with old outputs) represent legitimate long-term use, while transactions with very new outputs can be quickly created by attackers to manipulate the system.
**Privacy Trade-offs:**
- **Leaks Information**: Reveals minimum age of inputs and transaction values
- **Preserves Identity**: Maintains anonymity through ring signatures
- **Chain Analysis**: May facilitate temporal correlation of transactions
**Conceptual Problems:**
- **Complex UX**: Users need to understand complex mathematics to optimize transactions
- **Predictability**: Deterministic system can be "gamed" by sophisticated attackers
- **Entry Barrier**: New users with recent outputs are penalized
### **4. Proof of Stake: The Radical Change**
**The Proposal:**
The most radical option would be to completely abandon Proof of Work in favor of Proof of Stake.
**Why It Was Considered:**
- Would eliminate the selfish mining problem
- Would reduce energy consumption
- Would provide faster finality
**Why It Was Rejected:**
The Monero community deeply values the Proof of Work philosophy and sees PoS as fundamentally centralizing. While PoS was mentioned as one potential long-term solution, it received little serious consideration during the meeting.
## **The Meeting Dynamics: Democracy in Action**
The meeting revealed a divided community, but one committed to transparent democratic processes. Renowned developers participated, including rucknium (moderator), ArticMine, jberman, kayabanerve, sgp\_, and other experts.
### **Three Schools of Thought**
**The Pragmatists** (rucknium, ArticMine, spirobel):
- Defend DNS checkpoints as a necessary evil
- Emphasize urgency in the face of active threat
- Cite historical success against Bitmain
**The Purists** (kayabanerve, sgp\_, kill-switch):
- Reject centralizing solutions
- Prioritize the project's original philosophy
- Warn about dangerous precedents
**The Realists** (tevador, DataHoarder, ofrnxmr):
- Recognize inevitable trade-offs
- Focus on practical viability
- Seek gradual transition solutions
### **Notable Quotes**
**kayabanerve on centralization:** "At this point, I understand DNS checkpoints. I just feel we have to be unequivocally clear that even 'opt-in', it's a failure of our decentralization and needs to be a priority to remove."
**sgp\_ on the reality of checkpoints:** "I see DNS checkpoints as effectively saying 'we are becoming centralized until we come up with something better'."
**articmine on decentralization:** "The checkpoints are advisory. It is up to the miners to implement them. The latter is decentralized."
## **Deep Technical Implications**
### **For the Monero Ecosystem**
The impact of this crisis goes far beyond purely technical issues. Exchanges have already raised confirmation requirements - some demanding more than 30 confirmations instead of the traditional 6-10. The consequences include:
- **Degraded Experience**: Transactions take hours to confirm
- **Compromised Trust**: Users question the network's security
- **Economic Pressure**: Traders migrate to more agile alternatives
### **For the Privacy Movement**
Monero represents more than a cryptocurrency - it's a symbol of the fight for financial privacy. Seeing the network under attack generates consequences that extrapolate beyond technical issues:
- **Critic Validation**: Opponents of financial privacy point to the problems as evidence of unviability
- **Community Fragmentation**: Different views on solutions may divide developers
- **Precedent for Other Networks**: How other privacy-focused cryptocurrencies respond to similar threats
## **The Scalability Question**
Parallel to the attack debate, the meeting also addressed post-FCMP++ scalability:
### **Transaction Parameters**
- **Size Limit**: Proposals for 160KB per transaction
- **Fee Structure**: Rebalancing for new architecture
- **P2Pool Considerations**: Adjustments for decentralized pools
### **Future Implications**
Scalability changes may affect:
- Transaction costs for users
- Viability of different use cases
- Competitiveness vs other cryptocurrencies
## **The Emerging Consensus**
After hours of intense debate, a fragile consensus emerged:
### **Discussion Trends (Not Formal Decisions)**
1. **DNS Checkpoints Gain Reluctant Acceptance**: Despite fierce criticism, they emerge as the most viable short-term option, but only as a coordinated "opt-in" system
2. **Pool Coordination**: Focus on engaging NOSH (Nanopool, MoneroOcean, SupportXMR, Hashvault) which represent >50% of global hashrate
3. **"Failure" Recognition**: Explicit admission by the community that checkpoints represent a "failure of decentralization"
4. **Long-term Research Funding**: luigi1111 tentatively approved kayabanerve's CCS (Community Crowdfunding System) for 175 XMR (about $26,000) to research permanent "finality layer" solutions - systems that would make it impossible to reverse transactions after a certain point, definitively eliminating reorg attacks
### **Realistic Timeline**
- **Immediate**: DNS checkpoints activation in testnet
- **1-3 months**: Mainnet implementation if attacks continue
- **6-12 months**: Development of decentralized solutions
- **1-2 years**: Transition to permanent finality layer
## **Lessons for the Crypto Ecosystem**
This crisis offers valuable lessons for the entire cryptocurrency ecosystem:
### **About Security**
- **Concentration is the Real Risk**: It's not absolute hashrate, but its distribution that determines vulnerability
- **Economic Incentives are Critical**: Attackers can manipulate rewards to concentrate mining power
- **Attacks Evolve**: Theoretical strategies from 2014 finally materialized in practice
### **About Governance**
- **Transparency is Crucial**: Open discussions enable better decisions
- **Trade-offs are Inevitable**: Perfect solutions don't exist
- **Community Matters**: Technical decisions require social alignment
### **About Innovation**
- **Pressure Creates Solutions**: Crises force accelerated innovation
- **Diversity of Opinion is Valuable**: Different perspectives lead to better outcomes
- **Gradual Implementation**: Radical changes require time and testing
## **Looking to the Future**
The battle for Monero's security is far from over. The proposed solutions represent only the first round of a longer war between developers and attackers.
### **Next Developments**
- **Finality Layer Research**: Deep investigation into finality layers
- **PoW Improvements**: Possible improvements to the RandomX algorithm
- **Network Effects**: Efforts to increase legitimate hashrate
### **Open Questions**
- Will DNS checkpoints remain truly temporary?
- Will the community maintain unity during the transition?
- Will other privacy-focused projects face similar attacks?
## **Conclusion: A Community Tested by Fire**
The Monero crisis reveals technical vulnerabilities and also exposes the true character of a community committed to principles. The willingness to openly debate imperfect solutions, recognize painful trade-offs, and maintain commitment to fundamental values demonstrates a rare maturity in the crypto ecosystem.
**The Hard Reality:** As guest55 observed in the meeting: "i think we can come to a consensus that the blockchain is under attack"
**The Decisive Moment:** Monero survived Bitmain's ASICs in 2018. Now it faces a different challenge - attacks that exploit its own decentralization philosophy. The chosen response will define not only the network's technical future, but its credibility as a leader in financial privacy.
**The Final Paradox:** To defend decentralization, the community may have to temporarily accept centralized solutions. This isn't capitulation - it's strategic pragmatism from a community that understands that perfection cannot be the enemy of functional.
The war for privacy continues. And Monero, even wounded, continues resisting.
---
**About this article**: Based on the Monero developers meeting of September 17, 2025, complete transcripts and video analysis by EddieOz. To follow future developments, follow [@eddieoz](https://x.com/eddieoz?ref=eddieoz.com) and [eddieoz@sats4.life](https://nostr.com/eddieoz@sats4.life?ref=eddieoz.com).
**Disclaimer**: This article represents technical analysis and does not constitute financial advice. Monero faces real security risks that may affect its value and usability.
---
References:
- Selfish Mining: [https://www.cs.cornell.edu/\~ie53/publications/btcProcFC.pdf](https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf?ref=eddieoz.com)
- Monero Research Lab Meeting - Wed 17 September 2025: [https://github.com/monero-project/meta/issues/1268#issuecomment-3313805186](https://github.com/monero-project/meta/issues/1268?ref=eddieoz.com#issuecomment-3313805186)
- Selfish mining mitigations (Publish or Perish): [https://github.com/monero-project/research-lab/issues/144](https://github.com/monero-project/research-lab/issues/144?ref=eddieoz.com)
- Lucky Transactions: [https://github.com/monero-project/research-lab/issues/145](https://github.com/monero-project/research-lab/issues/145?ref=eddieoz.com)
- DNS Checkpoints: [https://github.com/monero-project/monero/issues/10064](https://github.com/monero-project/monero/issues/10064?ref=eddieoz.com)
