<kayabanerve:matrix.org> @diego:cypherstack.com: The current ruled can cause the network to blow up in a year without my proposal for a static limit.

<kayabanerve:matrix.org> *rules

<kayabanerve:matrix.org> There is a minimum required patch set, even if we can debate if an entire new proposal must be done with FCMP++ or after.

<kayabanerve:matrix.org> It's why my proposal was independent

<diego:cypherstack.com> Can I see the write up?

<diego:cypherstack.com> Sorry must have missed it.

<kayabanerve:matrix.org> It was a 32 MB limit which became the heavily-discussed 90 MB limit.

<kayabanerve:matrix.org> 32 MB was proposed as it's our effective bandwidth from stressnet. 90 MB was thrown out by @boog900:monero.social: to ask ArticMine if they'd accept literally any discussion on this, as after that, things definitively break.

<kayabanerve:matrix.org> Things already start breaking at 32 MB, that's just a much more managed situation with a 3 line PR adequate and not requiring resigning block distribution and the RPC.

<articmine> I uploaded my proposal to lower the penalty free zone to 62500 bytes.

<articmine> github.com/ArticMine/Monero-Documen…/master/MoneroScaling2025-12-02.pdf

<articmine> First year less than 1.4*10^7 bytes

<gingeropolous> yah know what, this has been bouncing around my head. Basically, we could be setting a precedent that we don't want to set. (I guess this depends on how things are fixed / modified). But imagine we fix the things, it all works. We lift the sanity cap. But, we ask, do we know if the code can handle 1GB blocks? Even if we are fu [... too long, see mrelay.p2pool.observer/e/yOvR288KT2NYZ3R5 ]

<kayabanerve:matrix.org> I think there's a difference between performance degradations at 1 GB and the code literally breaking upon 1 GB.

<kayabanerve:matrix.org> If we properly shred blocks, and re-design the RPC as unbounded, there wouldn't be such hard limits.

<jbabb:cypherstack.com> not to be pedantic but the current scaling parameters etc were also arbitrary before they were set

<jbabb:cypherstack.com> I don't think we'd really reach 32 MB for awhile, but with it being a simple fix, it's simple to undo, too. 32 MB for such and such time and then the ArticMine + tevador proposal but, frankly, with of the parameters lower, I think (but that's just me)

<gingeropolous> block shreds. mmmmmmmm

<jbabb:cypherstack.com> a hard cap for x amount of blocks is the quickest and easiest. clean to reverse as well, just a few lines to remove

<jbabb:cypherstack.com> I think we could get consensus that 10-90 MB is reasonable as long as there's a realistic deactivation height. at least 3 months, but really 6 mos is still fast. 32 MB for a year or two and with an adjusted LTM now is realistic

<jbabb:cypherstack.com> it is a bit of a tangent but I always want to lower the barrier to entry or resources required to participate... both in terms of hardware as well as in fees. I always used to want to continually change the hash algo as an anti-ASIC measure, but that's a bit unrealistic... and perhaps futile, anyways

<jbabb:cypherstack.com> at least adjusting the hash algo by doubling the blake 2b round as suggested would be a good first step, that's easy

<gingeropolous> randomx is already anti-ASIC

<kayabanerve:matrix.org> @jbabb:cypherstack.com: The deactivation height is when this is fixed.

<articmine> My proposal is under 14 MB for a year. Why 32 MB for a year?

<articmine> What is really requested here is an indefinite deactivation height

> there's a realistic deactivation height.

^ then nodes can be fed blocks above that height before reaching it :)

<monero.arbo:matrix.org> wow so I'm gone a couple days and AM has resorted to spreading FUD on reddit. I wish I were surprised > <@sgp_> lazy developers need to do their job reddit.com/r/Monero/comments/1peug7…o_developers_are_on_track_to_add_an

<monero.arbo:matrix.org> > <@gingeropolous> yah know what, this has been bouncing around my head. Basically, we could be setting a precedent that we don't want to set. (I guess this depends on how things are fixed / modified). But imagine we fix the things, it all works. We lift the sanity cap. But, we ask, do we know if the code can handle 1GB bl [... too long, see mrelay.p2pool.observer/e/-syq7M8KRWJqTG1F ]

<monero.arbo:matrix.org> this is why I think the growth rate needs to be much lower. It gives you room to breathe without feeling like you need "sanity caps" just in case the block size blows up so fast it breaks the network

