<datahoarder> I commented on it @jeffro256:monero.social but seraphis-migration/monero #250 has similar issues as on seraphis-migration/monero #245

<datahoarder> New changes on #245 converge to the ones in my go implementation as well :)

<articmine> Yes this works as a scaling cap. It is very easy to add to my proposal

<articmine> monero-project/research-lab #155

<articmine> I am referring to the above

<articmine> I have updated my proposal to incorporate the above sanity cap with slightly tighter parameters.

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

<spackle> The (new) sanity limit in this proposal is solely a function of block height. Consensus that the daemon can handle 10 MB blocks will not be sufficient.

<articmine> It is the lower of the adaptive block weight and the sanity limit.

<articmine> That is the point of a sanity limit

<articmine> ... and why it works

<monero.arbo:matrix.org> small note AM for the future commas or exponential notation would keep me from sitting here counting 6 or 7 zeros after a number

<monero.arbo:matrix.org> so in 10 years we're looking at roughly max 250 MB blocks, is that right?

<articmine> Correct

<monero.arbo:matrix.org> I'll keep chewing on it, would love to see some graphs or simulations, but my initial impression is that I find that number spooky but not suicidal

<monero.arbo:matrix.org> which is a notable improvement for sure

<boog900> I am disappointed that this very clearly moves by itself after you were very clear yesterday @articmine:monero.social that it wouldn't.

<boog900> I was correct to be suspicious

<articmine> @boog900: You are ignoring the existing scaling

<articmine> This is a cap

<boog900> No I am not. Do not twist my question

<boog900> Was not*

<boog900> Let me get the logs

<boog900> libera.monerologs.net/monero-research-lounge/20251202#c621117

<monero.arbo:matrix.org> I see what you both mean. AM Is saying block size doesn't go up automatically, boog is pointing out that this particular parameter does go up automatically, yeah?

<articmine> You have to look at the entire equation

<boog900> Very clearly I was talking about specifically the sanity cap

<articmine> @boog900: No I was not

<articmine> I meant the block weight

<boog900> To try and twist my question to mislead people is very disappointing

<spackle> We are having a communication issue but that is fine. In less than two years, this proposal will allow for 16 MB blocks to be generated from flooding at almost any time.

<articmine> @spackle: No

<boog900> @articmine: Yes you were not but I clearly was

<monero.arbo:matrix.org> What was the penalty free zone in 2015 when XMR launched? if it was 100 kB that would imply 25 MB now using AM's formula

<monero.arbo:matrix.org> in case that's a helpful reference for anyone, it helps me to think about it, thinking backwards instead of forwards

<articmine> @spackle: There is a cost

<monero.arbo:matrix.org> we know there is a cost but that doesn't mean it can't be "at almost any time"

<spackle> @articmine: As discussed earlier, I am not interested in making a short term network breaking expensive, I am interested in preventing it entirely.

<spackle> Short term again, meaning without moving the long term median.

<articmine> @spackle: This has at been the case

<spackle> Anyway, I trust readers to understand my meaning.

<articmine> You either want peer to peer cash or not

<articmine> Yes we have to deal with BS suppression of Monero

<monero.arbo:matrix.org> @articmine: a global peer to peer cash network will need a Level 2, you can't just sidestep the blockchain trilemme with scaling

<articmine> @monero.arbo:matrix.org: No it does not

<monero.arbo:matrix.org> sure, recording every transaction on the planet forever makes sense :/

<monerobull:matrix.org> how many transactions is 32mb

<articmine> 32 transactions per second

<boog900> This is effectively a block size bomb and I will not support it over a proper limit that moves with sufficient activity.

<articmine> I am not wasting any more time on this

<monerobull:matrix.org> @articmine: right now we are at 100 times less than that

<articmine> Correct

<ofrnxmr:xmr.mx> @boog900: I'd have to disagree here, as that would also imply that we shouldnt allow 10.8mb (as we didnt have the volume last yr to reach 7mb etc)

