This post originally appeared on my website.

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.

We will say that a transaction is "valid" if it has been included in a block on the main blockchain or it is eligible to be mined into a new block on the blockchain. A transaction is "invalid" if it cannot be mined into a new block.

We will compare the validity rules for bitcoin transactions and Monero transactions. Monero transactions need to obey the same basic rules as bitcoin transactions, but with some twists that make Monero special.

How bitcoin does it

A fundamental concept of many cryptocurrencies, including bitcoin and Monero, are transaction outputs. An output is a quantity of the currency inside of a transaction that is spendable. To provide a refresher on the concept of a bitcoin transaction output, I will quote my earlier article analyzing the Bitcoin Cash hard fork:

An output is a concept closely related to – but distinct from – address. An output is identified by its transaction ID plus its position in the transaction outputs, i.e. first position, second position, third position, etc. Once an output is spent by another transaction, it is spent permanently and cannot be reused. However, an address can be re-used repeatedly.

Transactions usually have more than one output because even a payment to a single recipient usually does not use up all of the output being spent. The remaining value, "change" like metal coins returned to a customer in a brick-and-motor store, is sent back to the sender's address in a second output in the same transaction.

A new bitcoin transaction that is eligible for inclusion in a new block will contain the transaction ID and the output position (first, second, third, or...) of the output being spent. The output position is the local output index. The index only refers to the position inside of its own transaction. This will be different from how Monero does it.

In bitcoin and Monero, a single blockchain is a consistent version of history. Transactions must appear on the blockchain in the correct order or else users could spend the same coins multiple times or create coins out of thin air.

In a single bitcoin blockchain (i.e. single version of history) a valid transaction must obey these rules that are relevant to our analysis:

1. An output that has already been spent cannot be spent again.
2. A transaction can only spend an output that has already been included in a prior block or in the same block as the transaction. Spending outputs from thin air is not allowed.
3. The spender must prove that they are authorized to spend the output by producing a cryptographic signature with their private key that matches the public key associated with the output.

The only exception to rule #2 is when miners are paid in completely new coins as payment for their service of mining new blocks.

A cryptographic signature is the result of a specific mathematical operation that combines the user's private key (which is never shared publicly) and the message that authorizes spending.

How Monero does it

Monero has many privacy features. One of them is "ring signatures". In bitcoin, every signature spends a single output. There is a one-to-one relationship between the output being spent and the transaction that spends it. There is no ambiguity about which output is spent, so the flow of funds is easily traced.

In Monero, a ring signature declares that any one of several outputs are being spent in a given transaction. An external observer cannot know which of the outputs in the ring is actually being spent. Monero's current ring size is 16, which means that there is one "real spend" hidden in the ring with 15 "decoy" outputs.

How does Monero fulfill the conditions that bitcoin requires of its transactions?

Bitcoin's rule #1 was "An output that has already been spent cannot be spent again." Monero makes sure that an output is only spent once by requiring that transactions include the key image of the output that is being spent. Each output has a unique key image that cannot be faked, yet in normal circumstances an observer cannot know which specific output is spent in a ring signature. Once a key image inside a transaction is included in a block, no other transactions with that key image are allowed inside the blockchain.

Bitcoin's rule #2 was "A transaction can only spend an output that has already been included in a prior block or in the same block as the transaction." Monero's rule is similar, with an important difference: Monero transactions can only spend an output that has already been included in a block at least 10 blocks ago. This rule is known as the "10 block lock". Since decoys and real spends are treated the same in the transaction validation process, all 15 of the decoy ring members must also follow this rule.

Bitcoin's rule #3 was "The spender must prove that they are authorized to spend the output by producing a cryptographic signature with their private key that matches the public key associated with the output." In bitcoin, there is a single public key. In Monero at current ring size, there are 16 public keys for every output that is to be spent. For a specified set of 16 public keys, the ring's cryptographic signature must match the whole set and only that set. You cannot split the signature and somehow replace one or more ring members. If you want to change any of the ring members, you must create a whole new signature, which requires creating a new version of the transaction.

A shortcut

Bitcoin transactions refer to outputs that they spend by their transaction ID and the output index inside that transaction. Monero transactions use a global output index to spend outputs. The global index is a count of every single output that has ever been included in Monero blocks. There are about 140 million outputs on the Monero blockchain already, with more added about every two minutes, on average.

