<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." Exampl [... too long, see mrelay.p2pool.observer/e/w-eq8sUKZG1yUVda ]

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

<rucknium> The meeting starts in 45 minutes, at 17:00 UTC as usual.

<articmine> We cannot ignore the future if we analyze the present and past. In particular the impact of blockchain surveillance BS in suppressing Monero adoption for the last decade.

<articmine> A simple reversal in the US courts of a criminal conviction could derail the entire BS law enforcement narrative, and unleash Monero adoption after suppression for over a decade.

<articmine> I will not support baking into the Monero protocol the harm that the BS companies have done to Monero by looking at only the past and present.

<articmine> There is also the very real issue of conflict of interest here.

<rucknium> The future will be discussed later in the meeting. It will be much easier to start by closing the gap between participants by agreeing on facts.

<rucknium> Meeting time! monero-project/meta #1292

<rucknium> 1. Greetings

<articmine> Hi

<spackle> Hello

<jberman> waves

<sgp_> Hello

<vtnerd> Hi

<boog900> hi

<rucknium> 2. Updates. What is everyone working on?

<sgp_> ping kayabaNerve. Working out a GBP issue (which they believe they found a resolution for)

I have updated the scaling proposal and commented on the changes and impacts seraphis-migration/monero #44

<rucknium> me: Starting my first adventures with using Wireshark to analyze Monero p2p packets for spy node analysis. Did you know that Monero has its own display filter in Wireshark? wireshark.org/docs/dfref/m/monero.html

<rucknium> ping @jeffro256:monero.social

<jeffro256> Howdy

<vtnerd> Me: subaddress lookahead in lws daemon

<jeffro256> Me: fleshing out device integration for Carrot and working thru some Stressnet bugs