<monero.arbo:matrix.org> it's not that we shouldn't allow it, I think they're saying it should require activity to scale the long term growth as well

<articmine> I can see the BS conflict of interest behind the scenes here

<monero.arbo:matrix.org> I know, it's the lesser of the two parameters, but the conversation is about whether both shoudl take TX volume to scale

<articmine> This is what this is really about

<spackle> Please be specific of whom you are accusing, and of what exactly you are accusing them.

<articmine> Those who fear peer to peer cash

<monerobull:matrix.org> we dont need more than 100 times the current throughput for a long time but setting a hard limit could spiral into bitcoin-style blocksize wars if it ever gets close to the limit

<articmine> @monerobull:matrix.org: If course

<articmine> If course

<ofrnxmr:xmr.mx> We're probably having that war rn

<spackle> Agreed, I also oppose the 32 MB hard limit proposal.

<monerobull:matrix.org> can we time-lock it

<spackle> We can do anything we agree on

<monerobull:matrix.org> put some dynamic scaling on it that only activates after 5 years?

<monerobull:matrix.org> that would prevent a war later on

<ofrnxmr:xmr.mx> 10.8mb this yr is 15mb next yr, 21mb in 2027, 29mb is 2028 etc (using 1.4)

<monerobull:matrix.org> because we are not hard-locked into a specific limit

<articmine> @monerobull:matrix.org: It is the same issue. One can allow growth or not. One cannot do both

<ofrnxmr:xmr.mx> Is 10.8mb is acceptable right now, i see no reason to assume that 29mb wont be equally as feasible in 2028

<ofrnxmr:xmr.mx> If* 10.8

<monero.arbo:matrix.org> @ofrnxmr:xmr.mx: I don't think compute is growing that fast...

<monerobull:matrix.org> @articmine: one can have limits based on reality

<ofrnxmr:xmr.mx> Other proposals on the table are to allow near 100mb's this year, 32mb hard cap, or starting st 16mb. All of those can be hit before 2028

<monero.arbo:matrix.org> was 3 MB the limit in 2022?

<ofrnxmr:xmr.mx> @monerobull:matrix.org: This IS based on reality

<monerobull:matrix.org> if you have zero limits you end up like BTCSV

<ofrnxmr:xmr.mx> @monero.arbo:matrix.org: No, it was virtually unlimited

<ofrnxmr:xmr.mx> @monerobull:matrix.org: Youre not paying attention. There are limits. 1.4x per year

<articmine> They have demonstrated 4 GB blocks 3 years ago

<monero.arbo:matrix.org> @ofrnxmr:xmr.mx: I meant hypothetically, in terms of like a max viable number. If we're saying we can go from 10.8 to 30 in 3 years, then that implies the number 3 years ago would have been ~3

<monero.arbo:matrix.org> again I find it easier to think about these things by projecting backwards because we KNOW what tech was like then

<ofrnxmr:xmr.mx> @monero.arbo:matrix.org: could have been* and yea, 3 years ago we could have handled 3mb

<articmine> @monero.arbo:matrix.org: You mean like 2MB in 1979?

<monero.arbo:matrix.org> I feel like 3 years ago we could have handled more than 3, probably over 5, which to me implies a slower rate of growth

<monero.arbo:matrix.org> @articmine: I've seen you say stuff like this a couple times now but I think we all know growth is slowing, and not just because of technical hurdles. transistors are already down to the size of a few atoms. going much further will require more than just shrinking the die

<ofrnxmr:xmr.mx> @monero.arbo:matrix.org: Tevadors numers are below neilsons law of 1.5, so the numbera are below what they would otherwise be

<spackle> @ofrnxmr:xmr.mx: Are you confirming that the network can handle a steady stream of blocks that are 10MB (increasing to 16 MB within 2 years)?

<ofrnxmr:xmr.mx> @spackle: That is what i am implying, yes