The global output index is a useful shortcut. Ring signatures must refer to many outputs at once. If outputs in rings were referenced explicitly by transaction ID, each Monero transaction would be take up much more space to store. A transaction ID requires 32 bytes to store. Integer index numbers take up much less space: 4 bytes or less.

Monero transactions are already much larger than bitcoin transactions. A 2-input/2-output bitcoin transaction is about 0.4 kilobytes. A 2-input/2-output Monero transaction is about 2.2 kilobytes. An unpruned Monero node already takes up about 240 gigabytes of storage for the whole blockchain. Including every single transaction ID explicitly in each ring would increase the size of a 2-in/2-out Monero transaction by about 50 percent. Instead, rings refer to outputs implicitly by their global index number.

Since bitcoin transactions refer to their parent transactions explicitly by their transaction ID, the transactions' validity is basically independent of the exact position of the parent transactions in the blockchain. The parent transaction could be included in the previous block, a block from a week ago, or even the same block that the child transaction is included in. The situation is different with Monero transactions. Since the index of outputs depends on its exact position on the blockchain, the child transaction will not be valid if the index ordering is different from what the child transaction expected.

How can the output index ordering be different from what a Monero transaction was "expecting"?

The 10 block lock establishes the expectation. The global output index in blocks produced 10 or more blocks in the past is not supposed to change. The output index in blocks shallower than 10 blocks can change without major problems.

Such events occur occasionally just as a result of the random mining process. There is no coordination between miners where they "take turns" mining blocks. Each block production is a random event and sometimes random events can occur nearly simultaneously, in different parts of the network. It takes time for new blocks to spread throughout the network. Therefore, short alternative chains can develop occasionally until the whole network agrees on the one longest chain. The short chains that lose the race are eventually ignored by nodes in a process called orphaning. In normal circumstances, honest miners do not try to produce these alternative chains, yet unintentionally a few alternative chains of 1, 2, and very rarely 3 blocks long are produced. The output indices in these alternative chains can differ from each other. However, the short chains do not violate the expectations of new transactions because they are shorter than 10 blocks.

A simplified example

When orphaned chains are 10 blocks or longer, the expectations of new transactions are violated. Therefore, the transactions can be invalidated. Let's visually walk through an example.

To allow a compact diagram, in this example we will set the ring size to 3 and the block lock to 3. Each transaction will have a single transaction output and each block will have exactly 2 transactions. Coinbase transactions, which are reward payments to miners, are ignored.

The diagram shows the abbreviated transaction output public keys of each transaction. The output index is shown to the right of each public key.

Our transaction is labeled 4b20 and colored purple. Simplifying more, we will treat this 4b20 identifier as if it refers to the ring, output, and transaction itself in one concise label. Our transaction only selects ring members outside of the 3-block lock. When there is a 3-block lock, that means that rings cannot contain outputs from the most recent 2 blocks previous to one that included the transaction. The lock is represented by the red-orange coloring of blocks preceding the block where our transaction was originally confirmed.

The wallet software has created the ring and generated a valid signature for the public keys associated with the outputs in the ring. The ring members have indices 54, 49, and 48. The real spend is output public key f382, with index 49. At this point, no external observer knows that the real spend is f382. The other two outputs in the ring were selected randomly by the wallet software when the transaction was created.

This is the normal functioning of the example chain. New transactions are created. Their rings include outputs from blocks prior to the locked blocks. The transactions, with valid ring signatures, are included in new blocks and all is well.

However, it is possible for a powerful malicious miner to upset the orderly functioning of the blockchain. Even with a minority of total network hashpower, the malicious miner can occasionally get lucky and produce long alternative chains, in secret, faster than the honest miners can produce them. When the malicious miner successfully mines an alternative chain longer than the honest chain, it reveals the chain to the network. Suddenly, nodes in the Monero network realize that the longest chain is the new malicious one and they orphan the honest chain. This event is depicted in the diagram below.

The transactions of the orphaned honest chain are expelled from the orphaned blocks. They are seeking to be included in the new chain, if they have not already been included. Notice that the index numbers on the attacking chain refer to different output public keys than the original honest chain because some outputs are different and the outputs that are the same are in a different order.

