My take on block size scaling: monero-project/research-lab #155

<sgp_> I included tevador's numbers for my scaling proposal, and I also included some potential mechanisms for not growing the flex space if demand does not justify (instead of always growing it). This is challenging to do well, so I'm very open to suggestions! monero-project/research-lab #152#issuecomment-3602637932

On getmonero.org/resources/research-lab maybe the "UNPUBLISHED: Understanding ge_fromfe_frombytes_vartime" section can link to documented versions? monero-project/research-lab #142 monero-oxide/monero-oxide #33

<articmine> Tevador's concept makes a lot of sense as a sanity check on my proposal.

<articmine> I do have concerns regarding some of the conclusions.

<articmine> 1) Two data points using different methodologies do not justify changing the growth rate of Nielsen's Law to 1.4 from 1.5. What this does independently show is that Neilsen's Law is reasonable.[... more lines follow, see mrelay.p2pool.observer/e/rofvys4KQ0tuRS1z ]

<articmine> I will most certainly be incorporating the concept into my proposal with a 1.5 Neilsen's Law growth factor and a base rate between 10 Mbps and 100 Mbps.

<gingeropolous> the 10 MB cap with 40% annual growth gives us a max blocksize of 206MB in 10 years, 5GB in 20 years, 168GB in 30 years.. and we hit 1GB in 36 years. I think thats plenty of room.....

<gingeropolous> sorry, 1 TB in 26 years

<gingeropolous> 36 years. blargh

<boog900> IMO we should not have exponential growth without any extra demand

<sgp_> @boog900:monero.social: I would love for you to take a sec to read this and let me know what you think: monero-project/research-lab #152#issuecomment-3602637932

<articmine> In 1979 I wrote a program that needed 2 MB of memory from the University of BC mainframe computer to solve a differential equation. I got a too much memory error. I had to optimize my program to get it below the 2MB limit. Had to re punch a number of punch cards. It worked.

<articmine> Scaling this to today using at 50% a yes I get 111 Terabytes of memory. The largest supercomputer has about 5 Petabytes of RAM today. So yes this 50% rate of growth has stood the test of time.

<gingeropolous> @boog900: the adaptive blocksize would still be in effect.

<boog900> @gingeropolous: which one? the one that allows GB blocks in a year?

<gingeropolous> well whatever one. but now it has a hard cap (the grows over time). so it wouldn't get to GB blocks in one year

<boog900> yeah but in 20 years the limit is 5 GB so it'll only take 1 years worth of spam to reach the limit. Yes this is better than current, but still not ideal.

<articmine> It is true that the numbers that Trevador has proposed are reasonable. I just we should really stick to what the time tested data has shown

<sgp_> I personally didn't take tevador's proposal to mean the size would increase 40%, but instead that it was setting a max increase bound

<ofrnxmr:xmr.mx> I read it as would, otherwise why start at 10mb instead of 300kb?

<gingeropolous> "With an average block time of 120 seconds, we get a block size cap of 10.8 MB, growing by 40% per year, or roughly doubling every 2 years."

<boog900> either way artic is talking about a limit that increases no matter what

<gingeropolous> its a cap. so the adaptive could grow up to that cap if needed

<articmine> We are after all talking about a sanity cap.

<articmine> On the of a highly priced scaling algorithm.

<articmine> On top of

<sgp_> the proposal mentions the short-term median, so that suggests it would allow a pretty rapid growth to the max cap if demand (incl. spam) pushed it up

<articmine> Anyway I have to work on my proposal.

<sgp_> ah, so your criticism @boog900:monero.social is that if there are e.g. 3 years of blocks that are empty, the protocol would allow >40% increase from year 3 to 4? Something like 380% inn that year to "catch up" to the max?

<boog900> yeah the "sanity limit" is always increasing, eventually it'll be so big it is effectively not there.

<boog900> even with no extra activity

<sgp_> Fwiw I agree with you but ArticMine sees that as an advantage. My guess it that people are split on that

<ofrnxmr:xmr.mx> But that should be "priced in", meaning (ideally) monerod, networking, hardware etc should be able to handle it by then

<boog900> 168 GB blocks? > <@gingeropolous> the 10 MB cap with 40% annual growth gives us a max blocksize of 206MB in 10 years, 5GB in 20 years, 168GB in 30 years.. and we hit 1GB in 36 years. I think thats plenty of room.....

<boog900> yes that is 30 years so like it doesn't matter that much, but this is pretty much a block size bomb

<ofrnxmr:xmr.mx> But the bomb at that point in time should be negligible

<kayabanerve:matrix.org> Fixed 32 MB limit with dynamic scaling up to there would never do that to you /s

<ofrnxmr:xmr.mx> meaning, if we ballooned up to 10.8mbs today, we SHOULD be able to handle it

<kayabanerve:matrix.org> I would appreciate scaling with use more than no matter what as @boog900:monero.social: identified. That maintains feedback from real-world throughput and does let miners consciously influence the limit.

<boog900> 7 years will take us above 100 MB blocks in a year, hopefully we have the packet limit fixed and are able to handle all those FCMPs by then.