<monero.arbo:matrix.org> @ofrnxmr:xmr.mx: ah well my concern from the start has been more about compute than bandwidth

<spackle> Are you comfortable saying it directly?

<spackle> That would be an important moment. As of now, I am not aware of any person who has confirmed the daemon is capable of that.

<articmine> We will need to split the chain like Bitcoin. Only in this case the fork is the small block supporterd

<ofrnxmr:xmr.mx> The master daemon has a couple bugfixes to be upstreamed, but with these bug fixes, yes monerod can handle 16 mb today

<articmine> I also recommend Roger Vet's book. Highjacking Bitcoin

<articmine> Roger Ver

<spackle> To be clear, I don't mean a single block. I mean a steady stream of 16 MB blocks.

<boog900> I did say sufficient activity, if we want to grow 10x in the short term, sure, but this proposal will have us scale so effectively there is no sanity limit even with no extra activity > <@ofrnxmr:xmr.mx> I'd have to disagree here, as that would also imply that we shouldnt allow 10.8mb (as we didnt have the volume last yr to reach 7mb etc)

<ofrnxmr:xmr.mx> @spackle: Yeah, same

<articmine> @boog900: The issue here is the suppression of Monero by BS lobbying . We have to catch up once the VS companies are out in their place by the courts

<monero.arbo:matrix.org> @boog900: yeah raising M_L from 1.7x to 2x does allow very fast growth within these bounds, for sure

<articmine> BS companies

<articmine> @monero.arbo:matrix.org: That is the point

<monero.arbo:matrix.org> I mean yes it is your point but I also udnerstand the concern

<articmine> Then why fight this proposal?

<articmine> The fact is that Monero has been suppressed for close to a decade. So has Bitcoin and I also suspect Ethereum

<monero.arbo:matrix.org> I did say it's better but doesn't mean I'm giving uncritical support, why would it

<ofrnxmr:xmr.mx> @monero.arbo:matrix.org: I think there should still be a cap of 1.4x the cap of 262800 blocks prior

<monero.arbo:matrix.org> @ofrnxmr:xmr.mx: those are the "bounds" I meant

<articmine> @ofrnxmr:xmr.mx: Then you hard code the BS suppression into the consensus

<monero.arbo:matrix.org> Idk like I said it would be nice to see some graphs or something, it's hard to just stare at equations and go "oh okay that looks good"

<monero.arbo:matrix.org> @articmine: bruh

<monero.arbo:matrix.org> 1.4x growth per year is generous

<ofrnxmr:xmr.mx> @articmine: Not a cap of the median, a cap of the neilsons law cap. So if that is 10.8mb right now, then 1 year from now that should be automaticly adjusted to 15.12

<articmine> @monero.arbo:matrix.org: Not after 10 years of suppression

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: ^

<ofrnxmr:xmr.mx> Suppression doesnt matter if the cap grows regardless of activity

<articmine> @ofrnxmr:xmr.mx: It allows catching up

<monero.arbo:matrix.org> @articmine: I'm talking about for our capabilities. If we think ~11MB blocks are about what we can handle now, increasing that number by 40% year over year is extremely generous

<monero.arbo:matrix.org> providing more capacity than the network can handle helps preciciely nobody except people who want to see Monero fail

<articmine> It actually is not

<articmine> Realistically we need a chain split

<monero.arbo:matrix.org> whatever, I've got stuff to do today. I am once again getting tired of AM trying to bully the majority of the community on this

<monero.arbo:matrix.org> and now he keeps proposing chain splits

<monero.arbo:matrix.org> while calling OTHERS the destructive ones

<monero.arbo:matrix.org> go split the chain then bro

<articmine> It will happen. It happened in Bitcoin

<articmine> I got.out before it happened in Bitcoin.

<articmine> I saw it coming

<articmine> Unfortunately I also see it here.

<articmine> 😂

