The MRL discussion on transaction volume scaling parameters post-FCMP hard fork had rough consensus on transaction weights roughly equaling byte size, but debates on block size limits, surge factors, growth rates, and fee mechanisms to prevent spam while avoiding adoption suppression from high fees; concerns included daemon performance, ~4 TB annual storage growth, verification times, and balancing fast scaling against DDoS risks, with proposals from ArticMine for low-penalty scaling and sgp_ for a simple market-based model requiring costs for large blocks. rucknium: I will add more structure to the scaling discussion agenda item. I will ask meeting participants to write what they think are the relevant facts about transaction volume scaling. These facts must be about the present or past. Nothing about the future. "It is difficult to make predictions, especially about the future." I think there is a path to rough consensus on post-hardfork scaling parameters. Finding the path will be easier if the discussion participants can get on the same page about the facts. jberman: Again, first and foremost, I want to reiterate there appears to be rough consensus for tx weight roughly equal to byte size ArticMine: A 30x growth in on chain transaction is nuder 2 years and strong evidence of the suppression of Monero adoption by the BS companies for close to a decade. sgp_: For the simple proposal, consider for comparison scaling parameters as follows: set the initial flex space to 16 MB-ish (as what ArticMine picked in their update) and the permitted growth rate to 50%/year. spackle: If the surge factor is instead set to 8 (M_N=min(M_S, 8*M_L)), miners are penalized for creating 16 MB blocks and a fee market is required to support that level. I prefer setting the surge factor to 8. That said, either approach gives the design a safety margin. If there is consensus behind either option I believe both are acceptable. ArticMine: My change allows for nor low rate scaling between MS at 8x ML and MS at 16x ML,. There is not need to pay outrageous fees if the scaling rate is low. The fees become prohibitive with just changinng the scaling factor to 8. sgp_: A fact is that 16 MB blocks full for a year (e.g. miner spam) is ~4 TB of growth per year. Assuming no further growth in the block size or additional spam jberman: Once we have this OOM issue solved + tx relay v2 in, we will likely get a better picture of what the daemon is able to handle. Hopefully that will be within the next week or 2 rucknium: The advocates for fast scaling are worried that history will repeat itself. Bitcoin's 1MB limit was supposed to be a temporary anti-spam measure. As the saying goes, there is nothing more permanent than a "temporary" solution. The advocates for slower scaling are worried that fast scaling could become a DDoS threat against the network because daemon performance is suboptimal. jberman: "because daemon performance is suboptimal" -> 16mb blocks = 4TB of chain data per year There is also verification time and wallet sync time that would end up painful even when implemented in the theoretically optimal way tevador: I don't think we should allow anyone to choke the network with a random 16 MB block. jberman: I think it should cost to maintain 16 MB blocks and I agree I like that a miner / the network can't immediately create a 16 MB block in the more complex proposal spackle: Put differently, when everyone goes to sleep at night they must know that the network will be in a stable condition when they wake up the next day. I believe that is the key requirement for the scaling algorithm in the short term. libera.monerologs.net/monero…

The brief discussion on mining pool centralization focused on fixing a DNS checkpoints bug with calls for a reproducible sequence or unit test to aid debugging. DataHoarder: maybe spend some developer time between alpha and beta stressnet fixing the bug within that core function for DNS checkpoints to function ^ ? this is an example of technical debt and flawed implementation, if we are to be fixing those :) boog900: Do we know where the bug is yet? Or what the exact bug is DataHoarder: we know the symptom and affected function, unclear if that's where the bug is... a checkpoint set on an altchain at a specific height causes monero to get stuck and not be able to switch to the altchain or add blocks after it'd help massively as mentioned if we can get a specific repro sequence, as otherwise it's hard to test against. or a unit test for it :) libera.monerologs.net/monero…