<boog900> sorry 8*

<ofrnxmr:xmr.mx> Monero is 11 yrs old, i'd hope we can handle 100mb blocks in 8 more years

<kayabanerve:matrix.org> But 40% for the next n years, where n is defined, isn't something I'd hate

<boog900> @ofrnxmr:xmr.mx: hopefully 🙏

<ofrnxmr:xmr.mx> meaning, if we ballooned up to 10.8mbs today, we SHOULD be able to handle it <<>> 3TB a year ?

<sgp_> 236 TB of max blockchain space in 10 years is quite a bit fwiw

*3TB this year

<sgp_> We're not even at 1 TB total after a decade

<ofrnxmr:xmr.mx> the size of the blockchain is something thatbwe obv have to work on

<ofrnxmr:xmr.mx> Whether that be using ssd cache and hdd archive, more aggresive pruning, or something else

<sgp_> yeah 3TB today is a non-trivial cost. Not insane, but non-trivial

<sgp_> Which is probably exactly what the proposal is going for

<sgp_> A cheap 4 TB ssd is roughly $250 today. $100 for hdd. So roughly that in new storage costs per year

<articmine> @sgp_: ... and to fill this up with on chain peer to peer transactions what do you think the price of Monero in terms of say 2025 USD will have to be?

<boog900> nioc: That's just the block and tx blobs as well. You would need to around 1.5x that for the full db

<sgp_> @articmine: Unknowable

<articmine> Lower bound?

<sgp_> Lower bound is essentially $0 in fees

<sgp_> Except for the block reward penalty I guess, depending how you calculate it

<articmine> @sgp_: Fees have nothing to do with this

<articmine> We are not talking about spam

<sgp_> Bitcoin shows there isn't necessarily a relationship between XMR/USD and transaction volume

<sgp_> So unknowable

<articmine> I am talking about peer to peer electronic cash transactions. Speculation on centralized ledgers is unknowable and ON TOP of that.

<sgp_> I find it completely unrealistic to try to correlate the price of XMR with on chain transaction volume

<sgp_> I believe there is nearly 0 relation, certainly not a predictable one

<articmine> @sgp_: I find it unreasonable to ignore the impact of peer to peer cash

<sgp_> Yeah but how the hell do you quantify the price impact to XMR/USD

<sgp_> Anyway I think this discussion doesn't really matter

<articmine> @sgp_: That makes sense if one does not believe in peer to peer cash transactions

<articmine> What is the point of cryptocurrency anyway?

<sgp_> A wire transfer that moves an average of 4 million USD will have more economic value than my bus fare of $2. All transactions aren't made equal relative to the XMR/USD price. Assuming they are related is unsubstantiated

<articmine> What is the value proposition for Monero vs fiat card payments?

<articmine> We have to start with the basics here.

<sgp_> I'd rather just... not. I don't want to talk in circles about ultimately nothing

<articmine> @sgp_: Where we disagree is the fundamentals

<sgp_> Yes

<articmine> I actually agree with Warren Buffett's assessment of Bitcoin. I believe he got the exponent for the "Rat Poison" wrong. It is was too low

<articmine> This exponent scales with Neilsen's Law

<articmine> Again what is the value proposition of Monero?

<boog900> IMO if you believe tx volume is enough for privacy and you want a crypto that can scale to the world ASAP, you don't want Monero.

<articmine> @boog900: Why has the market valued Monero over ZCash and Pirate Chain?

<boog900> I don't see your point

<sgp_> Why does Solana have more transactions but a lower market cap than Bitcoin. These aren't predicably correlated. Period.

<articmine> @boog900: My point is that the size of the mix set is critical for privacy

<sgp_> if I spem XMR transactions the price of

<articmine> @sgp_: I am not talking about spam

<sgp_> my point is that the impact is unknowable, as demonstrated through those basic examples

<boog900> @articmine: I still don't see how that is related to my original point lol

<articmine> @sgp_: Because Solana has a use case. Bitcoin is becoming selling to the greatest fool. The candidate for greatest fool is Uncle Sam

<sgp_> you're just describing that the market is irrational. hence unknowable

<articmine> @sgp_: In the long term fundamental value wins in the market. That is why Warren Buffett made billions

<rucknium> Here is yet another scaling algorithm, from Bitcoin Cash: gitlab.com/0353F40E/ebaa#technical-description

<articmine> Bitcoin Cash has no pricing for scaling. That is my main concern with their approach

<articmine> Their algorithm is a very interesting otherwise

<articmine> If Bitcoin Cash had a tail emission it would become a very viable option

<articmine> @boog900: There is a very good argument for drowning the BS companies in Ether. So yes a very good case can be made for privacy by size alone. Especially in a post quantum world.

<articmine> The reality is that Monero today has the best scaling, and the reality of technological change makes the ' burden of privacy' irrelevant in the long term

<articmine> So one can be a Monero maximalism and not care about privacy

<boog900> @articmine: you can create a monero clone with exactly the same scaling rules but much smaller txs with no privacy features