<boog900> @ofrnxmr:xmr.mx: in the sort term the exponential growth is fine, but it will get out of hand. Even if bandwidth grows that much CPU power and our ability to use it might not.We can say this will happen far enough in the future it doesn't matter but it is still a bomb.

<articmine> I will NOT split this chain but I do not believe a split can be stopped

at the end tevador's issue referenced by AM monero-project/research-lab #155 he states ....

Verification time constraints

The exact same formulas I used to derive the natural block size cap can be used to derive a block verification time cap. Instead of the median download speed, the formula would use the median CPU performance and its annual growth rate.

is this being taken into account?

and as far as being for or against p2p cash, without a functioning network you can't have it

in my mind the #1 thing that sets monero apart is that it is fungible, this it what is supposed to make BS companies useless. Are all our privacy features useless against BS?

ofc we need a certain # of txs, the question is how many? Transparent chain vs Monero

*Monero with FCMP++

<spackle> On the note of verification time, @ofrnxmr:xmr.mx I would like to examine your claim that the network can handle 16 MB blocks being produced steady state. At the last meeting it was mentioned that verifying a 16 MB block might take 93 seconds on a single thread. That would mean a miner needs to have a direct connection to the [... too long, see mrelay.p2pool.observer/e/3-ag8M4KUDhNcTU1 ]

<spackle> Does what I just wrote seem incorrect to you?

<ofrnxmr> Blocks should be over 10mb in a couple hrs and you'll be able to see for yourself

<spackle> I don't feel you've answered my question, or addressed the point I was making. Of course that is your prerogative if you don't wish to, but I was hoping that you might.

<ofrnxmr> Afaik, you dont reverify txs that are in blocks

<ofrnxmr> it might take 93 seconds for a single threaded device to verify a a 16mb block where they have not seen a of the txs yet

<ofrnxmr> But the (fluffy)block itself is not 16mb

<spackle> If a node is receiving the transactions that will constitute a 16 MB at steady state, they will need to verify all the transactions in a block at some point in time, no?

<spackle> Meaning that the will need to verify transactions at the rate of block production.

<ofrnxmr> single threaded node would take 93 seconds even if the block is never mined - they verify txs in the pool

<spackle> Yes, and it follows that they will need to verify txs in the pool at the rate of block production. Does it not?

<ofrnxmr> Are we assuming a txpool that grows at 16mb / 120seconds? If so, sure

<articmine> nioc: Is the current Monero more private than Pirate Chain? This is a valid question.

<ofrnxmr> If the txpool grows at 32mb/120seconds, no. They have to verify 32mb/120seconds

<spackle> That would seem be a requirement of producing a steady stream of 16MB blocks.

<ofrnxmr> @spackle: A minimum* requirement

<ofrnxmr> Theres nothing stopping txs from being produced at 40mb per minute (as an example)

<spackle> I am glad we agree. So returning to the point at hand, a node might need to spend, at minimum, 93/120 seconds on verification.

<spackle> It follows that this node can spent, at maximum, 27/120 seconds on actual mining.

<ofrnxmr> A single threaded* node

<spackle> Yes

<ofrnxmr> Mining on monerod is paused while adding blocks to the the chain, but i don't think its paused while verifying txs

<ofrnxmr> You just wouldnt include txs that arent verified in the template

^ if mining via xmrig or p2pool the miners keep mining

using the old template, as monerod has not published a new one

or not even template, has not published new miner data

<spackle> I see your point.

there is no "stop the miners" message on stratum, at best you can close the connection so they stop working, but them reconnecting to it can take a few seconds once you open it

that caused already quite a few diverging forks in stressnet as well

at some point it was ~25s before new miner data was ready on a 9900X3D locally

<ofrnxmr> Yeah i think that was fixed by relaying empty fluffyblock (?)

this has improved in recent versions, but it's still a major part of wasted proof of work during large blocks

<ofrnxmr> otherwise the nodes disconnected from one another

the issue is local ofrnxmr