Output c63c was originally in the ring created by our transaction. The ring referred to it by index 54. Output c63c is still valid on the attacking chain and actually was included in a later block on the attacking chain. The figure below shows where it went on the attacking chain. It now has index 57 on the attacking chain.

The new output index being out of order is a big problem for our transaction. In the new version of the chain created by the malicious miner, index 54 points to output public key 14bd instead of c63c.

The transaction's signature for the ring is no longer valid in the new chain history because the whole set of public keys do not match the signature, even though c63c is in the new chain. For our transaction to be valid, the attacking chain must have the exact same transactions in the exact same order as the honest chain, which did not happen here. Our transaction cannot be included in a new block because it is invalid.

Privacy impact

The transaction we created is invalid, but we can create another one that spends the same amount of coins to the same recipient. We change the ring and produce a new signature for that ring. We must include the same real spend, and here is where the ring privacy protections go wrong in this situation. The decoys, randomly selected, are different, but the real spend is the same. The figure below shows the old invalid ring on the left and the new valid ring on the right. The two rings only overlap on one output: f382 at index 49.

Any external observer of the blockchain can see this overlap of the two rings and deduce that the real spend was f382, defeating the privacy protections that ring signatures are supposed to provide. The observer knows that the two rings were trying to spend the same output because the ring has the same key image, as was mentioned before. The figure below summarizes the privacy impact. f382, in yellow, appears in both rings.

18-block reorg

On September 14, 2025, the Monero blockchain experienced an 18-block reorg. The deep reorg violated the assumption that reorg depths would not exceed 9 blocks. The incident invalidated 115 transactions that expected the 10 block lock rule to not be broken.

The 18-block reorg was achieved by Qubic, another cryptocurrency project. For months, Qubic has held a large, yet minority, share of Monero hashpower and has executed short blockchain reorgs to unfairly raise its share of mining revenue through a selfish mining strategy. A clickable visualization of the 18-block reorg event is viewable here.

Does the 18-block reorg mean that Qubic held a majority of hashpower? Not necessarily. Mining is a random process subject to luck. Qubic has had many chances to get lucky. According to block timestamps, Qubic mined a total of 20 blocks in 66 minutes. Assume that network mining difficulty was equal to network hashpower. If Qubic had 40 percent of network hashpower, it would have a 5 percent chance of creating 20 blocks in 66 minutes or less. This result is based on using an Erlang distribution where the shape parameter is 20 and the rate parameter is 0.4 * 1/2, i.e. 40% of the hashpower necessary to produce the usual one block per 2 minutes. Given that Qubic could try again and again, a 5 percent chance per attempt can turn into a very high chance with repeated attempts.

What happened to transactions in the orphaned chain? Most of the transactions (456) were expelled from the orphaned chain and included later in the attacking chain. 115 of the transactions were invalidated because they referenced outputs on the orphaned chain. Below is a table counting the number of transactions invalidated on each block of the orphaned chain. Notice that the first orphaned block at height 3,499,659 contained zero transactions, so no subsequent transactions would have included any outputs from that block inside their rings.

Even in the final block of the orphaned chain at height 3,499,676, only half of transactions were invalidated because, by chance, about half of transactions contained no rings that referenced an output in the orphaned chain. Their ring members were all on the chain prior to the first orphaned block at height 3,499,659.

Case study of one transaction

We will follow the journey of one transaction that became invalidated: tx id d3e574c05b01f5d74815e3894f55e1645f402cdbf0415877f49e752a71b0d376.

This transaction was originally included in the orphaned chain at block height 3,499,672. Its ring specified global output index 139,283,631, plus 15 other indices from earlier in the chain. Within the orphaned chain, index 139,283,631 pointed to the output with public key b2de1e442b60b70ac681e9044581bb2dcbf66c97865b340d9a8ae4e3bb8e3d61 at block height 3,499,660. Note that some Monero block explorers label the output public key as a "stealth address".

However, when the 18-block reorg occurred, the transaction was expelled from the orphaned chain and started to wait to be included in a later block. In the new chain, index 139,283,631 pointed to the output with public key 61b08cd8a250fd2558cdd1a63ebfa38aeea0c9d4395c9223d315439fbc2e0e68 at block height 3,499,665. Since this was a different public key than the original signature was valid for, the transaction cannot be included in a block in the new chain because the old signature is invalid.