do all of our privacy mean little?

I remember when 1 hop was enough :D

^^for btc

<articmine> nioc: I can become a balancing act. Realistically I believe we can have the best of both worlds.

<articmine> It is a myth that BS works on BTC. This by the way is before the courts

<articmine> @boog900: I hope this does not become necessary

<articmine> A non privacy Monero ledger fork?

<boog900> @articmine:monero.social: I don't see why you wouldn't want that, it would make your scaling much more achievable

<testtank:matrix.org> mrelay.p2pool.observer/m/matrix.org/tsZVRwZotmNUNixOxkelBZSj.jpeg (IMG_3240.jpeg)

<testtank:matrix.org> @articmine: .

<articmine> @boog900: I believe that there is a big difference between extreme sanity limits and the actual reality

<articmine> The key to an adaptive blocksize is that one prices scaling. This has worked very well in Monero. Why was ZCash spammed to 300x their blocksize while with Monero spammers gave up in frustration once they just touched the penalty?

<boog900> we have been over this so many times

<articmine> What would have happened to Monero with a 300x increase in blocksize via spam?

<articmine> I am staying loyal to the original Monero social covenant, as opposed to making drastic changes.

<articmine> This begs the question why not fork Monero and create a Bitcoin style ultra small block coin?

<articmine> Then let the community choose which fork to support.

<boog900> you fundamentally believe monero's privacy is unimportant. Stop pretending that anyone who disagrees with you wants bitcoin style ultra small blocks.

<boog900> Monero's social contract does not require dangerous scaling. If it does we are breaking it anyway as we can't support scaling to the dangerously numbers you decided in the past.

<articmine> @boog900: I did not change the scaling to make it dangerous. This is simply not true. What I did is agree to certain limits on scaling which have for the most part have been proven irrelevant by the market.

<boog900> You argued for increasing the limits at the last HF.

<articmine> @boog900: Limits that I had designed my proposal.

<articmine> Like a year before

<boog900> exactly

<articmine> The original scaling had no long term median, and has been proven to work.

<articmine> The so called big bag attack never happened. It is just theory.

<articmine> Big Bang

<boog900> just because an attack hasn't happened doesn't mean it might not be a real attack.

<boog900> again we have already gone over this

<articmine> In any case, I am perfectly fine with a long term Neilsen's Law 50% increase cap per year. Which is way below all of the arguments about whether the long term median is 2x, 1.7x 1.2x etc

<boog900> yes or no, does the increase happen without any extra on-chain activity?

<articmine> NO

<boog900> your 50% cap?

<articmine> NO

<boog900> I am suspicious but I will wait for the proposal

<articmine> Good

<boog900> I don't see why you don't just change the long term multiplier in that case

<sgp_> @boog900:monero.social sorry if I missed your answer but what do you think about these methods to only grow if there's demand? Particularly idea 2. It's really difficult to get it right in practice

<sgp_> monero-project/research-lab #152#issuecomment-3602637932

<articmine> The 50% is a cap on top of my existing proposal which requires on chain activity. The actual cap is THE LOWER OF THE 2 > <@boog900> yes or no, does the increase happen without any extra on-chain activity?

<articmine> @sgp_: By it self an actual disaster for spam for starters

<boog900> @articmine: but if the 50% cap also requires sufficient on chain activity to move I don't see why you don't just change the long term multiplier

<articmine> @boog900: Because you get much lower scaling over the long term

<articmine> While allowing pricing much tighter over the short to medium term

<articmine> So this is an overall reduction in scaling

<boog900> @articmine: how? a lt multiplier that grows at max of 40% a year should lead to the same growth

<sgp_> can we ignore debating how we already now Artic's proposal will be? :p I actually want to now the thoughts on the comment since it directly tries to account for what you want boog

<articmine> No changing the long term median growth does not address the concend

<articmine> Convcens

<sgp_> because you want the ability to "catch up" to the max to make up for lagging/suppressed/delayed, and boog opposes, yes we all know

<boog900> @sgp_: he is saying it requires on chain activity ....

<articmine> @boog900: A 50 % cap over the long term is like 1.085 on ML

<sgp_> you both understand the same thing but are defining it differently

<sgp_> the cap does increase regardless of demand. But the cap isn't necessarily the instantaneous block limit, since there are other caps that could apply

<boog900> that would contradict what he said here though^ > <@articmine> NO

<sgp_> I'm just trying to cut past this to reality lol

<gingeropolous> a short term median, a long term median, and a sanity cap

<gingeropolous> stir em all together, you get scaling.

<boog900> @sgp_: yeah I do have a strong suspicion, I am excited to see the proposal now though!

<boog900> as for yours I will have to take a look at the whole thing again, I don't have any major problems with that small part though

<boog900> I don't know if I would want such a huge change to our scaling though

<spackle> I am excited to see the proposal as well, and I share boog's perspective on today's conversation. If there is consensus that the daemon can handle 10.8 MB blocks (and I think it is very reasonable to expect this or similar), I don't believe anything else is needed.