like, even if not connected to network, the templates take quite long to verify

specially when monero itself provided the valid txs already to be used

<ofrnxmr> Ive been mining with xmrig without issue for a while now. I had a lot of issues on older versions of stressnet

you find no issues, just "delays"

see when xmrig finds a share

and when it receives a new job

<ofrnxmr> I mean, on older versions monerod would return bad data while it was broadcasting the block

yeah on ZMQ it just sent nothing, it wasn't even RPC polling

<ofrnxmr> Hasnt happened in quite a few weeks now

<ofrnxmr> Which would lead to me mining invalid or rejected shares

<ofrnxmr> I mean, on older versions monerod would return bad data while it was broadcasting the block

<ofrnxmr> (fwiw, i think im just using rpc)

it uses rpc indeed

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

<sgp_> this does indeed add some sanity to the proposal. It's slightly less than 40% max growth rate per year (38.89%) if my math is right. It's just super annoying to me that it took weeks of bickering that the old version was totally fine, and that I only wanted to remove the explosive growth because I want Monero to fail, when the prior proposal had obvious issues.

<sgp_> I still don't like the way the fee market is handled, but at least the proposal probably won't kill Monero anymore

<articmine> How old are single thread processors? > <@ofrnxmr> A single threaded* node

<ofrnxmr> Like 2002? Lol

<articmine> Seriously

<ofrnxmr> Probably older actually, i think we had dual core processors before y2k

<ofrnxmr> Anyway, single threaded numbers are only good for "per thread" analysis. So 16mb per thread is still possible, but would increase time til confirmation by 93 seconds iiuc

<ofrnxmr> these numbers also would imply that a 16 thread system would take 93 seconds to verify 256mb

<spackle> My thought was that single threaded performance was worth discussing because daemon multi-threading was limited in both scope and performance. If that has changed I am delighted to hear it.

<ofrnxmr> Monero's multithreading has a very silly default config of 4 threads

<ofrnxmr> Changing this to max threads increases sync speed by 40-70%

<ofrnxmr> Running single threaded is much slower than 4 threads, as evidenced by @mayhem69:matrix.org 1vcpu 2gb ram tests. I also tested and can confirm that 1 thread is much slower than 4

<boog900> @ofrnxmr: its not just that, monero takes locks in places too, like when adding a tx to the pool

<ofrnxmr> This is without checkpoints and im not sure if it effects tip/tx syncing, or if its only relevant for syncing batch txs / blocks

<boog900> @boog900: changing this is going to be harder as you need to make sure data stays in sync

<ofrnxmr> @boog900: My main point is that "catch-up" sync or ibd w/o checkpoints is much faster with more threads

<articmine> @spackle: I have been arguing this for years. It is not an excuse to throttle scaling

<jbabb:cypherstack.com> Has block size been an actual limit to transaction throughput yet?

<boog900> scaling has only been activated like once during the last spam wave

<boog900> even then it didn't even really move

<boog900> @articmine: Its a bottleneck, just like every other bottleneck. Until it is fixed we should not ignore it.

<rucknium> AFAIK, FCMP can also do batch verification if you have all the txs together, like in initial block download. I don't know how much that speeds up the processing. The numbers I quoted are for single txs as they arrive in the txpool AFAIK, where you cannot easily perform batch verification.

<ofrnxmr> Fwiw, theres currently 112k txs in the pool

<rucknium> Stressnet? My nodes with default txpool size are showing 60K txs. So there are a lot more txs out there is non-default txpools.

<ofrnxmr:xmr.mx> Yeah, my explorer node has a 3gb limit

<boog900> During that last spam the locks was causing issues with public nodes, that was never fixed right?

<boog900> We didn't even have that big of blocks then too, just over the current median IIRC

<articmine> @boog900: Which is why it needs to be fixed. What I cannot support is to ignore it and then try to hide it by preventing people from using Monero

<boog900> Yes but we have already been over this. The scaling is dangerous _now_, we need to plan for what we can handle _now_.