About 36 hours later, a new transaction appeared, 2b02f010b63b7a931eaafc681a1c2d2344ef44bdd0998c4b730663b041b4099c. We know that this transaction is related to the original one because its ring has the same key image: 1792997a43d27bb473605424ff3f1f1e1e69b44fec1ebc59dadba713a22eafa8.

The ring members of this transaction are all different except for one, at index 139,282,277. Both the old and new transactions contained this index. This index points to output public key 75254fa644c59a40eed60ad9bc6d9727a152323ac04069de764b72f9fcf3bd6b in transaction eb4f9e77a031c24fad0bb2abab76302e34e200bd3dff52a9f203fc187e2a4ff8 inside block at height 3,499,628, just a few hours before the 18-block reorg occurred. By process of elimination, this output must be the real spend. The ring signature's privacy protection was defeated.

Double spends and respends

Arguably the greatest negative impact of a deep blockchain reorg is the potential for a "double-spend" attack. In a double-spend attack, a malicious miner uses its hashpower to create an alternative history of the blockchain, then substitutes its history for the honest history. The miner spends the coins to a victim in the honest history, then spends the coins to itself in the attacking chain. Satoshi Nakomoto, creator of bitcoin, described the attack in his 2008 white paper that described the bitcoin protocol:

We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent.

To execute the double-spend attack, a miner would have to send Monero coins to a victim, such as a merchant or centralized exchange. The victim would wait a certain number of block confirmations, depending on the victim's preference, and then send an irretrievable item to the miner, such as a physical good shipped in the mail or coins of another type of cryptocurrency.

Meanwhile, the miner would be mining an alternative chain in secret that contains a transaction that contradicts the "payment" to the victim. Once the malicious miner's chain was long enough and enough blocks on the honest public chain are confirmed, the miner would broadcast the secret chain, which causes a reorg and reverses the payment to the victim.

A successful double-spend requires the intended victim to take some action, such as sending the perpetrator some item of value. Without the intended victim taking action, the attack has no effect.

In the intentional double-spend attack on the bitcoin blockchain, the perpetrator invalidates the first transaction on the honest chain by mining a contradictory transaction on its secret chain. Bitcoin rule #1, "An output that has already been spent cannot be spent again," is the violation that invalidates the transaction. In bitcoin, only the original sender of the transaction can invalidate the transaction because only the original sender can sign a transaction that contradicts the first transaction.

As explained previously, a Monero transaction can become invalidated by a deep reorg even if the original sender did not deliberately attempt a double-spend by producing a contradictory transaction. Qubic invalidated the 115 transaction as a sort of collateral damage of its behavior.

Another difference in Monero, compared to bitcoin, is that it is easy to see if two bitcoin transactions sent the same exact amount of coins to the same address, because of its lack of privacy features. In Monero, addresses are hidden on the blockchain through its stealth address feature and amounts are also hidden with confidential transactions technology. Therefore, it is unknown if the later valid transactions just sent the same coins to the same recipient as the invalidated transactions were trying to send in the first place.

As of release of this post (September 26, 2025), about 74 percent of the 115 invalidated transactions had at least one of its ring's key image confirmed in another transaction after the original transaction had been invalidated. It is maybe better to call these transactions "respends" instead of double-spends because they could have been spent to the original intended recipient. Note that invalidated transactions could have been users sending funds to themselves or users could have completed the original payment to another recipient using a different set of coins or a different wallet. No merchant has yet claimed publicly to be an accidental or deliberate victim of a double-spend as a result of the 18-block reorg.

FCMP transaction invalidation

Full-Chain Membership Proofs (FCMP) is an upcoming upgrade to Monero's privacy features. Instead of having a small "ring size" of 16, FCMP will, in effect, produce a ring that includes all of the hundreds of millions of outputs ever produced on the Monero blockchain. It is a huge improvement in privacy. How would FCMP transactions handle a deep blockchain reorg?

In one way FCMP performs better than ring signatures, but in another way it performs worse. The privacy impact would be eliminated. Since FCMP transactions would include the whole set of previous outputs in their "rings", an observer could not perform the process-of-elimination analysis that defeated the privacy of small rings when transactions are invalidated and need to be reconstructed.

