06:43:56 <tevador> My take on block size scaling: https://github.com/monero-project/research-lab/issues/155
15:36:00 <br-m> <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! https://github.com/monero-project/research-lab/issues/152#issuecomment-3602637932
16:16:29 <DataHoarder> On https://www.getmonero.org/resources/research-lab/ maybe the "UNPUBLISHED: Understanding ge_fromfe_frombytes_vartime" section can link to documented versions? https://github.com/monero-project/research-lab/issues/142 https://github.com/monero-oxide/monero-oxide/pull/33 
16:19:38 <br-m> <articmine> Tevador's concept makes a lot of sense as a sanity check on my proposal. 
16:19:38 <br-m> <articmine> I do have concerns regarding some of the conclusions.
16:19:38 <br-m> <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 https://mrelay.p2pool.observer/e/rofvys4KQ0tuRS1z ]
16:22:46 <br-m> <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.
16:27:49 <br-m> <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.....
16:28:32 <br-m> <gingeropolous> sorry, 1 TB in 26 years
16:28:35 <br-m> <gingeropolous> 36 years. blargh
16:29:51 <br-m> <boog900> IMO we should not have exponential growth without any extra demand 
16:30:34 <br-m> <sgp_> @boog900:monero.social: I would love for you to take a sec to read this and let me know what you think: https://github.com/monero-project/research-lab/issues/152#issuecomment-3602637932
16:50:07 <br-m> <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. 
16:50:07 <br-m> <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.
16:51:09 <br-m> <gingeropolous> @boog900: the adaptive blocksize would still be in effect. 
16:51:58 <br-m> <boog900> @gingeropolous: which one? the one that allows GB blocks in a year? 
16:52:34 <br-m> <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
16:54:11 <br-m> <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. 
16:54:12 <br-m> <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 
16:54:39 <br-m> <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
16:55:20 <br-m> <ofrnxmr:xmr.mx> I read it as would, otherwise why start at 10mb instead of 300kb?
16:55:42 <br-m> <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."
16:55:49 <br-m> <boog900> either way artic is talking about a limit that increases no matter what 
16:55:55 <br-m> <gingeropolous> its a cap. so the adaptive could grow up to that cap if needed
16:56:19 <br-m> <articmine> We are after all talking about a sanity cap.
16:56:51 <br-m> <articmine> On the of a highly priced scaling algorithm.
16:57:06 <br-m> <articmine> On top of 
16:57:16 <br-m> <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
16:57:56 <br-m> <articmine> Anyway I have to work on my proposal.
17:01:01 <br-m> <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?
17:02:47 <br-m> <boog900> yeah the "sanity limit" is always increasing, eventually it'll be so big it is effectively not there. 
17:03:01 <br-m> <boog900> even with no extra activity 
17:03:41 <br-m> <sgp_> Fwiw I agree with you but ArticMine sees that as an advantage. My guess it that people are split on that
17:03:44 <br-m> <ofrnxmr:xmr.mx> But that should be "priced in", meaning (ideally) monerod, networking, hardware etc should be able to handle it by then
17:04:03 <br-m> <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.....
17:04:55 <br-m> <boog900> yes that is 30 years so like it doesn't matter that much, but this is pretty much a block size bomb 
17:06:02 <br-m> <ofrnxmr:xmr.mx> But the bomb at that point in time should be negligible
17:06:19 <br-m> <kayabanerve:matrix.org> Fixed 32 MB limit with dynamic scaling up to there would never do that to you /s
17:06:27 <br-m> <ofrnxmr:xmr.mx> meaning, if we ballooned up to 10.8mbs today, we SHOULD be able to handle it
17:07:40 <br-m> <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.
17:07:54 <br-m> <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. 
17:08:15 <br-m> <boog900> sorry 8*
17:08:28 <br-m> <ofrnxmr:xmr.mx> Monero is 11 yrs old, i'd hope we can handle 100mb blocks in 8 more years
17:08:29 <br-m> <kayabanerve:matrix.org> But 40% for the next n years, where n is defined, isn't something I'd hate
17:09:14 <br-m> <boog900> @ofrnxmr:xmr.mx: hopefully 🙏
17:09:59 <nioc> <ofrnxmr:xmr.mx> meaning, if we ballooned up to 10.8mbs today, we SHOULD be able to handle it <<>> 3TB a year ?
17:10:11 <br-m> <sgp_> 236 TB of max blockchain space in 10 years is quite a bit fwiw
17:10:59 <nioc> *3TB this year
17:11:21 <br-m> <sgp_> We're not even at 1 TB total after a decade
17:13:02 <br-m> <ofrnxmr:xmr.mx> the size of the blockchain is something thatbwe obv have to work on 
17:14:02 <br-m> <ofrnxmr:xmr.mx> Whether that be using ssd cache and hdd archive, more aggresive pruning, or something else
17:14:34 <br-m> <sgp_> yeah 3TB today is a non-trivial cost. Not insane, but non-trivial
17:14:58 <br-m> <sgp_> Which is probably exactly what the proposal is going for
17:17:47 <br-m> <sgp_> A cheap 4 TB ssd is roughly $250 today. $100 for hdd. So roughly that in new storage costs per year
17:19:51 <br-m> <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?
17:20:16 <br-m> <boog900> nioc: That's just the block and tx blobs as well. You would need to around 1.5x that for the full db
17:20:42 <br-m> <sgp_> @articmine: Unknowable
17:21:19 <br-m> <articmine> Lower bound?
17:21:39 <br-m> <sgp_> Lower bound is essentially $0 in fees
17:21:59 <br-m> <sgp_> Except for the block reward penalty I guess, depending how you calculate it
17:22:01 <br-m> <articmine> @sgp_: Fees have nothing to do with this
17:22:28 <br-m> <articmine> We are not talking about spam
17:22:52 <br-m> <sgp_> Bitcoin shows there isn't necessarily a relationship between XMR/USD and transaction volume
17:23:00 <br-m> <sgp_> So unknowable
17:25:55 <br-m> <articmine> I am talking about peer to peer electronic cash transactions. Speculation on centralized ledgers is unknowable and ON TOP of that.
17:27:02 <br-m> <sgp_> I find it completely unrealistic to try to correlate the price of XMR with on chain transaction volume
17:27:35 <br-m> <sgp_> I believe there is nearly 0 relation, certainly not a predictable one
17:27:49 <br-m> <articmine> @sgp_: I find it unreasonable to ignore the impact of peer to peer cash
17:28:14 <br-m> <sgp_> Yeah but how the hell do you quantify the price impact to XMR/USD
17:28:34 <br-m> <sgp_> Anyway I think this discussion doesn't really matter
17:28:51 <br-m> <articmine> @sgp_: That makes sense if one does not believe in peer to peer cash transactions
17:29:54 <br-m> <articmine> What is the point of cryptocurrency anyway?
17:34:32 <br-m> <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
17:35:22 <br-m> <articmine> What is the value proposition for Monero vs fiat card payments?
17:36:04 <br-m> <articmine> We have to start with the basics here.
17:36:49 <br-m> <sgp_> I'd rather just... not. I don't want to talk in circles about ultimately nothing
17:37:34 <br-m> <articmine> @sgp_: Where we disagree is the fundamentals
17:37:41 <br-m> <sgp_> Yes
17:39:25 <br-m> <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 
17:40:34 <br-m> <articmine> This exponent scales with Neilsen's Law
17:45:14 <br-m> <articmine> Again what is the value proposition of Monero?
17:46:13 <br-m> <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.
17:47:33 <br-m> <articmine> @boog900: Why has the market valued Monero over ZCash and Pirate Chain?
17:49:04 <br-m> <boog900> I don't see your point 
17:49:27 <br-m> <sgp_> Why does Solana have more transactions but a lower market cap than Bitcoin. These aren't predicably correlated. Period.
17:51:10 <br-m> <articmine> @boog900: My point is that  the size of the mix set is critical for privacy
17:52:24 <br-m> <sgp_> if I spem XMR transactions the price of 
17:52:55 <br-m> <articmine> @sgp_: I am not talking about spam
17:53:44 <br-m> <sgp_> my point is that the impact is unknowable, as demonstrated through those basic examples
17:53:53 <br-m> <boog900> @articmine: I still don't see how that is related to my original point lol
17:55:21 <br-m> <articmine> @sgp_: Because Solana has a use case. Bitcoin is becoming selling to the greatest fool. The candidate for greatest fool is Uncle Sam
17:56:04 <br-m> <sgp_> you're just describing that the market is irrational. hence unknowable
17:57:18 <br-m> <articmine> @sgp_: In the long term fundamental value wins in the market. That is why Warren Buffett made billions
17:59:02 <br-m> <rucknium> Here is yet another scaling algorithm, from Bitcoin Cash: https://gitlab.com/0353F40E/ebaa#technical-description
18:00:19 <br-m> <articmine> Bitcoin Cash has no pricing for scaling. That is my main concern with their approach 
18:00:47 <br-m> <articmine> Their algorithm is a very interesting otherwise 
18:02:58 <br-m> <articmine> If Bitcoin Cash had a tail emission it would become a very viable option 
18:11:42 <br-m> <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.
18:11:42 <br-m> <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
18:12:37 <br-m> <articmine> So one can be a Monero maximalism and not care about privacy 
18:14:04 <br-m> <boog900> @articmine: you can create a monero clone with exactly the same scaling rules but much smaller txs with no privacy features 
18:15:07 <nioc> do all of our privacy mean little?
18:16:00 <nioc> I remember when 1 hop was enough  :D
18:16:22 <nioc> ^^for btc
18:16:55 <br-m> <articmine> nioc: I can become a balancing act. Realistically I believe we can have the best of both worlds.
18:18:02 <br-m> <articmine> It is a myth that BS works on BTC. This by the way is before the courts
18:18:49 <br-m> <articmine> @boog900: I hope this does not become necessary
18:22:03 <br-m> <articmine> A non privacy Monero ledger fork?
18:27:12 <br-m> <boog900> @articmine:monero.social: I don't see why you wouldn't want that, it would make your scaling much more achievable
18:27:59 <br-m> <testtank:matrix.org> https://mrelay.p2pool.observer/m/matrix.org/tsZVRwZotmNUNixOxkelBZSj.jpeg (IMG_3240.jpeg)
18:27:59 <br-m> <testtank:matrix.org> @articmine: .
18:30:04 <br-m> <articmine> @boog900: I believe that there is a big difference between extreme sanity limits and the actual reality
18:33:15 <br-m> <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?
18:34:48 <br-m> <boog900> we have been over this so many times 
18:34:54 <br-m> <articmine> What would have happened to Monero with a 300x increase in blocksize via spam?
18:36:52 <br-m> <articmine> I am staying loyal to the original Monero social covenant, as opposed to making drastic changes. 
18:36:52 <br-m> <articmine> This begs the question why not fork Monero and create a Bitcoin style ultra small block coin?
18:38:09 <br-m> <articmine> Then let the community choose which fork to support.
18:39:36 <br-m> <boog900> you fundamentally believe monero's privacy is unimportant. Stop pretending that anyone who disagrees with you wants bitcoin style ultra small blocks.
18:41:02 <br-m> <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.
18:44:08 <br-m> <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.
18:44:41 <br-m> <boog900> You argued for increasing the limits at the last HF.
18:45:42 <br-m> <articmine> @boog900: Limits that I had designed my proposal.
18:46:14 <br-m> <articmine> Like a year before 
18:47:46 <br-m> <boog900> exactly 
18:47:48 <br-m> <articmine> The original scaling had no long term median, and has been proven to work.
18:48:30 <br-m> <articmine> The so called big bag attack never happened. It is just theory.
18:48:43 <br-m> <articmine> Big Bang 
18:50:04 <br-m> <boog900> just because an attack hasn't happened doesn't mean it might not be a real attack.  
18:51:22 <br-m> <boog900> again we have already gone over this
18:52:23 <br-m> <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
18:53:04 <br-m> <boog900> yes or no, does the increase happen without any extra on-chain activity? 
18:53:18 <br-m> <articmine> NO
18:53:27 <br-m> <boog900> your 50% cap?
18:53:35 <br-m> <articmine> NO
18:53:52 <br-m> <boog900> I am suspicious but I will wait for the proposal 
18:54:02 <br-m> <articmine> Good 
18:55:03 <br-m> <boog900> I don't see why you don't just change the long term multiplier in that case 
18:55:59 <br-m> <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
18:55:59 <br-m> <sgp_> https://github.com/monero-project/research-lab/issues/152#issuecomment-3602637932
18:56:46 <br-m> <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? 
18:57:43 <br-m> <articmine> @sgp_: By it self an actual disaster for spam for starters
18:57:52 <br-m> <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 
18:58:32 <br-m> <articmine> @boog900: Because you get much lower scaling over the long term
18:59:01 <br-m> <articmine> While allowing pricing much tighter over the short to medium term 
18:59:29 <br-m> <articmine> So this is an overall reduction in scaling 
18:59:29 <br-m> <boog900> @articmine: how? a lt multiplier that grows at max of 40% a year should lead to the same growth
18:59:45 <br-m> <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
19:01:12 <br-m> <articmine> No changing the long term median growth does not address the concend
19:01:36 <br-m> <articmine> Convcens
19:02:47 <br-m> <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
19:03:10 <br-m> <boog900> @sgp_: he is saying it requires on chain activity ....
19:03:29 <br-m> <articmine> @boog900: A 50 % cap over the long term is like 1.085 on ML
19:03:30 <br-m> <sgp_> you both understand the same thing but are defining it differently
19:06:19 <br-m> <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
19:07:39 <br-m> <boog900> that would contradict what he said here though^  > <@articmine> NO
19:08:02 <br-m> <sgp_> I'm just trying to cut past this to reality lol
19:08:05 <br-m> <gingeropolous> a short term median, a long term median, and a sanity cap
19:08:32 <br-m> <gingeropolous> stir em all together, you get scaling. 
19:09:29 <br-m> <boog900> @sgp_: yeah I do have a strong suspicion, I am excited to see the proposal now though! 
19:11:44 <br-m> <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 
19:12:35 <br-m> <boog900> I don't know if I would want such a huge change to our scaling though 
23:21:20 <br-m> <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.