01:09:40 I commented on it @jeffro256:monero.social but https://github.com/seraphis-migration/monero/pull/250 has similar issues as on https://github.com/seraphis-migration/monero/pull/245 01:25:38 New changes on #245 converge to the ones in my go implementation as well :) 01:41:43 Yes this works as a scaling cap. It is very easy to add to my proposal 01:43:22 https://github.com/monero-project/research-lab/issues/155 01:43:22 I am referring to the above 06:25:08 I have updated my proposal to incorporate the above sanity cap with slightly tighter parameters. 06:26:05 https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-01.pdf 07:17:13 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. 11:18:46 It is the lower of the adaptive block weight and the sanity limit. 11:19:27 That is the point of a sanity limit 11:21:50 ... and why it works 12:49:29 small note AM for the future commas or exponential notation would keep me from sitting here counting 6 or 7 zeros after a number 12:52:50 so in 10 years we're looking at roughly max 250 MB blocks, is that right? 12:55:32 Correct 12:57:30 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 12:57:36 which is a notable improvement for sure 13:00:55 I am disappointed that this very clearly moves by itself after you were very clear yesterday @articmine:monero.social that it wouldn't. 13:01:04 I was correct to be suspicious 13:01:33 @boog900: You are ignoring the existing scaling 13:01:48 This is a cap 13:01:52 No I am not. Do not twist my question 13:01:58 Was not* 13:02:04 Let me get the logs 13:02:38 https://libera.monerologs.net/monero-research-lounge/20251202#c621117 13:02:39 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? 13:02:40 You have to look at the entire equation 13:02:59 Very clearly I was talking about specifically the sanity cap 13:03:15 @boog900: No I was not 13:03:29 I meant the block weight 13:03:36 To try and twist my question to mislead people is very disappointing 13:03:38 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. 13:03:53 @spackle: No 13:03:54 @articmine: Yes you were not but I clearly was 13:05:06 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 13:05:06 in case that's a helpful reference for anyone, it helps me to think about it, thinking backwards instead of forwards 13:05:07 @spackle: There is a cost 13:05:30 we know there is a cost but that doesn't mean it can't be "at almost any time" 13:05:57 @articmine: As discussed earlier, I am not interested in making a short term network breaking expensive, I am interested in preventing it entirely. 13:06:13 Short term again, meaning without moving the long term median. 13:06:44 @spackle: This has at been the case 13:06:47 Anyway, I trust readers to understand my meaning. 13:07:37 You either want peer to peer cash or not 13:08:23 Yes we have to deal with BS suppression of Monero 13:08:41 @articmine: a global peer to peer cash network will need a Level 2, you can't just sidestep the blockchain trilemme with scaling 13:08:58 @monero.arbo:matrix.org: No it does not 13:09:28 sure, recording every transaction on the planet forever makes sense :/ 13:09:58 how many transactions is 32mb 13:10:20 32 transactions per second 13:10:23 This is effectively a block size bomb and I will not support it over a proper limit that moves with sufficient activity. 13:11:18 I am not wasting any more time on this 13:11:33 @articmine: right now we are at 100 times less than that 13:11:55 Correct 13:12:39 @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) 13:13:34 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 13:13:51 I can see the BS conflict of interest behind the scenes here 13:13:59 I know, it's the lesser of the two parameters, but the conversation is about whether both shoudl take TX volume to scale 13:14:12 This is what this is really about 13:14:15 Please be specific of whom you are accusing, and of what exactly you are accusing them. 13:14:40 Those who fear peer to peer cash 13:16:34 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 13:16:54 @monerobull:matrix.org: If course 13:17:08 If course 13:17:16 We're probably having that war rn 13:17:19 Agreed, I also oppose the 32 MB hard limit proposal. 13:17:38 can we time-lock it 13:17:49 We can do anything we agree on 13:17:58 put some dynamic scaling on it that only activates after 5 years? 13:18:16 that would prevent a war later on 13:18:19 10.8mb this yr is 15mb next yr, 21mb in 2027, 29mb is 2028 etc (using 1.4) 13:18:32 because we are not hard-locked into a specific limit 13:18:55 @monerobull:matrix.org: It is the same issue. One can allow growth or not. One cannot do both 13:18:58 Is 10.8mb is acceptable right now, i see no reason to assume that 29mb wont be equally as feasible in 2028 13:19:13 If* 10.8 13:19:42 @ofrnxmr:xmr.mx: I don't think compute is growing that fast... 13:19:45 @articmine: one can have limits based on reality 13:20:11 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 13:20:16 was 3 MB the limit in 2022? 13:20:20 @monerobull:matrix.org: This IS based on reality 13:20:27 if you have zero limits you end up like BTCSV 13:20:41 @monero.arbo:matrix.org: No, it was virtually unlimited 13:21:04 @monerobull:matrix.org: Youre not paying attention. There are limits. 1.4x per year 13:21:05 They have demonstrated 4 GB blocks 3 years ago 13:21:22 @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 13:21:53 again I find it easier to think about these things by projecting backwards because we KNOW what tech was like then 13:21:57 @monero.arbo:matrix.org: could have been* and yea, 3 years ago we could have handled 3mb 13:22:33 @monero.arbo:matrix.org: You mean like 2MB in 1979? 13:23:00 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 13:23:49 @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 13:24:11 @monero.arbo:matrix.org: Tevadors numers are below neilsons law of 1.5, so the numbera are below what they would otherwise be 13:24:19 @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)? 13:24:46 @spackle: That is what i am implying, yes 13:25:07 @ofrnxmr:xmr.mx: ah well my concern from the start has been more about compute than bandwidth 13:25:09 Are you comfortable saying it directly? 13:25:54 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. 13:26:21 We will need to split the chain like Bitcoin. Only in this case the fork is the small block supporterd 13:27:06 The master daemon has a couple bugfixes to be upstreamed, but with these bug fixes, yes monerod can handle 16 mb today 13:27:26 I also recommend Roger Vet's book. Highjacking Bitcoin 13:27:37 Roger Ver 13:27:39 To be clear, I don't mean a single block. I mean a steady stream of 16 MB blocks. 13:27:40 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) 13:28:06 @spackle: Yeah, same 13:29:27 @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 13:29:36 @boog900: yeah raising M_L from 1.7x to 2x does allow very fast growth within these bounds, for sure 13:29:42 BS companies 13:29:55 @monero.arbo:matrix.org: That is the point 13:30:11 I mean yes it is your point but I also udnerstand the concern 13:30:55 Then why fight this proposal? 13:32:07 The fact is that Monero has been suppressed for close to a decade. So has Bitcoin and I also suspect Ethereum 13:32:08 I did say it's better but doesn't mean I'm giving uncritical support, why would it 13:32:08 @monero.arbo:matrix.org: I think there should still be a cap of 1.4x the cap of 262800 blocks prior 13:32:35 @ofrnxmr:xmr.mx: those are the "bounds" I meant 13:33:20 @ofrnxmr:xmr.mx: Then you hard code the BS suppression into the consensus 13:33:29 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" 13:33:59 @articmine: bruh 13:34:34 1.4x growth per year is generous 13:35:07 @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 13:35:24 @monero.arbo:matrix.org: Not after 10 years of suppression 13:35:34 @ofrnxmr:xmr.mx: ^ 13:35:48 Suppression doesnt matter if the cap grows regardless of activity 13:36:17 @ofrnxmr:xmr.mx: It allows catching up 13:36:19 @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 13:36:34 providing more capacity than the network can handle helps preciciely nobody except people who want to see Monero fail 13:36:44 It actually is not 13:37:59 Realistically we need a chain split 13:38:07 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 13:38:11 and now he keeps proposing chain splits 13:38:20 while calling OTHERS the destructive ones 13:38:27 go split the chain then bro 13:39:15 It will happen. It happened in Bitcoin 13:39:54 I got.out before it happened in Bitcoin. 13:40:04 I saw it coming 13:40:45 Unfortunately I also see it here. 13:41:41 😂 13:42:52 @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. 13:43:57 I will NOT split this chain but I do not believe a split can be stopped 13:48:47 at the end tevador's issue referenced by AM https://github.com/monero-project/research-lab/issues/155 he states .... 13:48:59 Verification time constraints 13:48:59 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. 13:49:15 is this being taken into account? 13:50:36 and as far as being for or against p2p cash, without a functioning network you can't have it 13:53:17 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? 13:55:35 ofc we need a certain # of txs, the question is how many? Transparent chain vs Monero 13:55:53 *Monero with FCMP++ 14:06:12 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 https://mrelay.p2pool.observer/e/3-ag8M4KUDhNcTU1 ] 14:06:39 Does what I just wrote seem incorrect to you? 14:11:26 Blocks should be over 10mb in a couple hrs and you'll be able to see for yourself 14:13:09 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. 14:13:58 Afaik, you dont reverify txs that are in blocks 14:14:34 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 14:14:50 But the (fluffy)block itself is not 16mb 14:15:14 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? 14:15:40 Meaning that the will need to verify transactions at the rate of block production. 14:15:52 single threaded node would take 93 seconds even if the block is never mined - they verify txs in the pool 14:16:54 Yes, and it follows that they will need to verify txs in the pool at the rate of block production. Does it not? 14:18:09 Are we assuming a txpool that grows at 16mb / 120seconds? If so, sure 14:18:34 nioc: Is the current Monero more private than Pirate Chain? This is a valid question. 14:18:36 If the txpool grows at 32mb/120seconds, no. They have to verify 32mb/120seconds 14:18:37 That would seem be a requirement of producing a steady stream of 16MB blocks. 14:19:01 @spackle: A minimum* requirement 14:19:27 Theres nothing stopping txs from being produced at 40mb per minute (as an example) 14:20:02 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. 14:20:29 It follows that this node can spent, at maximum, 27/120 seconds on actual mining. 14:20:50 A single threaded* node 14:21:16 Yes 14:22:54 Mining on monerod is paused while adding blocks to the the chain, but i don't think its paused while verifying txs 14:23:08 You just wouldnt include txs that arent verified in the template 14:29:04 ^ if mining via xmrig or p2pool the miners keep mining 14:29:17 using the old template, as monerod has not published a new one 14:29:30 or not even template, has not published new miner data 14:30:29 I see your point. 14:30:32 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 14:30:52 that caused already quite a few diverging forks in stressnet as well 14:31:30 at some point it was ~25s before new miner data was ready on a 9900X3D locally 14:31:58 Yeah i think that was fixed by relaying empty fluffyblock (?) 14:32:04 this has improved in recent versions, but it's still a major part of wasted proof of work during large blocks 14:32:15 otherwise the nodes disconnected from one another 14:32:17 the issue is local ofrnxmr 14:32:32 like, even if not connected to network, the templates take quite long to verify 14:32:45 specially when monero itself provided the valid txs already to be used 14:33:14 Ive been mining with xmrig without issue for a while now. I had a lot of issues on older versions of stressnet 14:33:25 you find no issues, just "delays" 14:33:45 see when xmrig finds a share 14:33:47 and when it receives a new job 14:34:15 I mean, on older versions monerod would return bad data while it was broadcasting the block 14:34:47 yeah on ZMQ it just sent nothing, it wasn't even RPC polling 14:35:16 Hasnt happened in quite a few weeks now 14:35:16 Which would lead to me mining invalid or rejected shares 14:35:17 I mean, on older versions monerod would return bad data while it was broadcasting the block 14:37:22 (fwiw, i think im just using rpc) 14:43:57 it uses rpc indeed 14:50:22 > <@articmine> https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-01.pdf 14:50:22 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. 14:50:22 I still don't like the way the fee market is handled, but at least the proposal probably won't kill Monero anymore 15:31:55 How old are single thread processors? > <@ofrnxmr> A single threaded* node 15:32:12 Like 2002? Lol 15:32:12 Seriously 15:34:24 Probably older actually, i think we had dual core processors before y2k 15:37:17 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 15:38:36 these numbers also would imply that a 16 thread system would take 93 seconds to verify 256mb 15:42:04 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. 15:52:31 Monero's multithreading has a very silly default config of 4 threads 15:53:01 Changing this to max threads increases sync speed by 40-70% 15:54:02 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 15:54:52 @ofrnxmr: its not just that, monero takes locks in places too, like when adding a tx to the pool 15:54:57 This is without checkpoints and im not sure if it effects tip/tx syncing, or if its only relevant for syncing batch txs / blocks 15:55:44 @boog900: changing this is going to be harder as you need to make sure data stays in sync 15:56:10 @boog900: My main point is that "catch-up" sync or ibd w/o checkpoints is much faster with more threads 15:58:58 @spackle: I have been arguing this for years. It is not an excuse to throttle scaling 16:00:37 Has block size been an actual limit to transaction throughput yet? 16:01:08 scaling has only been activated like once during the last spam wave 16:01:26 even then it didn't even really move 16:02:20