The FCMP alpha stressnet discussion highlighted progress on version 1.4 with fixes for high memory usage and other bugs, identification of three blocking issues (OOM errors, transaction pool clearing, and wallet double spends), and plans to resolve them soon before advancing to beta with consensus on scaling parameters. jberman: We released v1.4 of the stressnet which includes some monerod fixes and improvements. I identified a significant cause of high memory usage in the FCMP++ integration (batch verifying many large input proofs simultaneously), discussed with kayabanerve who brought down mem usage 33%, and I wrote an initial patch that takes more careful consideration for batch verifying many large proofs in parallel. Before running the patch, SNeedlewoods was running into OOM's repeatedly on a machine with 8GB, and since running the patch a little over 24h ago hasn't had an OOM. So we're making solid progress on the OOM front, and once fully solved, would leave 1 more issue I considered a "blocking" issue for the integration last week v1.4 may have introduced a regression as well that we're looking into too Repeating the 3 blocking issues: 1) OOM's, 2) daemon kicking all txs from the pool but one, 3) wallet running into double spends after some use 1. we're making progress 2. v1.4 included a bug fix that addressed this issue, monitoring to see if that repeats 3. I'm waiting on a repeat occurrence with reflected daemon logs for this one. With OOM addressed + tx relay v2 (which may also help with OOM's), and observed stable perf under stress, I would advocate for moving to the beta DataHoarder: how soon after alpha concludes would beta come online? jberman: A week seems reasonable to me Rucknium: IMHO, a little more notice than a week would be good to get more people running nodes. But you can give more than one week of notice if the alpha stressnet shuts down after the beta announcement - Need to reach consensus on scaling parameters before beta: jberman: Of note, we'll also want to reach consensus on scaling params and implement it before beta, so there is going to be some time. - Potential inclusion of Cuprate in stressnet phases: rucknium: boog900, Could cuprate participate in stressnet, in the RingCT phase and/or FCMP phase, with that timeline? boog900: Yes ringCT maybe FCMP. We can always join late too. - Remaining Carrot changes to be addressed before beta: DataHoarder: would remaining carrot changes be done before beta? jberman: yes. DataHoarder: personalization string for one for the transcript / blake2b in general. any coinbase specific changes (for example same pubkey suggested by tevador, but I think that's relevant for future stuff). - Updating Oxide and Cuprate for FCMP: kayabanerve: The issue with the FCMP phase is that someone has to update oxide, and then propagate to Cuprate, and I'll note a few misc rules have been added which'll need to found and indexed. Updating oxide isn't the worst, it's already in Rust, I'm just noting someone has to get it over the hump. - TODO list tracker for beta on GitHub: jberman: We have a TODO list tracker for beta here: github.com/seraphis-migratio…. libera.monerologs.net/monero…

Mining pool centralization: Temporary rolling DNS checkpoints, github.com/monero-project/mo… Share or Perish, github.com/monero-project/re… and Lucky transactions. github.com/monero-project/re…

FCMP alpha stressnet. monero.town/post/6763165

Transaction volume scaling parameters after FCMP hard fork. github.com/ArticMine/Monero-… Revisit FCMP++ transaction weight function. github.com/seraphis-migratio… Simple Market-Based Monero Fee Proposal. github.com/monero-project/re…

Monero Research Lab Meeting - Wed 05 November 2025, 17:00 UTC github.com/monero-project/me…

The discussion on mining pool centralization was focused primarily on a bug blocking DNS checkpoint implementation: DataHoarder: still blocked by the issue on monero around hitting a checkpoint in the wrong place rucknium: DataHoarder, What are the resources needed to address the DNS checkpoint bug, in your opinion? DataHoarder: rucknium, a reproducer that can be fed via pop_blocks, restart, then feed blocks / txs via RPC in offline mode (that way we can literally script the steps and can verify the behavior to debug further and start untangling that) realistically it should get refactored to not be really tied together then it can get well unit tested that's a ... larger change, in a very consensus part of the logic someone that knows that consensus part well can attempt the fixes, but it's not great without a specific reproducer other than "get lucky when the checkpoints are set" I manually attempted to selfish mine myself and place the branch in the specific point it's supposed to trigger the issue, but it didn't (and instead got banned for several days by all testnet peers :D) FCMP++ stressnet also took all the attention, so not much has been done on regular testnet ^ looking into this one rucknium: I converted most of my testnet nodes to stressnet nodes. I could keep both stressnet and testnet on the same machines, but then the stressnet node would OOM kill everything :D libera.monerologs.net/monero…