<rucknium> 3. Transaction volume scaling parameters after FCMP hard fork (github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf). Revisit FCMP++ transaction weight function (seraphis-migration/monero #44). Simple Market-Based Monero Fee Proposal (monero-project/research-lab #152).

<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." Example [... too long, see mrelay.p2pool.observer/e/vPP488UKQWJUbzhv ]

<jberman> Me: 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:matrix.org who brought down mem usage 33%, and I wrote an initial patch [... too long, see mrelay.p2pool.observer/e/4qv588UKanpVLUpy ]

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

Here are the facts bitinfocharts.com/comparison/transactions-price-xmr.html#log&alltime

<jberman> Again, first and foremost, I want to reiterate there appears to be rough consensus for tx weight roughly equal to byte size

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.

<rucknium> @jberman:monero.social: I agree.

<articmine> @jberman: That is correct

<sgp_> I only have one comment at this moment, which is how I don't understand how my simpler proposal is in conflict with "Monero's principles."

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

<sgp_> Is this acceptable ArticMine? What's the risk to Monero's principles in your view if we do that?

<kayabanerve:matrix.org> Hello, I've been handling bug fixes, improvements to oxide as it targets 1.0, managing merging GBPs into oxide's main branch _and_ its BBP program, and going back and forth with Berman a bit (they're doing the work) on higher than expected memory use. I did make a patch for one obvious oversight that brought it down 33%, but t [... too long, see mrelay.p2pool.observer/e/6JOI9MUKQ3NsQXd3 ]

<kayabanerve:matrix.org> Sorry for the late hello

<jeffro256> @sgp_:monero.social: I will look more deeply at your proposal shortly .Could you link it here now for the record please ?

<sgp_> github.com/monero-project/research-lab/issues/152

<spackle> @rucknium:monero.social: Quick note that the most recent proposal from ArticMine is github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-11.pdf

<spackle> There is no penalty zone when the penalty median is equal to the maximum block size. Miners will receive the full block reward when creating a steady stream of 16 MB blocks.

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

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

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

<spackle> As I see it, the key requirement is that there is no short term gap between daemon performance and scaling limits. So long as there is developer/community consensus that the daemon can handle a steady stream of 16 MB blocks, either is acceptable.

It is the way for me to be able to support the safety margin at 16x

<rucknium> What are the facts about daemon performance?

<spackle> At the moment, I do not know that 16 MB is the correct level. I am waiting to hear the educated opinions of others.

I also provided an interim temporary proposal using the current RingCT

with a much lower cap

Effectively 4x

<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

Please. I will not agree to baking the harms of BS ito the protocol. there is no such spam

We are talking about ham

<articmine> @jberman: This is wi I also provided the lower interim option

If addition time is neeeded to fix this

<jberman> Bringing blockchain surveillance into this discussion is a non sequitur. FCMP++ is by 100 miles the most significant thing we can do to negatively impact blockchain surveillance at this stage

We have to consider post quantum attack for example when BC can play a role

it is far from a non sequitor

<jberman> Great! Carrot brings post quantum forward secrecy for people who don't share their addresses / for change outputs

the issue here is the suppression of adoption

<jberman> Delaying FCMP++ / Carrot is the most helpful thing you can do for blockchain surveillance

<boog900> I do think there should be some cost preventing people from creating 16 MB bocks forever

I really believe we can avoid this, but unfortunately we do have real issue with the code that need to be addressed

<boog900> Although I do think 16 MB is a much better target for performance than 32 MB

The is what I call the BS harm trap

if Monero adoption had not been suppressed by the BC companies 16 MB blocks could esily be the norem

norm

<sgp_> @boog900:monero.social the simple proposal could be set with a flex space of 16 MB. Then those blocks could still be made, but only at the cost of the block reward. And the size of the flex space could be permitted to grow (accounting for tech improvements)

<sgp_> *cost of the tail emission

<rucknium> I think that 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.

<rucknium> The advocates for slower scaling are worried that fast scaling could become a DDoS threat against the network because daemon performance is suboptimal.

<rucknium> Am I seeing things correctly?

<articmine> @sgp_: The fex in the simple proposal is extremely ext

<articmine> Expensive

<articmine> @rucknium: Yes the Bitcoin issue is real.

<articmine> We need to address the deamon issues. Not allow this to be an excuse to cripple Monero over the long term

<sgp_> at 16 MB max block size, the approximate penalty from the tail emission is 0.000384615 XMR/tx, or ~$0.13 in today's prices

<jberman> "because daemon performance is suboptimal" -> 16mb blocks = 4TB of chain data per year

<sgp_> mrelay.p2pool.observer/m/monero.social/feLUbEJBHwlueOxjWrvaHMIT.png (image.png)

<boog900> I do like the slow increase with the more complex proposal though, with yours you can wack a 16 MB block straight away right? > <@sgp_> @boog900:monero.social the simple proposal could be set with a flex space of 16 MB. Then those blocks could still be made, but only at the cost of the block reward. And the size of the flex space could be permitted to grow (accounting for tech improvements)

<articmine> In 50 blocks

<articmine> Spam is one of the real issues with this simple proposal

<rucknium> @jberman:monero.social: You are saying that the issues you see with fast scaling include raw blockchain storage size?

<sgp_> @boog900: If that's what you set it to. You can of course pick a lower number if you want. Creating a block that consumes the entire flex space costs the tail emission

<articmine> There is no pricing for the base scaling

<jberman> @rucknium: yes, imo daemon performance isn't even the primary issue

<elongated:matrix.org> @sgp_: For a attacker (rouge mining pool) it doesn’t matter

<jberman> There is also verification time and wallet sync time that would end up painful even when implemented in the theoretically optimal way

I don't think we should allow anyone to choke the network with a random 16 MB block.

<sgp_> @elongated:matrix.org: A mining pool pays the opportunity cost by not receiving the tail emission, that's a major advantage of the simple proposal

<elongated:matrix.org> @sgp_: We had qubic, they can be incentivised other ways

<articmine> tevador: ThIs is the reason why a ZCash type attack did not work in Monero

<sgp_> The other proposal has no cost, so it's incrementally more. Whether it's a deterrent is another matter

<sgp_> *sufficient deterrent

<elongated:matrix.org> @sgp_: Can current ecosystem handle 16mb blocks ?

<boog900> @jberman:monero.social: do you think growth should be slower or it should cost to maintain 16 MB blocks?

<articmine> @sgp_: As I indicated I will respond to your proposal in GitHub. First I want to work on the weights for which we have consensus

<spackle> There is the additional matter that miners may limit block sizes out of sheer practicality, and I expect that would be the case in reality. If the network is configured to sufficiently limit the network to daemon performance in the short term to what it can handle, all network participants are given some amount of time to respond to any condition that arises.

<boog900> Or something else

<sgp_> Fwiw I don't propose 16 MB blocks, I'm just saying that those are *compatible" with my proposal if that's what you want. I want smaller blocks

<spackle> But they must be given some amount of time to respond thoughtfully, and not ambushed.

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

<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

<articmine> @jberman: There is a cost to maintain 16 MB blocks

<articmine> If you stop the short term median resets

<sgp_> In mine, the max allowed block size will incur a fixed cost of 0.6 XMR per block

<articmine> This has always been the case

<articmine> Can we move on

<rucknium> Move on to the next agenda item?

<articmine> Yes

<rucknium> Ok

<rucknium> 4. FCMP alpha stressnet (monero.town/post/6763165).

<monerobull:matrix.org> Why did that ping me

<monerobull:matrix.org> Ah, town link

<jberman> Repeating my prior update: 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 ini [... too long, see mrelay.p2pool.observer/e/99Co9cUKaV9rUjM2 ]

<jberman> v1.4 may have introduced a regression as well that we're looking into too

<jberman> 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

<jberman> 1. we're making progress

<jberman> 2. v1.4 included a bug fix that addressed this issue, monitoring to see if that repeats

<jberman> 3. I'm waiting on a repeat occurrence with reflected daemon logs for this one

<jberman> 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

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

<rucknium> @boog900:monero.social: Could cuprate participate in stressnet, in the RingCT phase and/or FCMP phase, with that timeline?

<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

<boog900> Yes ringCT maybe FCMP

<rucknium> @jberman: Yes, that would been needed, too.

would remaining carrot changes be done before beta?

<boog900> We can always join late too

<jberman> DataHoarder: yes

<jberman> well I guess it depends which carrot changes you're referring to

<kayabanerve:matrix.org> 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

<jberman> We have a TODO list tracker for beta here: seraphis-migration/monero #166

<kayabanerve:matrix.org> Updating oxide isn't the worst, it's already in Rust, I'm just noting someone has to get it over the hump

<jeffro256> DataHoarder: Which changes ?

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)

<rucknium> Anything else on stressnet?

<jberman> Nothing from me

<rucknium> Thank you, everyone working on stressnet fixes :)