<boog900> The amount of throughput we can handle will not scale perfectly with the number of threads. We don't know how much a fix increasing parallel processing would give us.

<jbabb:cypherstack.com> Can we mitigate the effects of key image / input reuse across blockchain forks? > <@articmine> I will NOT split this chain but I do not believe a split can be stopped

<jbabb:cypherstack.com> The most famous result of a big block split shows a dismal future for the minority chain:

<jbabb:cypherstack.com> bitinfocharts.com/comparison/bitcoin%20cash-transactions.html#alltime

<jbabb:cypherstack.com> bitinfocharts.com/comparison/bitcoin-transactions.html#alltime

<jbabb:cypherstack.com> the implications for our current privacy protocol are more dire: splits for Monero in its current state would threaten to degrade the privacy that's the bedrock of Monero's use case.

<jbabb:cypherstack.com> the problem, frankly, is not that there are too many real-world people wanting to use the protocol and the block sizes are just too small such that they're suppressing usage and restricting access--at least, I don't see proof for that

<articmine> @jbabb:cypherstack.com: No the problem is that the blockchain surveillance companies have lobbied governments all over the world to de list Monero from exchanges.

<articmine> This prevents and frustrates people from using Monero. When the lobbying hit Canada I know of people who were forced to sell their XMR.

<articmine> The Monero community has valiantly responded to this attack by promoting de centralized exchanges.[... more lines follow, see mrelay.p2pool.observer/e/zvKz9c4KUC1oTzFa ]

<ofrnxmr> Delistings are proof enough that usage is heavily surpressed

<ofrnxmr> An example for canada: coincards operates out of canada and still accepts xmr but charges ~3% extra because they have to swap it out on trocador etc

<jbabb:cypherstack.com> re: delistings, we can't have our cake and eat it too.

<jbabb:cypherstack.com> that is, if we provide true privacy, it should be a foregone conclusion that sans political organizing, most nation states will ban true privacy.

<ofrnxmr> If all cexes delist monero, businesses which accept monero would have a hard time doing so, as they need a liquid way to convert monero into money that they can use to pay bills in

<ofrnxmr> I'm not "pro cex", but delisting are probably the easiest way to stifle adoption

<jbabb:cypherstack.com> OK, I see how that sort of political suppression does contribute to the claimed technical suppression--that because it's made illegal in certain ways and in certain places, less real world people want access to the shared block space

<jbabb:cypherstack.com> but raising the block size wouldn't reverse those ultimately political problems

<jbabb:cypherstack.com> it's a technical solution for a political problem and I don't see how it would lead to increased usage in and of itself

<ofrnxmr> Were technically adding a block size cap.

<jbabb:cypherstack.com> technical solutions would include bridging XMR to other chains so we can let users route around political barriers

<ofrnxmr> these proposals dont increase scaling, they all throttle it back and latest one puts a cap ln the max growth per yr

<ofrnxmr> (editing spams irc)

<ofrnxmr> Instead of being abke to reach 30mb blocks in 20hrs, the latest proposal maxes out at 10.8mb

<boog900> Only in the first year

<ofrnxmr> yeah, 40% growth per year

<ofrnxmr> in contrast to.. what 500mb in yr 1 currently?

<boog900> Yeah a lot better but we should not settle for what article agrees to if we can do better

<boog900> Artic*

<ofrnxmr> Kayabas proposal is to add 32mb cap (which would put us in 2028 or 2029)

<ofrnxmr> other proposals call for immediate cap of 16-32mb and max up to ~100mb

<gingeropolous> i am against the idea of a hard cap. it should always be dynamic in some regard

<spackle> I agree, and I think the vast majority of the community does as well.

<boog900> We can reduce the long term growth rate to 1.4x a year and then we move at the same rate but only when there is usage

<ofrnxmr> If we cant scale to 32, 48, 64 mb in '28 29 30, then we just soft fork to limit it further, no? Thats 3,4,5years out