<gingeropolous> so no sanity cap, but a much slower overall growth rate allowed by the dynamic algos?

<ofrnxmr:xmr.mx> 90mb isnt a sanity cap

<gingeropolous> lol

<ofrnxmr:xmr.mx> The sanity cap is the 1.4x yearly expanding cap

<gingeropolous> your a sanity cap

<articmine> Which is why indexing the sanity cap to below Neilsen's Law makes sense

<ofrnxmr:xmr.mx> 90mb is a hard cap related to packet size limit

<gingeropolous> gotcha

<boog900> @monero.arbo:matrix.org: have you seen my proposal, much better expectations for nodes/ node operators

<monero.arbo:matrix.org> @boog900:monero.social: I'm just catching up from the last few days, I have it open to read rn (:

<monero.arbo:matrix.org> Basically yes. We could have fast growth for a bit, to allow for processing bursts of network activity in a reasonable time, but then it needs to dramatically slow for some amount of time before it's allowed to "blow up" again > <@gingeropolous> so no sanity cap, but a much slower overall growth rate allowed by the dynamic algos?

<gingeropolous> @boog900:monero.social: , tryin to find link. do you have it handy?

<monero.arbo:matrix.org> seraphis-migration/monero #44#issuecomment-3617687600

<monero.arbo:matrix.org> @monero.arbo:matrix.org: so this could get it 25 MB in a year and gigabyte blocks in two years?

<boog900> yes to 25 no to gigabyte

<articmine> It is not capped by Nielsen's Law

<monero.arbo:matrix.org> @boog900: so the 40x per year slows down?

<articmine> So over the long term is more growth aggressive than mine

<boog900> @monero.arbo:matrix.org: it's only 40x to 47x if your ltm has adjusted, with 2 years of spam it wont have fully adjusted in the second year meaning you only get the 1.2x every ltm adjustment

<monero.arbo:matrix.org> hmm okay I see

<boog900> so yes it would only be 2.5x in the second year

<monero.arbo:matrix.org> @articmine: great then let's have both (:

<monero.arbo:matrix.org> (both limits)

<boog900> yeah if artic is really scared I am down for that, but he is not

<boog900> he is misrepresenting it like he has been doing

<boog900> he wants more growth not les

<articmine> We need to keep both the cap and the 2x on ML

<articmine> 2.5x compounded annually is greater than 1.4x

<basses:matrix.org> ART: A Graph-based Framework for Investigating Illicit Activity in Monero via Address-Ring-Transaction Structures

<basses:matrix.org> arxiv.org/abs/2511.16192

<boog900> the 1.4x happens without any usage

<basses:matrix.org> Advanced Monero wallet forensics: Demystifying off-chain artifacts to trace privacy-preserving cryptocurrency transactions

<basses:matrix.org> sciencedirect.com/science/article/pii/S2666281725001283

<monero.arbo:matrix.org> @boog900: that's bad

<boog900> @monero.arbo:matrix.org: I know, thats the difference

<boog900> mine is 2.5x if you max out the scaling algorithm

<boog900> his is 1.4x if there are literally 0 txs

<boog900> but he is trying to portray it as them being the same and his being less aggressive, when he himself knows its not. If he did think it was more aggressive do you not think he would support it?

<monero.arbo:matrix.org> yeah I hear you

<boog900> I can add the sanity cap but I really think it is unnecessary.

<boog900> here is what I put in the comment on github:

<boog900> > If sufficient usage was required to increase the cap then we could have the same outcome (if the algorithm was exponential), but we would have real warning as the block size creeps up, giving us time to put out a softfork if growth keeps growing. With this proposal, the maximum size that blocks can reach from 0 is always inc [... too long, see mrelay.p2pool.observer/e/4M-F7c8KNWJtc2ct ]

<monero.arbo:matrix.org> I figure your proposal gives us about 1-2 years of runway before things start to get bad in terms of network stability. Do we feel like that's enough to address any concerns that might arise in that time?

<monero.arbo:matrix.org> What if like, the longer the blocksize is continually pushed up (without stabilizing for x amount of time) the harder it is to push up?

<monero.arbo:matrix.org> idk just spitballing

<boog900> To do that you could probably increase the short term multiplier and decrease the long term multiplier

<boog900> I do think 2 years is enough warning though, I don't think this scaling proposal is the best possible but I wanted to keep it simple