However, since current-version Monero rings only select a limited number of outputs from the reorg zone, there is only a chance, not a guarantee, that the transactions outside of the 10 block lock are invalidated. In the actual 18-block reorg, only about half of transactions that could have been invalidated actually were, because of luck of the ring signature draw. If they were FCMP transactions, all transactions above the 10 block lock would have been invalidated because all of them would reference all transactions from 10 blocks and earlier.

anhdres created all diagrams in this post.

Special thanks to DataHoarder for extracting and hosting extended data about the reorg incident here and here.

jeffro256 and DataHoarder reviewed an earlier version of this post and provided feedback.

Open source code used to produce of the empirical analysis in this post is here.

If you enjoyed this article, consider supporting my work with a donation of XMR, BCH, BTC, or WOW.

More community input is needed on possible deployment of temporary rolling DNS checkpoints to defend against Qubic attacks: https://github.com/monero-project/monero/issues/10064

Please comment on the GitHub issue and/or click thumbs-up/down emoji reaction.

TL;DR: A malicious mining pool is disrupting the network and could cause deep blockchain re-organizations. DNS checkpoints, which have existed for emergency use in the code since 2014, could prevent deep blockchain re-organizations, but Monero's blockchain consensus protocol would temporarily be less decentralized.

Advantages

Practical advantages

• The code for this countermeasure has been in the Monero codebase for over ten years. The countermeasure is ready to deploy now, once final testing, "procedure smoothing" (see below) and successful outreach to honest mining pools is completed.

• Humans (i.e. the Monero Core Team) could intervene by ceasing or modifying the checkpointing procedure if the checkpointing produces undesirable results.

Principled advantages

• Rolling DNS checkpoints could keep the Monero network working, with minimum disruption, for the thousands of users who depend on it every day for private peer-to-peer electronic cash.

Disadvantages

Practical disadvantages

• Rolling DNS checkpointing has never been deployed on Monero's mainnet before. Something unforeseen could go wrong.

• Successful checkpointing requires most of the major honest Monero mining pools to voluntarily enable DNS checkpointing enforcement. If the mining pools choose not to, rolling DNS checkpoints will likely be unsuccessful.

• Maintaining control of the DNS records would require strict security procedures. Two previous security incidents in 2019 and 2023 involving malicious software hosted on getmonero.org servers and theft of community donated funds should be kept in mind.

Principled disadvantages

• Without a doubt, Monero's consensus mechanism would be less decentralized if rolling DNS checkpoints were enabled.

• Monero nodes would temporarily no longer follow the chain with the most proof of work.

• Mining pools following the DNS checkpoints would be similar to a situation of the majority of mining hashpower coordinating and colluding against a minority hashpower miner. "Majority hashpower cannot collude" may be considered a security assumption of proof-of-work consensus.

(Thanks to spackle for this writeup!)

The first week has been a wild ride, and there is a lot to share. Presented roughly by order of importance:

PR Improving Node Startup

Restarting a node while there is a large mempool can take over an hour in extreme conditions, since the node must process all the mempool transactions before resuming regular operation. 0xFFFC has addressed this with a massive speed up in PR 9376. These changes are now in use on the stressnet, to great effect.

Block Sync Size

Block propagation and network synchronization suffer at larger block sizes, which encourages the creation of alternative chains. Setting '--block-sync-size 1' allows nodes to handle larger blocks more easily, and this is now standard practice on the stressnet. Further updates are expected on this soon.

Ongoing Investigations

• Block sync size
• Wallet-to-daemon connectivity and performance enhancements
• Tx pool management (including flush_txpool processing time)

General Announcements

• Go to monitor.stressnet.net to see network stats
• explorer.stressnet.net is offline for now
• Node operators should upgrade to latest release for a smooth(er) stressnet experience. Older releases struggle with larger blocks, and ban too many nodes.
• Congratulations to strawberry, winner of the wallet draining competition
• Ongoing discussion is being held on Matrix at #monero-stressnet:monero.social and Libera Chat IRC on ##monero-stressnet.

Stressnet Stats

• This plot shows the block sizes on stressnet over the past week
• Largest Block: 2.49 MB at height 2521514
• Most transactions processed in an hour: 33074 (equivalent of 794000 tx per day)

Monero has a problem. The suspected spam transactions from earlier this year showed that Monero nodes do not cope with high transaction volume as well as expected. Monero protocol developers have been trying to get to the root of the issue, but the problem only appears when nodes are handling high transaction volumes.

