(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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[Privacy Advisory]
Exodus Desktop Monero users, update to latest version for privacy fix

Prior to version 23.10.10, which was released on October 10, 2023,
Exodus Desktop wallets produced unusual fees when creating Monero
transactions. I suggest all Exodus Desktop users to update their
software to version 23.10.10 or later before making their next
Monero transaction to avoid the privacy impact of these unusual
fees. The Exodus _Mobile_ wallet also produces unusual fees, but
a fix has _not_ yet been developed and deployed to a new release
version of Exodus Mobile. The fee of all Monero transactions can
be viewed in plaintext by any observer of the blockchain, including
privacy adversaries. Transactions that use unusual fees distinguish
themselves from the rest of transactions on the blockchain.

Two transactions that have the same unusual fee are statistically
more likely to be made by the same user. Unusual fees can increase
the probability of correctly guessing that two transactions are
actually linked to a probability far above random guessing, which
is one divided by Monero's ring size (1/16 = 6.25% correct guessing
when guessing completely randomly). According to my new theoretical
and empirical research that has not been peer reviewed, a privacy
adversary can use a simple statistical classification rule to achieve
a 37% probability of correctly guessing the "real spend" in a ring
signature of a transaction created with pre-23.10.10 versions of the
Exodus Desktop wallet.[1,2]

Unusual fees affect the privacy provided by Monero's ring signature
feature, which obscures the senders of transactions. It does not
affect stealth addresses, which provide privacy for the transaction
recipients, nor does it affect confidential transactions, which hide
the amount of XMR that is being sent.

[1] Rucknium (2023) "Discussion Note: Formula for Accuracy of Guessing
    Monero Real Spends Using Fungibility Defects."
    https://github.com/Rucknium/misc-research/tree/main/Monero-Fungibility-Defect-Classifier/pdf

[2] Rucknium (2023) "Monero Nonstandard Fees."
    https://github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees
-----BEGIN PGP SIGNATURE-----

iQJMBAEBCgA2FiEEXV4Iojid8iWr0HgbKR4MIp1jFpcFAmUn38AYHHJ1Y2tuaXVt
QHByb3Rvbm1haWwuY29tAAoJECkeDCKdYxaXSaYP/0AKcROZbWqvPCFro3Z2CZTp
0IwmadtgY3OcLhlC8Bno05Rz9P8t6msF0rG51SapK2xtDq+uyM6PFJTqyly9IAVy
TncM79OlbBGFrC8U7HRGfElQbIxzE42ejrRbyTDxwh//dqUfX/3M56O1YOuto+HZ
eLwj3MfQO1sgsIMG5g3/vzp73Vet9+LXf1U3AJVIWlY1Vb7W6r8qvW/LGojT4CCw
/X1f3mkfnlr6CerT8evVlr9A2NYkDnl11pU2JJI2e3ZOgqPhvdJg6/7vFAhxp03d
XvItDpHTssKNagfFc3TScJAYj8S7kkaJsqcQ1Y7vlbGjyqIcg7HuArHMLmDuD84j
egtdFW3I+TD0ZPOeFFbo/mJEgogD+tZoe8ICGZzSLAAj5w8d9XlIfoDEionRas6j
MuGPizBhmwRLBNYvhciqjs1zQSAhQyj+wcx7hOLHpXX6JP5fFT1AH8InRJP9IKiT
UTC4KfofMTSCBZWgFdFTemo5soL+4O6kh2nY8v1QMbXWYXJPqs4WES4yuG+2P5io
xFLExzCZbRq6TeoQGw+iC+GTq2y0yDaLQzp34dIdL/YdIoRRLOBe7m1rLalm+wrL
Ys9ztAOKNFtg8vIY9Qe5VIwniW7WM2aQ0HXM/OyYg6/7EJ2MqvJt+edkDrQMAd9o
bf+PgNKASOmjuFkbMAPm
=cFy3
-----END PGP SIGNATURE-----

Q&A

Q: Does the unusual fee issue affect the Exodus Mobile wallet?

A: Yes. The Exodus Mobile wallet currently uses nonstandard Monero fees that are actually different from the fees used by old versions of the Exodus Desktop wallet. The latest version of the Exodus Mobile wallet does not have a fix for its unusual fees. Users of the Exodus Mobile wallet should be aware that their Monero transactions have lower privacy.

Q: I have sent Monero transactions with the Exodus Desktop wallet prior to the fix. Can those past transactions affect my privacy now?

A: Potentially yes. The fee data is part of every transaction permanently included in the Monero blockchain and cannot be removed. The unusual fee data can be accessed by anyone running a Monero node. If you used Exodus Desktop wallet to send Monero transactions in the past, you may consider if a higher average probability (37%) of your potential adversaries guessing the real spend in your transactions is a problem in your threat model.

Q: What makes the fees unusual?

A: Except when Monero's dynamic block/fee algorithm is raising block size and fees, a Monero node will suggest these four values for fees in units of nanoneros per byte: 20, 80, 320, 4000. A nanonero is 0.000000001 XMR. These four fee levels are "standard" fees. The Exodus Desktop wallet created Monero transactions with 240600, 342450, and 444300 nanoneros fee total (about 160 nanoneros per byte for transactions with 1, 2, and 3 inputs). The new 23.10.10 version of the Exodus Desktop wallet creates transactions with 20 nanonero per byte fees.

Q: How many Monero transactions were sent by an Exodus Desktop wallet?

A: I estimate about 3% of recent transactions had the Exodus Desktop nonstandard fees. That's about 4,000 Monero transactions per week. https://github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees

Q: Does the Exodus Desktop wallet fix have anything to do with the version 0.18.3.1 of the Monero GUI/CLI wallet that was just released?

A: No. The timing was a coincidence.

Q: How was the issue discovered and patched?

A: I discovered the issue when I analyzed the fee data on Monero's blockchain. A set of nonstandard fees of 160 nanoneros per byte started to appear on the blockchain over a year ago on August 25, 2022, the same date that Exodus released a new version that restored the ability to send Monero transactions. With that clue, I used the Exodus Desktop wallet to create Monero transactions and concluded that it was responsible. I reported the issue to Exodus on September 4, 2023 through HackerOne. Exodus developers wrote a patch that was included in the periodic new version release on October 10, 2023.

Q: Is there any way to reduce the nonstandard fee issue in the Monero protocol instead of hoping that individual wallet developers do not use nonstandard fees?

A: Maybe. The next proposed major upgrade to the Monero protocol, Seraphis, requires that transactions choose from a limited set of possible fees. This is called "fee discretization". https://gist.github.com/UkoeHB/f508a6ad973fbf85195403057e87449e#transaction-uniformity

Q: If I am a Monero user, but I never used the Exodus Desktop wallet, does the issue affect me?

A: The old version of the Exodus Desktop wallet may have created "black marble" effects for other users, but the impact would be very minor because only about 3 percent of all Monero transactions were created by the Exodus Desktop wallet. I have not tried to calculate what the exact effect could be. More info on "black marble" effects: https://reddit.com/r/Monero/comments/12kv5m0/empirical_privacy_impact_of_mordinals_monero_nfts/ . Wallet implementations that use the "wallet2" code to create Monero transactions will use standard fees. As far as I know, some of the wallets that use wallet2 are the GUI, CLI, Feather, Cake, Monerujo, and Stack wallets.

Q: Are there other wallet implementations that produce nonstandard fees?

A: According to the data on the Monero blockchain, yes. There are at least 4 other clusters of nonstandard fees that make up about 7 percent of recent transactions. Figuring out which wallets are creating the transactions requires testing wallets and services like centralized exchanges. You can help! Test wallets and services you use to see if they are producing nonstandard fees: https://github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees

A research note I wrote recently. For years there has been a worry about how much transaction fungibility defects are affecting user privacy. Now we can put specific numbers on it. If there is some tradeoff between requiring more transaction format strictness and some other goal, we can weigh the options with the estimated privacy benefits.

If your wallet uses the "standard" wallet2 method to create Monero transactions, this issue mostly doesn't affect you. As far as I know, some of the wallets that use wallet2 are the GUI, CLI, Feather, Cake, Monerujo, and Stack Wallet.

Direct link to the PDF: https://github.com/Rucknium/misc-research/blob/main/Monero-Fungibility-Defect-Classifier/pdf/classify-real-spend-with-fungibility-defects.pdf

Abstract

Many parts of Monero's transaction format such as tx_extra contents, the fee paid to miners, and the decoy selection algorithm are not standardized by rules set by nodes nor blockchain consensus. Instead, alternative Monero wallet implementations are free to set these transaction characteristics in ways that are unique to the wallet implementation. Therefore, observers of the blockchain data can determine that a transaction was likely created by a nonstandard implementation. The distinguishing characteristics of transactions create many “anonymity puddles” instead of one “anonymity pool”. An adversary that aims to guess the real spend of a ring signature can exploit the information contained in these characteristics, referred to as “fungibility defects”.

This note defines a simple classification rule that leverages information about the fungibility defects of each ring signature's 16 members. The classification rule is applied to the rings in all transactions that have the defect. A ring member having the defect increases the probability that it is the real spend because a user will often spend “change” outputs from transactions that were created by their own nonstandard wallet. Using basic probability concepts I develop a closed-form expression for the probability that the classifier correctly classifies a ring member as the real spend. This probability, the Positive Predictive Value (PPV) is a function of ring size, the probability that a user spends change in a ring, and the proportion of transaction outputs on the blockchain that have the defect. These three values are either defined by Monero's protocol rules or can be accurately estimated directly from the blockchain data. For example, when these values are 16, 40%, and 5%, respectively, the probability that the classifier correctly classifies a ring member as the real spend is 31.7%, much higher than the 1/16=6.25% probability of randomly guessing between the 16 ring members.

Why

Currently, Monero only has one node written in C/C++, many would see this as an issue. Having only one implementation makes us more vulnerable to implementation bugs, having another node will help us to spot and fix these issues.

monerod's code is also a bit of a mess, as many devs who have worked on it would agree. Cuprate is a fresh start and is built with modularity in mind which will lead to a cleaner and easier to understand codebase.

Having a consensus rules document will make it easier for developers to build software to interact with Monero. It will also make it easier to spot potential issues with consensus rules.

Popular documentation like “Mastering Bitcoin” suggests the usage of bx seed for wallet generation.

Secure cryptography requires a source of large, non-guessable numbers. If the random number generator is weak, the resulting cryptographic usage is almost always compromised.

For technical people: in this case, practical wallet security is reduced from 128 bit, 192 bit or 256 bit to a mere 32 bit of unknown key information.

I am not an expert, but if you use a multi-coin wallet that includes Monero, then your Monero could be affected. I don't see a list of wallet software that is affected. It would not be easy to verify that closed-source wallets do not use the exploitable code library.

Q: I used bx to generate my wallets but only use it for non-BTC coins, do I need to worry?

A: Yes. All funds stored on BIP39 mnemonic secrets or BIP32 wallet seeds are affected since the underlying private keys are basically public now.