<boog900> As otherwise it'll be a pain to get consensus for

<articmine> The growth in the sanity cap with no actual growth in usage is necessary especially to address BS suppression of Monero.

<articmine> I explained this scenario in my notes

<boog900> Yes we know you believe dangerous growth is needed and this ever increasing sanity cap is a way for you to sneak it in.

<monero.arbo:matrix.org> btw AM you keep mentioning the 100x growth in LTC transactions in 2017 but I'm looking at the chart and it looks more like 50x (from 2.3k to 111k) in a year before dropping down to 20-30k just a few months later (so only 10x from the initial 2.3k)

<articmine> I believe growth that is dangerous to Blockchain Surveillance but not to Monero

<elongated:matrix.org> @articmine: How does it affect BS companies ? After fcmp they have no edge

<articmine> On a small enough mix set even FCMP++ is vulnerable

<boog900> @articmine: 1,024x is extremely dangerous

<ofrnxmr> Fwiw im fully in favor of this > <@boog900> his is 1.4x if there are literally 0 txs

<boog900> Oh but the sanity cap!!!!

<ofrnxmr> Otherwise there's no logical reason to start at 10mb instead of 100kb

<monero.arbo:matrix.org> @articmine: "small"? I'm pretty sure even the lowest proposal is suggesting something like hundreds of thousands of transactions a day

<boog900> @ofrnxmr: What? Its all arbitrary at a certain point, yes that number was got from that proposal but why does that matter at all

<articmine> Then there is quantum computers

<boog900> @articmine: we have already been over this yesterday.

<articmine> I mean I am not wasting my time on this

<boog900> @ofrnxmr: ok, but do you support the rest of the proposal?

<ofrnxmr> im indifferent on the rest of it. In practice, i don't want fees to grow more than 2x on a 1in/2out tx. And would prefer burst speed fees to cost more than current

<ofrnxmr> and i personally think 100 block short term median is too short, but thats more bikeshedding imo

<boog900> yeah, personally I think bitcoin cash has a decent scaling algo, but it would take some work to fit that into Monero and then even more work to get consensus on it. FWIW bitcoin cash allows a max of 2x, compared to mine of 2.5x or 40x, if the ltm is adjusted, or artics 32x or 1024x.

<boog900> Also artic likes bitcoin cash, the last true contender for sound money, am I right?

<ofrnxmr> 1024 = 300mb? (1024 * 300kb?)

<boog900> no its 1024 * whatever the long term median is, which is at least 625kb in the current proposal

<boog900> if we get a steady stream of 10MB blocks and the ltm adjusts up to it, we could be looking at 10 GB blocks in just over a year.

<boog900> pretty crazy IMO.

<articmine> Bitcoin Cash does not have a tail emission so no. If Monero is destroyed there really is nothing left > <@boog900> Also artic likes bitcoin cash, the last true contender for sound money, am I right?

<articmine> If Bitcoin Cash were to stop the halving creating a tail emission then there would hope there.

<boog900> Their scaling algo is more conservative than mine lol

<articmine> As for thier scaling algorithm it is actually very bad because there is no pricing

<articmine> So it is trivial to spam

<articmine> @boog900: Your proposal would actually work well for a mature coin with say 1000 transactions per second, that is not under attack.

<articmine> It is getting there safely that is the issue.

<boog900> yayyy progress

<boog900> It has to be done slow enough so node operators have time to adjust

<boog900> and well software as time to improve

<boog900> has*

<articmine> Yes but aggressive scaling beneath a strict cap is actually way better there, because every one knows what to expect when

<articmine> So predictably is actually vital

<boog900> I mean not really, as in a few years we could have had no growth and then be chucked all the growth in an incredibly short amount of time.

<articmine> That can happen but everyone would know the limits ahead of time

<boog900> and your proposal does not take into account the afer reaching 1000 tx/s, we can't continue to allow growth at the same rate

<boog900> it would be crazy to always allow blocks to increase 1024x in a year

<articmine> That is like how far in the future?

<boog900> 14 years is when the sanity cap stops preventing a years worth of growth

<articmine> Furthermore it would be a one time move

<boog900> but before that it is still always increasing

<ofrnxmr> cant we simplify the scaling to like max 100x penalty free zone (volume) per year, max 16x short term (volume), so that would be max 62mb in year one?

