16:13:27 <br-m> <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 https://mrelay.p2pool.observer/e/w-eq8sUKZG1yUVda ]
16:16:06 <br-m> <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.
16:16:30 <br-m> <rucknium> The meeting starts in 45 minutes, at 17:00 UTC as usual.
16:53:53 <br-m> <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. 
16:53:53 <br-m> <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.
16:56:11 <br-m> <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.
16:57:19 <br-m> <articmine> There is also the very real issue of conflict of interest here.
17:00:53 <br-m> <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.
17:01:16 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1292
17:01:19 <br-m> <rucknium> 1. Greetings
17:01:26 <br-m> <articmine> Hi
17:01:28 <br-m> <spackle> Hello
17:01:29 <br-m> <jberman> waves
17:01:40 <br-m> <sgp_> Hello
17:02:53 <br-m> <vtnerd> Hi
17:03:04 <br-m> <boog900> hi
17:03:44 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:05:02 <br-m> <sgp_> ping kayabaNerve. Working out a GBP issue (which they believe they found a resolution for)
17:05:10 <ArticMine> I have updated the scaling proposal and commented on the changes and impacts https://github.com/seraphis-migration/monero/issues/44
17:05:18 <br-m> <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? https://www.wireshark.org/docs/dfref/m/monero.html 
17:07:19 <br-m> <rucknium> ping @jeffro256:monero.social
17:07:36 <br-m> <jeffro256> Howdy
17:07:49 <br-m> <vtnerd> Me: subaddress lookahead in lws daemon
17:08:55 <br-m> <jeffro256> Me: fleshing out device integration for Carrot and working thru some Stressnet bugs  
17:09:33 <br-m> <rucknium> 3. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf). Revisit FCMP++ transaction weight function (https://github.com/seraphis-migration/monero/issues/44). Simple Market-Based Monero Fee Proposal (https://github.com/monero-project/research-lab/issues/152).
17:09:43 <br-m> <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 https://mrelay.p2pool.observer/e/vPP488UKQWJUbzhv ]
17:09:51 <br-m> <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 https://mrelay.p2pool.observer/e/4qv588UKanpVLUpy ]
17:09:56 <br-m> <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.
17:10:41 <ArticMine> Here are the facts https://bitinfocharts.com/comparison/transactions-price-xmr.html#log&alltime
17:11:55 <br-m> <jberman> Again, first and foremost, I want to reiterate there appears to be rough consensus for tx weight roughly equal to byte size
17:12:22 <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. 
17:12:29 <br-m> <rucknium> @jberman:monero.social: I agree.
17:12:52 <br-m> <articmine> @jberman: That is correct
17:13:33 <br-m> <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."
17:13:33 <br-m> <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.
17:13:33 <br-m> <sgp_> Is this acceptable ArticMine? What's the risk to Monero's principles in your view if we do that?
17:13:55 <br-m> <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 https://mrelay.p2pool.observer/e/6JOI9MUKQ3NsQXd3 ]
17:15:01 <br-m> <kayabanerve:matrix.org> Sorry for the late hello
17:16:07 <br-m> <jeffro256> @sgp_:monero.social: I will look more deeply at your proposal shortly .Could you link it here now for the record please ?
17:16:37 <br-m> <sgp_> github.com/monero-project/research-lab/issues/152
17:16:44 <br-m> <spackle> @rucknium:monero.social: Quick note that the most recent proposal from ArticMine is https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-11.pdf
17:17:01 <br-m> <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.
17:17:16 <br-m> <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. 
17:17:45 <br-m> <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.
17:21:18 <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
17:22:31 <ArticMine> The fees become prohibitive with just changinng the scaling factor to 8
17:22:53 <br-m> <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.
17:23:14 <ArticMine> It is the way for me to be able to support the safety margin at 16x
17:23:42 <br-m> <rucknium> What are the facts about daemon performance?
17:23:43 <br-m> <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.
17:24:03 <ArticMine> I also provided an interim temporary proposal using the current RingCT
17:24:27 <ArticMine> with a much lower cap
17:25:15 <ArticMine> Effectively 4x
17:25:26 <br-m> <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
17:25:49 <br-m> <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
17:26:14 <ArticMine> Please. I will not agree to baking the harms of BS ito the protocol. there is no such spam
17:26:54 <ArticMine> We are talking about ham
17:28:55 <br-m> <articmine> @jberman: This is wi I also provided the lower interim option
17:30:16 <ArticMine> If addition time is neeeded to fix this
17:31:35 <br-m> <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
17:32:24 <ArticMine> We have to consider post quantum attack for example when BC can play a role
17:32:35 <ArticMine> it is far from a non sequitor
17:33:05 <br-m> <jberman> Great! Carrot brings post quantum forward secrecy for people who don't share their addresses / for change outputs
17:33:14 <ArticMine> the issue here is the suppression of adoption
17:33:19 <br-m> <jberman> Delaying FCMP++ / Carrot is the most helpful thing you can do for blockchain surveillance
17:34:43 <br-m> <boog900> I do think there should be some cost preventing people from creating 16 MB bocks forever
17:34:49 <ArticMine> I really believe we can avoid this, but unfortunately we do have real issue with the code that need to be addressed
17:35:12 <br-m> <boog900> Although I do think 16 MB is a much better target for performance than 32 MB 
17:35:16 <ArticMine> The is what I call the BS harm trap
17:35:56 <ArticMine> if Monero adoption had not been suppressed by the BC companies 16 MB blocks could esily be the norem
17:36:21 <ArticMine> norm
17:36:56 <br-m> <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)
17:37:54 <br-m> <sgp_> *cost of the tail emission
17:37:56 <br-m> <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. 
17:37:56 <br-m> <rucknium> The advocates for slower scaling are worried that fast scaling could become a DDoS threat against the network because daemon performance is suboptimal.
17:37:56 <br-m> <rucknium> Am I seeing things correctly?
17:38:02 <br-m> <articmine> @sgp_: The fex in the simple proposal is extremely ext
17:38:17 <br-m> <articmine> Expensive 
17:39:25 <br-m> <articmine> @rucknium: Yes the Bitcoin issue is real.
17:40:28 <br-m> <articmine> We need to address the deamon issues. Not allow this to be an excuse to cripple Monero over the long term 
17:40:29 <br-m> <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
17:40:42 <br-m> <jberman> "because daemon performance is suboptimal" -> 16mb blocks = 4TB of chain data per year
17:42:14 <br-m> <sgp_> https://mrelay.p2pool.observer/m/monero.social/feLUbEJBHwlueOxjWrvaHMIT.png (image.png)
17:42:26 <br-m> <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)
17:42:47 <br-m> <articmine> In 50 blocks 
17:43:24 <br-m> <articmine> Spam is one of the real issues with this simple proposal 
17:43:25 <br-m> <rucknium> @jberman:monero.social: You are saying that the issues you see with fast scaling include raw blockchain storage size?
17:43:29 <br-m> <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
17:44:05 <br-m> <articmine> There is no pricing for the base scaling 
17:44:09 <br-m> <jberman> @rucknium: yes, imo daemon performance isn't even the primary issue
17:44:43 <br-m> <elongated:matrix.org> @sgp_: For a attacker (rouge mining pool) it doesn’t matter
17:44:56 <br-m> <jberman> There is also verification time and wallet sync time that would end up painful even when implemented in the theoretically optimal way
17:45:21 <tevador> I don't think we should allow anyone to choke the network with a random 16 MB block.
17:45:27 <br-m> <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
17:45:58 <br-m> <elongated:matrix.org> @sgp_: We had qubic, they can be incentivised other ways
17:46:29 <br-m> <articmine> tevador: ThIs is the reason why a ZCash type attack did not work in Monero
17:46:30 <br-m> <sgp_> The other proposal has no cost, so it's incrementally more. Whether it's a deterrent is another matter
17:46:49 <br-m> <sgp_> *sufficient deterrent
17:47:38 <br-m> <elongated:matrix.org> @sgp_: Can current ecosystem handle 16mb blocks ?
17:48:04 <br-m> <boog900> @jberman:monero.social: do you think growth should be slower or it should cost to maintain 16 MB blocks?
17:48:06 <br-m> <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
17:48:07 <br-m> <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.
17:48:07 <br-m> <boog900> Or something else 
17:48:13 <br-m> <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
17:48:28 <br-m> <spackle> But they must be given some amount of time to respond thoughtfully, and not ambushed.
17:49:24 <br-m> <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.
17:49:37 <br-m> <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
17:50:53 <br-m> <articmine> @jberman: There is a cost to maintain  16 MB blocks
17:51:37 <br-m> <articmine> If you stop the short term median resets 
17:52:09 <br-m> <sgp_> In mine, the max allowed block size will incur a fixed cost of 0.6 XMR per block
17:52:15 <br-m> <articmine> This has always been the case
17:52:51 <br-m> <articmine> Can we move on
17:54:58 <br-m> <rucknium> Move on to the next agenda item?
17:55:06 <br-m> <articmine> Yes 
17:56:12 <br-m> <rucknium> Ok
17:56:17 <br-m> <rucknium> 4. FCMP alpha stressnet (https://monero.town/post/6763165).
17:56:38 <br-m> <monerobull:matrix.org> Why did that ping me
17:56:48 <br-m> <monerobull:matrix.org> Ah, town link 
17:57:43 <br-m> <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 https://mrelay.p2pool.observer/e/99Co9cUKaV9rUjM2 ]
17:58:56 <br-m> <jberman> v1.4 may have introduced a regression as well that we're looking into too
17:59:45 <br-m> <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
17:59:58 <br-m> <jberman> 1. we're making progress
18:00:48 <br-m> <jberman> 2. v1.4 included a bug fix that addressed this issue, monitoring to see if that repeats
18:01:41 <br-m> <jberman> 3. I'm waiting on a repeat occurrence with reflected daemon logs for this one
18:02:58 <br-m> <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
18:06:18 <DataHoarder> how soon after alpha concludes would beta come online?
18:07:30 <br-m> <jberman> A week seems reasonable to me
18:09:44 <br-m> <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
18:10:17 <br-m> <rucknium> @boog900:monero.social: Could cuprate participate in stressnet, in the RingCT phase and/or FCMP phase, with that timeline?
18:10:27 <br-m> <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
18:10:49 <br-m> <boog900> Yes ringCT maybe FCMP 
18:10:51 <br-m> <rucknium> @jberman: Yes, that would been needed, too.
18:11:12 <DataHoarder> would remaining carrot changes be done before beta?
18:11:21 <br-m> <boog900> We can always join late too 
18:11:51 <br-m> <jberman> DataHoarder: yes
18:11:57 <br-m> <jberman> well I guess it depends which carrot changes you're referring to
18:12:02 <br-m> <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
18:12:26 <br-m> <jberman> We have a TODO list tracker for beta here: https://github.com/seraphis-migration/monero/issues/166
18:12:51 <br-m> <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
18:13:06 <br-m> <jeffro256> DataHoarder: Which changes ?
18:13:23 <DataHoarder> personalization string for one 
18:13:35 <DataHoarder> for the transcript / blake2b in general
18:15:15 <DataHoarder> any coinbase specific changes (for example same pubkey suggested by tevador, but I think that's relevant for future stuff)
18:18:13 <br-m> <rucknium> Anything else on stressnet?
18:18:46 <br-m> <jberman> Nothing from me
18:19:35 <br-m> <rucknium> Thank you, everyone working on stressnet fixes :)
18:19:38 <br-m> <rucknium> 5. Mining pool centralization: Temporary rolling DNS checkpoints (https://github.com/monero-project/monero/issues/10064), Share or Perish (https://github.com/monero-project/research-lab/issues/146), and Lucky transactions (https://github.com/monero-project/research-lab/issues/145).
18:22:06 <DataHoarder> maybe spend some developer time between alpha and beta stressnet fixing the bug within that core function for DNS checkpoints to function ^ ?
18:23:05 <DataHoarder> this is an example of technical debt and flawed implementation, if we are to be fixing those :)
18:24:38 <br-m> <boog900> DataHoarder: Do we know where the bug is yet?
18:25:25 <br-m> <boog900> Or what the exact bug is
18:25:54 <DataHoarder> 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
18:26:34 <DataHoarder> 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
18:28:29 <br-m> <rucknium> DataHoarder: https://libera.monerologs.net/monero-research-lab/20251029#c604484-c604495
18:29:23 <DataHoarder> 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 :)
18:34:20 <br-m> <rucknium> We can end the meeting here. Thanks everyone.
18:34:32 <br-m> <sgp_> I accidentally closed my issue, can it be reopened please? https://github.com/monero-project/research-lab/issues/152
18:34:42 <br-m> <sgp_> rip
18:36:02 <br-m> <rucknium> Done.
18:36:05 <br-m> <articmine> @rucknium: Thanks
18:36:23 <br-m> <sgp_> @rucknium: thanks!
18:38:53 <br-m> <sgp_> @jeffro256:monero.social: am I misunderstanding your comment about the fee market, and sender fee selections?
19:50:09 <br-m> <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
19:50:09 <br-m> <ofrnxmr> for stripe_main_proceed, there were 2 contributing factors:
19:50:10 <br-m> <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 https://mrelay.p2pool.observer/e/xrXE-MUKM1VlQTNW ]