00:45:35 @diego:cypherstack.com: The current ruled can cause the network to blow up in a year without my proposal for a static limit. 00:46:14 *rules 00:49:22 There is a minimum required patch set, even if we can debate if an entire new proposal must be done with FCMP++ or after. 00:49:54 It's why my proposal was independent 00:52:20 Can I see the write up? 00:52:25 Sorry must have missed it. 00:53:41 It was a 32 MB limit which became the heavily-discussed 90 MB limit. 01:03:23 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. 01:05:16 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. 03:56:09 I uploaded my proposal to lower the penalty free zone to 62500 bytes. 03:57:56 https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-02.pdf 04:03:20 First year less than 1.4*10^7 bytes 04:39:26 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 https://mrelay.p2pool.observer/e/yOvR288KT2NYZ3R5 ] 04:43:47 I think there's a difference between performance degradations at 1 GB and the code literally breaking upon 1 GB. 04:44:15 If we properly shred blocks, and re-design the RPC as unbounded, there wouldn't be such hard limits. 04:44:49 not to be pedantic but the current scaling parameters etc were also arbitrary before they were set 04:46:10 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) 05:00:09 block shreds. mmmmmmmm 05:03:34 a hard cap for x amount of blocks is the quickest and easiest. clean to reverse as well, just a few lines to remove 05:03:50 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 05:03:55 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 05:04:14 at least adjusting the hash algo by doubling the blake 2b round as suggested would be a good first step, that's easy 05:04:56 randomx is already anti-ASIC 05:30:45 @jbabb:cypherstack.com: The deactivation height is when this is fixed. 06:07:09 My proposal is under 14 MB for a year. Why 32 MB for a year? 06:08:42 What is really requested here is an indefinite deactivation height 07:19:55 > there's a realistic deactivation height. 07:19:55 ^ then nodes can be fed blocks above that height before reaching it :) 14:09:19 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 https://www.reddit.com/r/Monero/comments/1peug7m/monero_developers_are_on_track_to_add_an/ 14:22:56 > <@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 https://mrelay.p2pool.observer/e/-syq7M8KRWJqTG1F ] 14:22:56 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 14:24:55 so no sanity cap, but a much slower overall growth rate allowed by the dynamic algos? 14:25:01 90mb isnt a sanity cap 14:25:19 lol 14:25:19 The sanity cap is the 1.4x yearly expanding cap 14:25:22 your a sanity cap 14:25:38 Which is why indexing the sanity cap to below Neilsen's Law makes sense 14:25:41 90mb is a hard cap related to packet size limit 14:26:34 gotcha 14:27:35 @monero.arbo:matrix.org: have you seen my proposal, much better expectations for nodes/ node operators 14:28:02 @boog900:monero.social: I'm just catching up from the last few days, I have it open to read rn (: 14:29:14 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? 14:29:54 @boog900:monero.social: , tryin to find link. do you have it handy? 14:30:05 https://github.com/seraphis-migration/monero/issues/44#issuecomment-3617687600 14:33:52 @monero.arbo:matrix.org: so this could get it 25 MB in a year and gigabyte blocks in two years? 14:34:56 yes to 25 no to gigabyte 14:34:59 It is not capped by Nielsen's Law 14:35:42 @boog900: so the 40x per year slows down? 14:35:43 So over the long term is more growth aggressive than mine 14:35:53 @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 14:36:21 hmm okay I see 14:36:24 so yes it would only be 2.5x in the second year 14:37:03 @articmine: great then let's have both (: 14:37:11 (both limits) 14:37:25 yeah if artic is really scared I am down for that, but he is not 14:37:42 he is misrepresenting it like he has been doing 14:37:55 he wants more growth not les 14:38:27 We need to keep both the cap and the 2x on ML 14:39:23 2.5x compounded annually is greater than 1.4x 14:39:27 ART: A Graph-based Framework for Investigating Illicit Activity in Monero via Address-Ring-Transaction Structures 14:39:27 https://arxiv.org/abs/2511.16192 14:39:59 the 1.4x happens without any usage 14:41:47 Advanced Monero wallet forensics: Demystifying off-chain artifacts to trace privacy-preserving cryptocurrency transactions 14:41:47 https://www.sciencedirect.com/science/article/pii/S2666281725001283 14:41:59 @boog900: that's bad 14:42:24 @monero.arbo:matrix.org: I know, thats the difference 14:42:40 mine is 2.5x if you max out the scaling algorithm 14:43:10 his is 1.4x if there are literally 0 txs 14:44:07 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? 14:46:09 yeah I hear you 14:46:55 I can add the sanity cap but I really think it is unnecessary. 14:47:54 here is what I put in the comment on github: 14:47:54 > 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 https://mrelay.p2pool.observer/e/4M-F7c8KNWJtc2ct ] 14:48:20 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? 14:49:23 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? 14:50:13 idk just spitballing 14:51:54 To do that you could probably increase the short term multiplier and decrease the long term multiplier 14:52:46 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 14:53:06 As otherwise it'll be a pain to get consensus for 15:09:16 The growth in the sanity cap with no actual growth in usage is necessary especially to address BS suppression of Monero. 15:09:16 I explained this scenario in my notes 15:13:08 Yes we know you believe dangerous growth is needed and this ever increasing sanity cap is a way for you to sneak it in. 15:18:31 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) 15:19:25 I believe growth that is dangerous to Blockchain Surveillance but not to Monero 15:20:12 @articmine: How does it affect BS companies ? After fcmp they have no edge 15:21:37 On a small enough mix set even FCMP++ is vulnerable 15:22:49 @articmine: 1,024x is extremely dangerous 15:23:04 Fwiw im fully in favor of this > <@boog900> his is 1.4x if there are literally 0 txs 15:23:11 Oh but the sanity cap!!!! 15:23:34 Otherwise there's no logical reason to start at 10mb instead of 100kb 15:23:39 @articmine: "small"? I'm pretty sure even the lowest proposal is suggesting something like hundreds of thousands of transactions a day 15:24:46 @ofrnxmr: What? Its all arbitrary at a certain point, yes that number was got from that proposal but why does that matter at all 15:25:00 Then there is quantum computers 15:25:30 @articmine: we have already been over this yesterday. 15:26:05 I mean I am not wasting my time on this 15:26:15 @ofrnxmr: ok, but do you support the rest of the proposal? 15:29:23 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 15:30:50 and i personally think 100 block short term median is too short, but thats more bikeshedding imo 15:41:09 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. 15:44:01 Also artic likes bitcoin cash, the last true contender for sound money, am I right? 15:50:58 1024 = 300mb? (1024 * 300kb?) 15:53:40 no its 1024 * whatever the long term median is, which is at least 625kb in the current proposal 15:55:57 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. 15:56:19 pretty crazy IMO. 16:08:37 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? 16:10:20 If Bitcoin Cash were to stop the halving creating a tail emission then there would hope there. 16:10:54 Their scaling algo is more conservative than mine lol 16:11:20 As for thier scaling algorithm it is actually very bad because there is no pricing 16:11:41 So it is trivial to spam 16:15:46 @boog900: Your proposal would actually work well for a mature coin with say 1000 transactions per second, that is not under attack. 16:15:46 It is getting there safely that is the issue. 16:16:01 yayyy progress 16:19:01 It has to be done slow enough so node operators have time to adjust 16:19:14 and well software as time to improve 16:19:19 has* 16:21:14 Yes but aggressive scaling beneath a strict cap is actually way better there, because every one knows what to expect when 16:21:56 So predictably is actually vital 16:22:00 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. 16:22:56 That can happen but everyone would know the limits ahead of time 16:23:04 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 16:23:34 it would be crazy to always allow blocks to increase 1024x in a year 16:23:40 That is like how far in the future? 16:24:15 14 years is when the sanity cap stops preventing a years worth of growth 16:24:19 Furthermore it would be a one time move 16:24:25 but before that it is still always increasing 16:24:28 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? 16:25:41 Still restricted by the sanity median 16:26:10 In 14 years with no growth then one gets 1000 TOS and.the cap is still 1.4x 16:26:33 TPS* 16:28:59 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 16:30:09 I was looking at a sanity median with 10^6 blocks 16:31:19 The trouble with that is the initial conditions 16:31:19 This is on top of the concerns that jeffro256 mentioned to me 16:32:04 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 16:32:04 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 16:32:38 I do 16:32:45 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. 16:33:10 mine would get us there in 5 instead 16:33:13 much better IMO 16:33:22 well jut 16:34:33 The assumption is that Neilsen's Law will hold. If it does great. If it changes then yes we have to make changes 16:35:10 You can't assume exponential growth of every Monero bottleneck forever. BIP101 agrees. 16:35:37 >"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 16:35:39 >is surprised 16:35:49 >"I wish I were surprised" 16:35:54 >is not surprised 16:36:23 chat am i illiterate 16:36:28 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. 16:37:32 like I get wanting to support growth 16:37:53 but that would blindside so many node operators who would have very little time to upgrade systems 16:38:01 and who says 1,024x is enough? 16:38:37 like really it is an arbitrary number that you decided, no one has a magic ball 16:39:59 @boog900: 0.6 worked just fine, so what about 0.6x growth 16:40:10 oh wait not likethat 16:40:10 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 16:40:59 How many HF can we reasonably expect before then while this thing is building up 16:41:11 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 16:41:50 @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 16:42:23 Yes but one still needs 14 years of no gry to move the cap 16:42:29 and btw you are preparing the system for this 16:42:45 you are the one preparing for 14 years of no growth then 1 GB in a year 16:43:14 like what not have a smaller ltm multiplier and make it a smooth increase 16:43:16 like mine :p 16:44:16 I am just pointing out the issue > <@boog900> and btw you are preparing the system for this 16:46:03 The current 5 years since 2021 is wild enough, but 14? 16:46:31 In any case I do have to leave 16:46:32 exactly so why do we need 1024x surly it should be lower? 16:47:07 we aren't going to have 14 years of no growth then get 1 GB in a year so why allow it? 16:50:21 @syntheticbird: initial surprise, followed quickly by "of course they did" 16:52:40 for real though, it's wild to have a member of "core team" reddit posting about how the devs are being sneaky and nefarious 16:52:49 genuinely irresponsible imo 16:56:17 @monero.arbo:matrix.org: [removed] 18:17:37 @boog900: The factor for a year under my proposal is 512 = 16 x 32. I am capping the block weight as opposed to MS 18:18:59 512x is a bit below a year 1024x is a bit above 18:19:57 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 18:20:25 Bit* 18:20:58 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 18:21:42 Yeah but that is just extra complication and gets back to who says this is enough 18:22:12 Like its all arbitrary as we don't know if that we be more than or less than the required growth 18:22:30 The argument is that this is comparable to the initial surge 18:22:45 At the HF 18:23:07 We already have a surge factor tho 18:23:15 40x or 47x 18:24:03 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. 18:24:15 No going from our current block weight to 10*10^7 bytes 18:27:12 By the way when it comes to the Litecoin surge I use a 43in 4 K monitor to measure it 18:27:27 I certainly would not use a smartphone 18:28:11 So 47x is too low 18:32:14 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. 18:32:14 I think we are just going to have to disagree here and allow others to make up their mind. 18:32:40 A 128x surge in a year is reasonable given our starting conditions and the LTC data 18:32:53 Bitcoin cash did analysis of their algo and they found it was enough to support all tx activity across bch ltc btc and ETH 18:33:07 And it is more conservative than mine 18:34:38 I've what period of time for ramp up? 18:35:10 For BCH 18:36:28 I believe their stating blocksize is 32 MB 18:36:29 https://gitlab.com/0353F40E/ebaa 18:37:17 @articmine: It was using 1 MB in the test 18:40:14 It is 32 MB from their definitions 18:40:43 Vs 625000 bytes for us 18:40:58 No 18:41:10