<ofrnxmr> Still restricted by the sanity median

<articmine> In 14 years with no growth then one gets 1000 TOS and.the cap is still 1.4x

<articmine> TPS*

<articmine> Seriously I had been grappling with this for 4 years until Tevador came up with the fixed rate of growth just under Nielsen's Law

<articmine> I was looking at a sanity median with 10^6 blocks

<articmine> The trouble with that is the initial conditions

<articmine> This is on top of the concerns that jeffro256 mentioned to me

<boog900> yeah so if we can handle 1 GB blocks in 14 years that is fine, but can we handle 225 GB in 30 years? This is the problem with the exponential, it is always increasing at a faster rate. Eventually one thing wont keep up. > <@articmine> In 14 years with no growth then one gets 1000 TOS and.the cap is still 1.4x

<boog900> I know a few people think this is so far in the future it is stupid to argue, but if you think that then why can we not just have a more secure scaling algo that behaves the same now and doesn't have this crazy behavior in the future

<articmine> I do

<boog900> you said mine would be fine if we had enough tx/s now, I can't see us needing to scale to that many tx/s in a year.

<boog900> mine would get us there in 5 instead

<boog900> much better IMO

<boog900> well jut

<articmine> The assumption is that Neilsen's Law will hold. If it does great. If it changes then yes we have to make changes

<boog900> You can't assume exponential growth of every Monero bottleneck forever. BIP101 agrees.

<syntheticbird> >"wow" > <@monero.arbo:matrix.org> wow so I'm gone a couple days and AM has resorted to spreading FUD on reddit. I wish I were surprised

<syntheticbird> >is surprised

<syntheticbird> >"I wish I were surprised"

<syntheticbird> >is not surprised

<syntheticbird> chat am i illiterate

<boog900> if this is the disagreement then I think this can be concluded soon, I don't think many people will agree we need a max of 1,024x in a year. > <@articmine> Your proposal would actually work well for a mature coin with say 1000 transactions per second, that is not under attack.

<boog900> like I get wanting to support growth

<boog900> but that would blindside so many node operators who would have very little time to upgrade systems

<boog900> and who says 1,024x is enough?

<boog900> like really it is an arbitrary number that you decided, no one has a magic ball

<syntheticbird> @boog900: 0.6 worked just fine, so what about 0.6x growth

<syntheticbird> oh wait not likethat

<articmine> What you are saying is an edge case 14 years down the road. It assumes no growth in 14 years followed by a 1 year catch up

<articmine> How many HF can we reasonably expect before then while this thing is building up

<boog900> I am not saying no growth, we could grow to 10 MB blocks and have the same things happen but it be 10 GB instead of 1 GB

<boog900> @articmine: yeah see but then you are setting us up for failure, this is my point if we assume we will just fork away from this then why not just choose a good algo now

<articmine> Yes but one still needs 14 years of no gry to move the cap

<boog900> and btw you are preparing the system for this

<boog900> you are the one preparing for 14 years of no growth then 1 GB in a year

<boog900> like what not have a smaller ltm multiplier and make it a smooth increase

<boog900> like mine :p

<boog900> I am just pointing out the issue > <@boog900> and btw you are preparing the system for this

<articmine> The current 5 years since 2021 is wild enough, but 14?

<articmine> In any case I do have to leave

<boog900> exactly so why do we need 1024x surly it should be lower?

<boog900> we aren't going to have 14 years of no growth then get 1 GB in a year so why allow it?

<monero.arbo:matrix.org> @syntheticbird: initial surprise, followed quickly by "of course they did"

<monero.arbo:matrix.org> for real though, it's wild to have a member of "core team" reddit posting about how the devs are being sneaky and nefarious

<monero.arbo:matrix.org> genuinely irresponsible imo

<syntheticbird> @monero.arbo:matrix.org: [removed]

<articmine> @boog900: The factor for a year under my proposal is 512 = 16 x 32. I am capping the block weight as opposed to MS

<boog900> 512x is a bit below a year 1024x is a bit above

<boog900> But that doesn't really answer why you think we need to prepare for 14 years of no growth then GB blocks in a but above a year

<boog900> Bit*

<articmine> One can cap the surge on ML over 5 cycles by capping it to say 128MP where MP is ML 5*10^5 blocks before

<boog900> Yeah but that is just extra complication and gets back to who says this is enough