The MRL FCMP alpha stressnet discussion highlighted technical debt in monerod and ongoing bug fixes: rucknium: it seems to me that monerod is full of technical debt. vtnerd: seen worse. its still manageable, but others may have different thoughts articmine: rucknium, Yes, I agree and this debt needs to be repaid before the hard fork DataHoarder: I'm a programmer, I agree, specially in the older parts of the codebase. They are usually also uncommented and have generic naming jberman: ofrn and I discussed blocker issues for mainnet launch: 1) OOM after synced (we're going to figure this out), 2) pool consistently cutting down to 1 tx (hopefully solved with the latest bug fix), 3) wallet complaining about double spends The OOM was there from the start, we think it's related to something from the FCMP++ integration, potentially the FFI Just judging the stressnet channel, it seems to me like we have noticed actual improvement on connection issues and such. So it doesn't look like problems are increasing to me... ...ofrn and I discussed blocker issues for mainnet launch: 1) OOM after synced (we're going to figure this out), 2) pool consistently cutting down to 1 tx (hopefully solved with the latest bug fix), 3) wallet complaining about double spends but generally I think we want to solve these issues before mainnet launch. And once tx relay v2 + cache validated txs is in and perf observed, we decide on beta stressnet. libera.monerologs.net/monero…

The MRL discussion covered scaling proposals, fee incentives, and transaction weight calculations. This discussion topic continues to be challenging, primarily due to debates over parameters: rucknium: This discussion topic continues to be challenging. If there are suggestions about how to structure the discussion (especially in the future), please bring them :) articmine: As I mentioned before I do not have to report anything new since I believe that addressing this new 10% proposal is required sgp_: I added two more aggressive scaling examples to my proposal. My proposal aims to simplify scaling and fees. Other parameters can be chosen, so feel free to ask me for different numbers. 10% is my suggestion and one example parameter, but any other value (e.g. 50%) can be chosen if desired. I included numbers for 25% and 50% this morning articmine: I agree that this topic is challenging primarily because of the sheer amount of fud and misinformation that has been imported from Bitcoin and related coins. As for this 10 % proposal my preliminary assessment is that it is a complete disaster and also a serious breach of the Monero's can Cryptonote social covenants jberman: I think there are 2 core problems to solve on this front: 1) tx weight, and 2) scaling algo. Personally I would prefer to tackle the former first, and the latter second. They can be solved together in one pass, but I think we'd end up stuck in bikeshedding hell trying to articmine: jberman, Actually the scaling algorithm need to be addressed first spackle: At present, Monero's scaling design gives no consideration to the capabilities of the daemon. Regardless of the path chosen, I believe this must change in the future. articmine: Since what we are ultimately dealing is fee incentives sgp_: My proposal works for any transaction weight calculation, so it would be fine to handle those separately from that perspective articmine: sgp_, No it doesn't ... rucknium: ... I will see if I can come up with more structure for the scaling discussion for next time. In the meantime, please feel free to share ideas for a structure. libera.monerologs.net/monero…

Security Assessment for the Helios–Selene Curve Cycle (by Bassa/@VeridiseInc ) moneroresearch.info/index.ph… sgp_: The parameters were changed to follow their recommendations. Ty tevador, kayabanerve, and Veridise for your huge help with this, and thanks to the community here for supporting this review. Veridise will work on the formal code verification next.

Rucknium: boog900 noticed that the spy node test is showing some spy nodes as false negatives, starting about a week ago: moneronet.info/ These nodes are still on the same IP addresses. About 100 in DigitalOcean and 100 in Hetzner. The LionLink spy nodes have the same behavior as before. The MRL ban list is still valid. The network should be monitored for "metastasizing" behavior of the spy nodes, i.e. new spy nodes without the peerID fingerprint But, the spy nodes may still be detectable with other tests. This recent paper monitors packet data: Kopyciok, Y., Schmid, S., & Victor, F. 2025. Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. moneroresearch.info/280 and finds a lot of anomalous behavior. Their code is open source, so I could try to run it. They use regular passive Monero nodes to collect the data, so it won't be as fast or complete as the network crawler scan that moneronet.info uses. AFAIK, @SyntheticBird_ discovered another way to deduce spy nodes. I could push Core to change the DNS ban list to include more spy nodes: github.com/monero-project/me… IMHO, this issue ^ is mature and has had time for comments. I set up moneronet.info because it shows pretty graphs and because it helps reveal changes in spy node behavior. It's doing its job 😁 libera.monerologs.net/monero…

Remember that monerod-gui works also with FCMP++ alpha stressnet nodes, with just a few clicks you can start helping with testing! github.com/everoddandeven/mo…

Mining pool centralization: Temporary rolling DNS checkpoints, github.com/monero-project/mo… Share or Perish, and github.com/monero-project/re… Lucky transactions. github.com/monero-project/re…

FCMP alpha stressnet. monero.town/post/6763165

Transaction volume scaling parameters after FCMP hard fork. github.com/ArticMine/Monero-… Revisit FCMP++ transaction weight function. github.com/seraphis-migratio… Simple Market-Based Monero Fee Proposal. github.com/monero-project/re…

Spy nodes. github.com/monero-project/me…

Monero Research Lab Meeting - Wed 29 October 2025, 17:00 UTC github.com/monero-project/me…

The Monero Research Lab is actively researching post-quantum encryption for Monero! 'CARROT already brings several forward-secrecy improvements. The purpose of Jamtis is to provide forward secrecy against a quantum enabled adversary even if a wallet address is publicly known.'