<boog900> There are infinite options

<boog900> @ofrnxmr: Yeah but I would rather have a good algo now than code in a block bomb

<gingeropolous> indeed.

<ofrnxmr> i think agreeing to start at 10.8, 16, 32 etx mb is already inline with the block bomb

<gingeropolous> as a sanity limit? because it doesn't get to 10.8 for free

<ofrnxmr> And theres no reason to assume that, if this proposal was made in 2026, that we wouldnt start at 15mb

<ofrnxmr> @gingeropolous: Yes

<boog900> @ofrnxmr: It gets harder to predict the more years you try look ahead. Even if you support this, why add all this complication to an already complicated system

<gingeropolous> i mean, its no more complicated than what we already heave (the double median). It just adds a third, final cap.

<boog900> Its the change of the algorithms for the original proposal that allows gigabyte blocks in a year too

<gingeropolous> yeah, the 50x changed to 16x?

<boog900> And the 1.7 to 2

<boog900> And the calculation of the block limit

<boog900> Its not just 2x the median in the gigabyte proposal

<boog900> Why make all these changes to satisfy artic?

16:39:09 <datahoarder> The conflict of interest here is delaying FCMP++ due to scaling issues which would already cover the part of breaking surveillance for rings, so that must be prioritized. Adding sanity scaling parameters/adjustments so that can exist happily with current implementations can speed the process of deploying this in an agreeable

way and stopping BS

18:12:35 <articmine> There may be a case to defer FCMP++ until we obtain these proofs

<datahoarder> it got shuffled around, but ^ delaying FCMP++ is a -- given previous BS statements. FCMP++ actively deals with BS so I can't understand how ArticMine wants to give BS more power for longer

if anything the improvements listed open the way for another hardfork for the areas which require one

<ofrnxmr:xmr.mx> @boog900: I'm mostly in aggreeance with the 40% yearly growth of the sanity cap, but the other changes i cant say i understand why they are the way they are

<gingeropolous> yeah me neither. the existing parameters allowed for pretty expansive growth

<datahoarder> not on new bridge, which doesn't pass the edits at the moment (I'm trying to make a regex finder for small edits, or post link to edits, which always include the latest version) > <@ofrnxmr> (editing spams irc)

<boog900> I think the 40% is probably fine for 5 or so years, after that 🤷‍♂️ after 15 its pretty much not there.

<ofrnxmr:xmr.mx> Well, in 5yrs monero will also be 40% older

<ofrnxmr:xmr.mx> .. :P

<boog900> I doubt we will have the performance improvements required to keep up with the exponential growth

<ofrnxmr:xmr.mx> And 5yrs is "only" 58mb

<ofrnxmr:xmr.mx> i personally think 5yrs is plenty lf lead-in to figure that out and modify if necessary

<ofrnxmr:xmr.mx> The last hard fork was 2022, just 3yrs ago

<boog900> Why not just set a hard limit in that case, we can remove it once we know we can handle it

<boog900> Instead of exponential growth, exponential growth to a point which we the HF to remove if we can handle it

<ofrnxmr:xmr.mx> Exponential growth to 99mb?

<ofrnxmr:xmr.mx> Since we, at min, need to remove the packet size limit before we can scale above it

<ofrnxmr:xmr.mx> I also want to see if the serialization causes single blocks to break stressnet at ~30mb. Spamming now for that 🙃

<boog900> @ofrnxmr:xmr.mx: It depends on the size of the txs too as it was the string limit that was hit IIRC

<ofrnxmr> i honestly dont remember. Might be documented on one if the prs to increase the limits

Micron stops making consumer-directed memory (ram) and SSD chips

they will be solely dedicated on AI and server-grade ones now.

there goes one major vendor less...

so SSD + HDD seems to be in the future :)

<elongated:matrix.org> With cloud based storage accessible, high storage consumers ssd will be a niche in near future ?