Since the spam is over (for now), the only way to help developers find and fix the bottlenecks is to run a separate test network that will be spammed with transactions. We call it "stressnet". The performance bottlenecks are potential blockers for privacy improvements like larger rings sizes and/or Full Chain Membership Proofs (FCMPs). To quote developer selsta: "a large increase to the ring size is going to risk the stability of the network if we don't fix the known daemon [node] inefficiency bugs first."

A testnet fork (the stressnet) has been created to stress test the node and diagnose performance bottlenecks. To participate, you can simply run a node using this slightly modified open source release of monerod (launch monerod with --testnet): https://github.com/spackle-xmr/monero/releases/latest

Testing begins on June 19th at 15:00 UTC. Current bugs require a significant number of connections to observe, so we need as many nodes on the stressnet as possible.

Ongoing discussion is being held on Matrix at #monero-stressnet:monero.social and Libera Chat IRC on ##monero-stressnet.

FAQs

• What are the risks to running a stressnet node?

The anonymity set of running a node on the mainnet Monero network is in the thousands. The anonymity set of running a node on this stressnet will be in the dozens at best. If you run a stressnet node on your machine, the IP address of your machine (or the proxy's IP address if your machine uses a proxy) will be visible to other nodes on the network. If you have an extreme threat model, this may be an unacceptable risk for you.

The Monero node process may consume a lot of your computer's resources like CPU and especially RAM. You can set the priority of the node lower using nice or just quit the process if it is taking up too much of your resources.

• How can I see what's happening on the stressnet?

We have set up a stressnet blockchain explorer at https://explorer.stressnet.net/ . We are working on more ways to visualize the stressnet activity.

• When should I sync up my node?

As soon as possible. The initial sync may take over 24 hours to complete. Once spamming starts on June 19th, it may be difficult to sync from scratch.

• How much storage space do I need?

The stressnet blockchain is about 10GB now. The stressnet could use up to 50GB of storage by the time testing completes. Pruning your node is fine.

• How long will the stressnet run?

We hope that it will run for two months. If it takes more time than expected to track down the bottlenecks and test patches, the stressnet could go on for longer.

• Would it be possible/advisable to run it alongside a mainnet node?

Yes, this is fine. If you also run a testnet node (this would be rare), then you have to change the stressnet node's default ports and the blockchain storage location. Instructions are in the README of spackle-xmr's monero GitHub repo.

Context in the MRL logs: https://libera.monerologs.net/monero-research-lab/20240401

I have some preliminary research for you:

https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf

March 2024 Suspected Black Marble Flooding Against Monero: Privacy, User Experience, and Countermeasures

On March 4, 2024, aggregate Monero transaction volume suddenly almost tripled. This note analyzes the effect of the large number of transactions, assuming that the transaction volume is an attempted black marble flooding attack by an adversary. According to my estimates, mean effective ring size has decreased from 16 to 5.5 if the black marble flooding hypothesis is correct. At current transaction volumes, the suspected spam transactions probably cannot be used for large-scale “chain reaction” analysis to eliminate all ring members except for the real spend. Effects of increasing Monero's ring size above 16 are analyzed.

Thank you to all donors!

The MAGIC Monero Fund's campaign to raise 226 XMR (28,800 USD) for three months of vtnerd (Lee Clagett) development work has succeeded.

vtnerd will work on Monero and Monero Light Wallet Server (LWS). The LWS increases Monero's capacity for more users and transactions. LWS will be even more important when Seraphis (next generation Monero transactions) is implemented because Seraphis will improve the user privacy and speed of light wallet servers.

Here are the full details of vtnerd's proposed work:

vtnerd is the author of Monero-LWS, and has been a contributor to the Monero codebase since 2016. He is a veteran of four CCS proposals; [1], [2], [3], [4]

This proposal funds 480 hours of work, ~3 months. The milestones will be hour based; 160 (1 month), 320 (2 months), 480 (3 months). At the completion of hours, he will provide the Monero Fund committee references to the work that was completed during that timeframe.

Some features that are being targeted in monero-project/monero :

• Get new serialization routine merged (work on piecemeal PRs for reviewers sake) (already in-progress)
• Complete work necessary to merge DANE/TLSA in wallet2/epee.
• Adding trust-on-first-use support to wallet2

Work targeted towards vtnerd/monero-lws :

• Optional full chain verification for malicious daemon attack (already-in progress)
• Webhooks/ZMQ-PUB support for tx sending (watch for unexpected sends)
• ZMQ-pub support for incoming transactions and blocks (notifies of any new transaction or block)
• Implement "horizontal" scaling of account scanning (transfer account info via zmq to another process for scanning)
• Make account creation more "enterprise grade" (currently scanning engine re-starts on every new account creation, and uses non-cacheable memory) * Unit tests for REST-API
• Create frontend LWS C/C++ library
• Provide official LWS docker-image
• Provide official snap/flatpak/appimge (tbd one or all of those)
• Provide pre-built binaries
• (Unlikely) - reproducible builds so community members can verify+sign the binary hashes
• It is unlikely that all features will be implemented, at which point the unfinished features will roll into the next quarter.

Last week rbrunner7 argued that future Monero transactions should not be able to set custom timelocks. This proposal was discussed in this week's Monero Research Lab meeting.

Monero's timelocks have been a "solution in search of a problem" for a long time. However, Alex from Local Monero said he had a special use for them:

Sometimes, we ban a certain user permanently from our platform. Sometimes, that user tries to return to the platform. We catch them and warn them not to return again or there will be consequences. They ignore us and return to our platform. In these cases, we take the XMR that they placed in the arbitration bond and send it to them in a timelocked transaction to disincentivize them from trying to return again.

The rough result of the meeting was to evaluate time lock puzzles as an off-chain replacement for custom unlock times. xFFFC0000, a new Monero dev, said that he would investigate time lock puzzles soon.

Supporting Monero since 2021, the MAGIC Monero Fund (MMF) continues to accept applications for research and development grants focused on improving the Monero protocol and ecosystem.

The fund can issue grants and host fundraisers for Monero research, development, security audits, and more. This allows for the Monero community to build a sustainable, alternative pool of funds to provide for significantly more consistent and less stressful research and development.

The application process is described here: https://monerofund.org/apply. Applications are accepted on a rolling basis. Contractors or recipients of MMF funding are required to undergo a basic KYC process that is similar to an employment on-boarding.

The fund has an advisory committee entirely elected by the Monero community and this committee selects which grants to fund. The current Magic Monero Fund Committee Members are kayabaNerve (Luke Parker), Rucknium (me), monerobull, kowalabearhugs, and artlimber. You can view current voters on the MAGIC website.

The MAGIC Monero Fund supplements but does not replace the Monero Community Crowdfunding System (CCS). By working in complement with other funding structures the fund aims to recruit and retain talent within the Monero ecosystem. You can view a list of previously funded proposals on the MoneroFund.org website.

MAGIC Grants’ Advantages

The 501( c )(3) public foundation status ensures donations to support our funding are fully tax deductible as allowable by US law, regardless of asset (eg: USD, BTC, XMR, NFTs, stock). An established non-profit since 2018, MAGIC utilizes US bank and exchange relationships while also maintaining the ability to work internationally.

While the Monero community appreciates XMR, as do we, it remains a volatile asset. This can be a barrier for people who want to contribute, one which has caused multiple proposals funded through the CCS to unfortunately fall through. The fund has the ability to convert donations to a less-volatile asset, such as fiat currency, for making payments in whichever means is preferred by the contractor. By handling all the boring legal stuff and tax documents, we can allow the community to focus on growing Monero.

If you are interested in helping support our cause, please review our active fundraisers as they appear, or consider donating to our general fund at https://monerofund.org/. Donors to the fund have the option of contributing anonymously.

Timeline of events

In the last Monero General Fund transparency report in March 2023, the General Fund held 8452 XMR. As far as we know, this separate wallet is safe and unaffected. It would be possible to pay people with active CCS proposal from the General Fund, but nothing has been decided.

Last week Exodus released a fix for their Desktop wallet creating Monero transactions with nonstandard fees, based on my discovery of the issue. Original announcement. Many users must have already updated their software because the number of these identifiable transactions on the blockchain have decreased from about 600 per day to 300 per day.

Yes, Exodus is a closed source wallet. I would not recommend people to use a closed source wallet. If people do choose to use Exodus despite it being closed source, then they should update to the latest version for better privacy. Monero users should have excellent privacy by default regardless of which wallet implementation they are using.