<rucknium> 5. Mining pool centralization: Temporary rolling DNS checkpoints (monero-project/monero #10064), Share or Perish (monero-project/research-lab #146), and Lucky transactions (monero-project/research-lab #145).

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> DataHoarder: Do we know where the bug is yet?

<boog900> Or what the exact bug is

we know the symptom and affected function, unclear if that's where the bug is. I think links were posted last meeting, but I don't have that backlog available currently

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

<rucknium> DataHoarder: libera.monerologs.net/monero-research-lab/20251029#c604484-c604495

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 :)

<rucknium> We can end the meeting here. Thanks everyone.

<sgp_> I accidentally closed my issue, can it be reopened please? monero-project/research-lab #152

<sgp_> rip

<rucknium> Done.

<articmine> @rucknium: Thanks

<sgp_> @rucknium: thanks!

<sgp_> @jeffro256:monero.social: am I misunderstanding your comment about the fee market, and sender fee selections?

<ofrnxmr> @boog900:monero.social im testing now, but i think we have the runaway spans fixed. > <@jberman> 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

<ofrnxmr> for stripe_main_proceed, there were 2 contributing factors:

<ofrnxmr> 1. I found an issue with next_needed_height, there it would incorrectly display blocks that we already have (fixed by 0xfffc)[... more lines follow, see mrelay.p2pool.observer/e/xrXE-MUKM1VlQTNW ]