<boog900> Like its all arbitrary as we don't know if that we be more than or less than the required growth

<articmine> The argument is that this is comparable to the initial surge

<articmine> At the HF

<boog900> We already have a surge factor tho

<boog900> 40x or 47x

<boog900> NGL you already have said this proposal would be fine for an already established coin. I think requiring 5 years worth of growth to get there is fine.

<articmine> No going from our current block weight to 10*10^7 bytes

<articmine> By the way when it comes to the Litecoin surge I use a 43in 4 K monitor to measure it

<articmine> I certainly would not use a smartphone

<articmine> So 47x is too low

<boog900> I have to say I strongly disagree that 47x is too low. 1024x is too low if you look at chains which have had growth more than that, which is literally every chain that has gone from 0 to any txs a year. Again this is arbitrary.

<boog900> I think we are just going to have to disagree here and allow others to make up their mind.

<articmine> A 128x surge in a year is reasonable given our starting conditions and the LTC data

<boog900> Bitcoin cash did analysis of their algo and they found it was enough to support all tx activity across bch ltc btc and ETH

<boog900> And it is more conservative than mine

<articmine> I've what period of time for ramp up?

<articmine> For BCH

<articmine> I believe their stating blocksize is 32 MB

<boog900> gitlab.com/0353F40E/ebaa

<boog900> @articmine: It was using 1 MB in the test

<articmine> It is 32 MB from their definitions

<articmine> Vs 625000 bytes for us

<boog900> No

<boog900> In the test it is 1 MB

<boog900> gitlab.com/0353F40E/ebaa#algorithm-too-slow

<articmine> This is not a valid comparison

<boog900> Yeah because it doesn't enforce your view we need 1024x in a year

<articmine> We should be using their deployed size vs our proposed deployed weight

<boog900> Its a multiplier based on previous usage

<articmine> My view is 128x over just less than a year

<boog900> @boog900: So at best we need a higher start which we will have, the short term growth allows us to get to 10MB

<articmine> Their start is 32 MB

<boog900> Bro

<boog900> > Back-testing the algorithm against hypothetical combined load of 4 major blockchains (BTC + LTC + ETH + BCH), initialized with 1 MB in 2009, shows us that generally it would have been able to accommodate historical growth, without the limit pressing against organic adoption.

<articmine> I don't agree with BCH parameters. I am just reading the Gitlab

<boog900> They demonstrated it is enough though?

<articmine> Now we have the answer I was looking for

<boog900> You could have just looked at the link I sent

<articmine> 17 years

<articmine> I see

<articmine> I did

<boog900> Yes it would have supported all growth over all those years

<boog900> At just its tiny 2 to 4x

<boog900> Like really you would have only liked it if it enforced your view

<articmine> Interestingly mine is 823MB after factoring in the 2 min blocks vs 10 min blocks

<boog900> What?

<articmine> Over 17 years with 1.388x factor from 625000 bytes

<articmine> Their implementation is 32 MB Ours a rise to 10 MB

<articmine> So we are well below

<articmine> Yours is actually higher

<boog900> You can see in their test they get a max block size of 25 MB

<boog900> The 32 was their arbitrary choice

<articmine> The 32 MB was the initial amount for Bitcoin

<boog900> > For Bitcoin Cash (BCH) network, we propose to initialize the algorithm with 32 MB minimum since that is the currently accepted limit,

<boog900> @articmine: Wdym?

<articmine> It was the result of a "bug"

<articmine> Just do the research on Bitcoin

<articmine> I don't have time right now

<boog900> I don't see your point at all

<boog900> Like does the goal post even exist anymore?

<ofrnxmr:xmr.mx> @boog900: Wasnt btc 1mb added later on

<boog900> It was just the test here that used 1 MB from 2009: gitlab.com/0353F40E/ebaa#algorithm-too-slow

<boog900> It doesn't matter the true limits of the coins

<boog900> That experiment shows that algorithm supported all tx activity across the 4 chains

<rucknium> moneroresearch.info is mostly back to normal after an upgrade. Special thanks to @plowsof:matrix.org for help during the upgrade.

<rucknium> Special un-thanks to Certbot. Wrote things into my default NGINX config marked by "managed by Certbot" that slowed down the upgrade.

<rucknium> Certbot has been warned that it's on the list to be managed into the scrap heap.

<rucknium> Bold formatting on the paper titles and the FCMP subcategory don't work yet.