00:00:07 A soft fork is a change that is backwards compatible with old nodes 00:00:16 not a temporary change 00:00:38 bring back "token" hardforks every 6 months :P 00:00:50 It is backwards compatible with the existing scaling and my proposal 00:01:35 but why have the extra softfork just include it in the hardfork? 00:02:03 To prevent attack on the existing scaling 00:02:18 wat 00:02:22 But the further 'soft forks' also have to be sequentially compatible 00:02:35 Regarding the identified vulnerabilites 00:02:58 @kayabanerve:matrix.org: Yes 00:03:20 you can include the restrictions on growth in the HF then remove them with miner consensus. Using the term soft fork is confusing as it doesn't need to be a softfork 00:03:39 still this is so much protocol complexity 00:04:09 Miner majori not consensus 00:04:09 For what? why not just change the short and long term multipliers? 00:04:41 @articmine: miner majority is pretty much consensus otherwise we can get chainsplits 00:04:56 Out of selfish reasons I want to say I prefer conservative scaling proposals because if it it is too easy to spam the blockchain I feel like I'm the one who always has to work on the emergency releases. 00:04:58 @boog900: This does not address the smart blocker concerns 00:05:20 selsta: Spam is not the issue 00:05:30 Neilsons law says you get a 50% bump every year 00:05:30 So why not do 00:05:30 Why not let long term median to 525600 (2yr) blocks @1.5x (meduan = 262800 blocks, 1yr) and max short term median to 16mb 00:05:35 @articmine: who are you to say? 00:05:53 I literally made it and it addresses my concerns (mostly) 00:05:57 It is genuine growth that is too fast t the network 00:06:27 @boog900: You are not the only one 00:06:27 we are not going to get 1000x growth in a year 00:06:30 monero is nowhere near the quality where l scaling becomes purely theoretical, as shown on stressnet 00:06:32 @ofrnxmr:xmr.mx: and we can hf to increase that if we have some breakthroughs 00:06:34 we aren't going to get 100x 00:07:27 <321bob321> Where going visa level soon 00:07:52 I will put something together 00:07:58 even during the low effort spam attack a couple years ago we ran into a lot of issues like nodes crashing due too too large txpool 00:08:17 so before our software is optimized i prefer slower scaling 00:08:27 Ok, I will also discuss my proposal with people 00:08:51 @ofrnxmr:xmr.mx: @boog900:monero.social @articmine:monero.social ^ thoughts? 00:10:09 if we increase txpool size and extend expiration time to longer than 72hrs, we can also expand shirt term meduan from 100 blocks to like.. 720 (1day) 00:10:28 @ofrnxmr:xmr.mx: that would be quite slow scaling, I am not against it but I think a few would be 00:10:34 We just put a cap that meets the above numbers and grows by 50% a year 00:11:00 also I do like how my proposal keeps a lot of stuff the same, there is a big benefit in keeping changes simple 00:11:07 It can meet boog900 numbers 00:11:27 It is t very simple change 00:11:34 16mb is 100x current volume (ringct) 00:11:51 And is 11gb per day 00:12:16 to add to what I wanted to say, long term scaling (over a year) is less relevant for me if it allows larger growth because it allows us to do emergency changes if it is not authentic growth 00:12:29 @ofrnxmr:xmr.mx: I would just lower the long term growth rate even more if you wanted slower scaling 00:13:28 With my proposal, short term is 8 long term is 1.4 with 750,000 penalty free zone. This means 12mb blocks in ~2 months and ~90mb blocks in a year. 00:13:54 still high, but better than gigabyte blocks in a year 00:13:55 can the current software support 90mb blocks? 00:14:02 no 00:14:04 i think 90mb blocks in a year is overkill w/o a hard fork 00:14:10 selsta: No 00:14:25 yea then we have to limit it realistically before the software supports it :D 00:14:51 unless the discussion currently is purely theoretical limits 00:15:18 currently i think current scaling allows much larger than 90mb 00:15:51 If we really want to test it, we should just ramp up scaling dramatocally on strwssnet and push blocks as large as we can until it breaks 00:16:15 I took 100 mb as a hard ceiling for a year as thats the packet size limit so getting above that would be extremely hard in a short amount of time, I would support even slower scaling though 00:16:27 @ofrnxmr:xmr.mx: its like 240mb in a year 00:17:30 using a long term growth rate of 1.2 instead of 1.4 would be ~35 mb 00:17:49 i personally dont think we need to support over 16mb within the first year, and 50% YoY increase until we hard fork with breakthroughs that allow us to support 100mb blocks 00:17:58 50% YoY is neilsons law 00:19:06 32mb might be do-able, and once the weight changes are on stressnet can be tested accurately 00:19:15 I thought that was called a fallacy 00:43:31 @boog900: So 100 Mb per block until the end of 2026 00:44:12 no 100 MB per block as long as current median is at minimum value 00:44:36 but as you can see selsta and ofrn both want lower 00:44:46 like 30 MB 00:45:15 which I wouldn't mind, which would put the long term max growth at 1.17 00:46:42 It is 16 MB for 69 days from 1 MB ZM 00:47:09 Just on my proposal 00:48:01 yeah but that increases 2x every 2 months after 00:48:49 To meet the 100 MB cap we have to set cap on the soft fork at 50MB 00:49:04 where does the 100k blocks number come from? (why 100k? Why not 262800? Etc) 00:50:01 @articmine: I feel like you have managed to ignore everything I have said today 00:50:21 Not at all 00:50:37 @ofrnxmr: tbf seen as it is already chosen, unless there is a good reason, I would just keep it as is 00:51:28 The 100 MB is a bug that cannot be easily fit 00:51:35 Fixed 00:51:54 @boog900: The shorter it is the more reactive, the longer the less reactive, but you can just change the rate it is scaled by so you get the same outcome 00:52:51 when just looking at max block size* 00:53:19 On just sets a global cap to meet the 100 MB limit and then scarlet it at 50% per year 00:53:40 Scales 00:54:07 yeah but now in the second year that is a 150 MB limit 00:54:25 etc etc for following years growing exponentially 00:54:29 At the end of the second year 00:54:53 I really feel just changing the current short/long multipliers is the simplest solution 00:54:55 It is way less than your proposal 00:55:24 And it follows Neilsen's law 00:56:45 my proposal will have the same yearly maximum from starting at the penalty free zone forever, after 7 years yours allows gigabyte blocks again in a year 00:57:21 What my approach will do is provide the necessary flexibility within the limits 00:58:09 not really, it is still higher than selsta and ofrn want and it will only meet my proposal for the first year 00:58:22 @boog900: Your proposal is over 5x vs 1.5 x per year 00:59:07 @articmine: if someone is fully spamming block mine allows 5x, sure, someone does not need to spam with your proposal to get the 1.5x 00:59:19 framing it as the same is disingenuous 01:00:28 @boog900: They do because they also have to deal with my current proposal 01:00:45 which allows gigabyte blocks in a year 01:00:57 That stays . It is the lower of the two 01:01:34 Min ( P1,P2) 01:01:36 and the 100mb limit increases no matter the spam, after some years its above the gigabyte 01:01:53 you know its not safer 01:02:04 Come on 01:02:39 I am not going to argue this. It is way safer since it is the lower of the two 01:03:21 its the same in the first year, after that it is worse when we take starting from 0 and spamming for a year, correct? 01:03:57 Shouldn't 100 MB be a hard ceiling entirely as we're no where close to that and existing code inherently assumes blocks don't get that big? 01:04:07 for year 1 a spammer spamming for a year can reach ~100 mb with both 01:04:07 for year 2 a spammer spamming for a year can reach ~100 mb with mine and 150mb with yours 01:04:14 Yes, we can say that's a bug to fix, but this is once again designing for theoretical usage and not our actual performance 01:04:44 *and also, it'd have to be a bit under 100 MB so with overhead, it doesn't exceed 100 MB 01:05:51 I'd vote 1 MB, which is under 100 MB and should even be currently supported /s 01:05:51 *I'd probably look at 50, 64, or 96 MB 01:06:24 probably but adding a hard limit would have some push back, and the limit should be way lower if we are doing that. Around 30 mb is the maximum currently before breakage IIRC. > <@kayabanerve:matrix.org> Shouldn't 100 MB be a hard ceiling entirely as we're no where close to that and existing code inherently assumes blocks don't get that big? 01:06:38 on mainnet it is lower than that again 01:06:51 Eh, I don't mind having the hard limit reasonably past current perf 01:07:18 2x current perf is its own discussion, I'm just saying if we have a year to find 5-10% and known improvements on the way, who minds 01:07:51 But that'd suggest 32 MB as a hard cap on the block size limit, to be reevaluated at the next HF? 01:08:21 And yes, that doesn't infinitely scale, it literally is finite, but monerod doesn't infinitely scale 01:10:30 What t current performance in a 2, 4, 6, 8, 10, 12 months time frame 01:11:02 Provide this and I can design the cap 01:11:17 let me get my magic ball rq 01:11:27 Arguing endlessly is pointless 01:12:52 absolutely I think I have a nice simple solution. Just adjusting the existing system is way simpler than bodging a dodgy safety cap on top. 01:22:35 @boog900: I disagree. A soft fork cap can solve this. What I need is the maximum allowable blocksize vs time, based upon the stressnet work and identified issues 01:25:03 right now IMO we should have advanced warning of blocks going to 20 to 30 MB than wayy in advanced warning of blocks going to 100 mb 01:25:21 those limits should not change year on year 01:26:21 As you can see my proposal covers this as although it may allow more grow other 2 years of spam, your proposal allows someone to wait a year and then they can spam that year upto 150 mb 01:26:58 No 01:49:48 What about us more fundamentally agreeing that a more reasonable max of 2x in a year is acceptable. We don't need to more than double in a year even under max demand conductions. If demand is high to justify that, the doubling is faster than the rate of historical tech advancement anyway. We don't need 100x or other massive increases within a year 01:50:57 I'm not even for 2x, I think that's too much still. But 2x is way better than the proposed max 01:52:07 @ofrnxmr:xmr.mx: Or 50% max. Again, closer to reason 01:52:52 @sgp_: 1.5x is Neilson's law tho 01:53:21 Yeah so even 2x max per year is too high by that metric 01:54:57 If were using neilsons law to justify #s, then we should be consistent. I think 32mb within a year is a safe number 01:55:20 Safe, as in, we shouldnt need more than that, and its "survivable" 01:56:00 > <@sgp_> What about us more fundamentally agreeing that a more reasonable max of 2x in a year is acceptable. We don't need to more than double in a year even under max demand conductions. If demand is high to justify that, the doubling is faster than the rate of historical tech advancement anyway. We don't need 100x or other massive increases within a year 01:56:00 TBC my proposal was more around using the existing system but just changing the growth rates. 100x is high, its literally the highest I wanted to go. 01:56:27 I would support targeting 32 MB or 2x the max short term growth instead 01:57:18 Im not saying 1.5x the penalty free zone, thats much too small. But 1.5x the max (ideally 32mb) short term limit 01:57:50 32mb is 100x the current penalty zone, and like 200x the actual volume 01:59:07 im also in favor of hard forking to increase these limits as soon as the software and hardware can handle them 01:59:10 I think a short term limit of 32 is pretty high ngl 01:59:53 I would rather be in the 16 MB range for short term 02:00:37 @boog900: You will be 02:00:43 Yeah I don't care as much about the initial M(L) (though I still care somewhat). I care more about preventing it from growing faster than is reasonable. 2x max growth per year should be plenty to allow for ArticMine to support it as a "catching up" function. Even that would literally allow for faster growth than the historical rate of tech advancement 02:00:48 Having a penalty free zone of 750,000 with a short term growth rate of 8 gives us 12mb, do we think this is enough? 02:01:43 For a short term limit^ 02:02:26 Then max block size is 24mb at the end of the year if we ho with 2x 02:03:07 Max growth rate of M(L) could be reduced by lengthing the long term median blocks and/or reducing the allowed growth rate per that time period 02:03:31 Conflict of interest 02:03:40 What's the current justification from growing M(L) from 1.7 to 2 02:03:40 Is a serious issue here 02:03:42 @articmine: Let's us talk 02:05:07 1.7 to the third is roughly 4.9x-ish per year, above 1.5x (Moore's law ish) and 2x per year 02:05:21 @sgp_: https://github.com/seraphis-migration/monero/issues/44#issuecomment-3561821958 02:06:12 Ok so it's just due to perceived capacity shortages 02:06:38 Pretty much 02:07:01 Need that 1000x gigabyte blocks in a year 02:07:30 Lowering to 1.2 would be more sensible in my view. That's still more growth than the rate of Moore's law 02:10:33 Does anyone else want to allow more than 50% or 100% growth a year? 02:12:02 (ignoring the first base adjustment to compensate for FCMP) 02:14:34 @sgp_: Do you have opinions on the penalty free zone or short term? 02:17:26 My personal opinion is that you need to assume that the penalty free and short term allowances will be filled with spam at near zero cost. Even if that's not what happens in practice, it's important to prepare for as a possibility if the price of XMR is too low to be a meaningful deterrent. 02:17:26 This, I'm for more conservative values there too, but I do understand others' practical desire for a temporary increase due to surge demand. I think it's unrealistic to allow, but if the limit is kept low, then the risk of network harm is minimized enough to the point of "just" being slightly annoying spam 02:19:37 I personally see "cheap surge space" as the same as "cheap spammer space" in practice. But if it's only 2x or whatever and temporary, then there's limited network harm and it's "just" an annoyance 02:20:41 The design goal needs to be that the chosen values can't cause network harm. After that I don't really care 02:36:08 To get to the first penalty free zone number, if probably start with the top ~10% of busiest days of Monero transactions in the last year and pick the penalty free zone weight with fcmps to allow for that. I think that's a reasonable enough place to start 02:39:04 With that, you'd be starting from a generous initial position, while allowing for generous long term growth (but not disastrously large if set to ~1.2), while still allowing short term surges (if you want to still allow those, maybe set to 2x). I really think that's not even a compromise, that's getting all the scaling you could reasonably want 02:45:36 weve never had a sustained full blocks aside from some half baked spam 02:47:32 There have been minutes where the txpool grew to a mb or 2, but never sustained (aside from >1yr old spam) 02:49:24 Right so there's little need to start fcmps with the same capacity even. But I wouldn't be opposed to it if you wanted to maintain the same capacity 03:59:36 https://www.naxo.com/ 04:00:19 Please review the above carefully. Then we can talk > <@boog900> Let's us talk 04:01:51 Pay close attention to the staff , partners and the FAQ particularly with regard to Monero and privacy 04:05:39 By the way this is already all over https://www.reddit.com/r/btc/comments/1p6gs6y/monero_subreddit_purges_all_mentions_that_their/ 04:09:02 ofc that thread has fireice_uk 04:11:11 Can someone point me to a trial where the tracking of XMR provided by a BS company led to a convinction? If the answer is no than all of this is just FUD, and whoever keeps spreading rumors that the devs are selling the secret souce to trace monero should be considerer bad actors 04:11:24 Also the complexity of BS scales as n!/((N-K)!*k!) Where n is the number of outputs in the blockchain and k I the number of allegedly illicit outputs in the block chain 04:12:41 It is not a rumour just go to the site above and do you own research 04:12:58 That is what I did 04:13:58 Yes I know that the people who brought this to my attention are not friends of Monero. 04:14:49 I just have to go with what I read from the source with my own eyes 04:17:08 @articmine: exactly why i won’t believe xmr can be traced, even if the devs are rogue, until i see actual proof in a court case 04:20:05 > <@sgp_> Yeah I don't care as much about the initial M(L) (though I still care somewhat). I care more about preventing it from growing faster than is reasonable. 2x max growth per year should be plenty to allow for ArticMine to support it as a "catching up" function. Even that would literally allow for faster growth than the historical rate of tech advancement 04:20:05 The longer the delisting and suppression of Monero continues the sharper and more drastic the catch up will need to be once BS is put in its place by the courts 04:20:44 @testtank:matrix.org: I do not believe Bitcoin can be traced 04:21:40 That has not prevented this BS industry from making all sorts of claims 04:22:19 Claims that have been very detrimental to Monero 04:26:14 What I do know is that mas scaling of Monero on layer 1 will be the end of BS. The long term growth is the key here hence the conflict of interest 04:26:47 Especially over the long term median growth factor 04:30:28 Given that there are ways of dealing with the very legitimate concerns of many t the devs without touching this parameter, I cannot and will not cave in to this conduct of interest and agree to change the growth rate of ML away from 2 04:46:53 Here is the standard that I use https://www.canada.ca/en/treasury-board-secretariat/services/values-ethics/conflict-interest-post-employment/apparent-conflict-interest.html 04:47:38 I believe that we should meet if not exceed the standard that the state uses 04:52:32 By the way Monero is an international project. So if other people have other conflicts of interest here standards we should choose the stricter standard 05:24:24 As I mentioned before I am working on a solution that will have a realistic chance of getting consensus. 13:51:11 https://www.johndcook.com/blog/2025/11/24/monero-stealth-addresses/ , https://news.ycombinator.com/item?id=46038868 13:59:29 sgp isn't a dev? who are we talking about > <@articmine> By the way this is already all over https://www.reddit.com/r/btc/comments/1p6gs6y/monero_subreddit_purges_all_mentions_that_their/ 14:00:26 regardless, I don't think having a conflict of interest should prevent someone from presenting an idea. people who don't have that conflict are there to evaluate the ideas objectively. 14:04:23 > <@sgp_> Does anyone else want to allow more than 50% or 100% growth a year? 14:04:23 10 MB blocks are working on testnet okay on some real shit ass hardware so the first 10x from 1 MB to 10 MB doesn't seem like thaaaat big a deal, but the next 10x would be very bad for network health I think. in the long run though, 100% (2x) growth YoY would be unsustainable. in 8 years you could be looking theoretically at 256 MB blocks 14:06:34 I think a system could be worked out where short term bursts of block space are possible, but long term growth is still restricted. 14:08:26 I guess by eating the block penalty with higher fees you get, what, up to 2x block size instantaneously? if fees are high enough. so that's your short term burst. would it be feasible to increase that by lowering the penalty, so that by the time you sacrifice the full 0.6 block reward, the block is say 3x the penalty free size? 14:11:20 Assume price doesn’t increase and someone keeps spamming for cents, it will make xmr unusable for most ppl. 14:11:20 Noobs struggle syncing wallet with current block size. 14:14:00 there's a lot of syncing improvements that aren't on mainnet right now but yeah, there's definitely a tention between the desire for low fees and the ability to drive up block size for very cheap 14:15:12 that's why I keep saying the fee market is an important part of restricting block size growth. the growth rate needs to be slow enough that fees are driven up in order to increase block size, implying the demand is more likely to be "real", since people are paying real money for it, not pennies 14:15:56 low fees ---> high fees while blocks grow slowly to meet demand ---> low fees again 14:15:56 but the high fee period is actually important 14:40:10