00:00:50 @articmine: its really not 00:01:23 I bet scaling to monerod's limits in the short/medium term still allows a lot of scaling 00:02:19 also it hasn't worked for 11 years it is broken 00:02:25 it just hasn't been used 00:03:11 its not black and white. I don't essentially killing scaling, and i don't support 100% balls to the wall, unrestricted scaling. The latter isnt proposed, the the former is 00:03:21 Of course we fix them > <@boog900> we have had vulnerabilities for years should we just not fix them? 00:03:38 Monero has blocks cant go from 300kb to 300mb overnight 00:03:47 @ofrnxmr:xmr.mx: not by me FWIW 00:03:52 Monero's 00:05:01 The insinuation that we want to be able to instantly produce a 1tb block isnt based in reality or proposed, nor |is it possible 00:05:27 I do think current scaling is too fast 00:05:30 I don't know how the current limits work 00:05:45 What the effective max block size is with 100k blocks 00:06:01 @boog900: Short term? Or long? 00:06:27 Short term = 2x median of last 100 blocks, right? 00:06:42 (But is capped somewhere) 00:07:04 Its also not easy to do. 00:07:33 Unless you control majority of the hashpower and have enough outputs 00:08:09 Example: on fcmp, with a few hundred thousand xmr, i can only produce a few 40mb blocks before all of my funds are locked up for 60 blocks 00:08:41 Which (ofc) im mining myself, so it costs me nothing 00:10:03 whatever is allowing us to hit the block size stressnet was seeing > <@ofrnxmr:xmr.mx> Short term? Or long? 00:10:10 The cost of a scaling attack requires mining all of your inputs, else youll rin out of steam (since emission would be 0) 00:10:34 tbf if you mine you can create a miner tx with loads of outputs to yourself 00:10:39 @boog900: Short term. But streasnet has only hit like 12mb (and those are actually misrepresented) 00:11:19 the sum of the tx sizes =! The reported block size. Theres something wrong there 00:11:53 100x 7kb txs will ahow as like 10mb. Probably some weight vs size issue 00:12:13 how long does it take for 40 mb blocks? > <@ofrnxmr:xmr.mx> Example: on fcmp, with a few hundred thousand xmr, i can only produce a few 40mb blocks before all of my funds are locked up for 60 blocks 00:12:37 @boog900: Less than 3000 blocks at lvl 3 00:13:21 wayy too fast IMO 00:13:35 1. I think that doesnt make sense 00:13:35 2. The fees arent enough to justify that imo 00:14:10 I agree with you there. Maybe that 100 block short term median should be 10000 00:15:26 or cap the doubling to once every 2160 blocks or smthn 00:15:35 honestly I don't think we should be going beyond 10 to 15 MB on the month(s) scale 00:18:48 i can agree with a long term median cap of like 10-15mb, which is 10gb/day 00:18:50 @boog900: Dropping the surge of the short term median from 50 to 16 will do that 00:19:08 That is what I proposed 00:21:29 It caps the short term median at 16 MB for over 2 months 00:22:05 While not dropping fees 00:24:07 After growth is limited to 2x for another 50000 blocks 00:25:09 My existing proposal is actually stricter 00:25:53 that sounds good, we can agree on the outcome then if we don't agree on the method 00:26:18 I will have to take a closer look at that proposal 00:27:46 The reason we need the fast surge is for holiday shopping that can peak in 1-2 days and then drop off 00:28:59 So we restrict the growth of the short term median rather than making the short term median longer 00:31:08 The current situation is that the fees don't adjust until long term median changes to deter spam 00:31:26 This of course stays 00:42:22 nioc: nanopool api is back and blocks got re-labeled 00:42:44 thx 4 update 10:59:52 There are people with serious money who want governments to rule Monero: > <@blurt4949:matrix.org> If Monero relies on government approval then it's useless to begin with so I don't follow? 10:59:52 > googlemozilla: I would rather trust a government institution overseeing CCS than relying on some random core members in Monero to manage it, for example. Officials in core can be elected democratically, which is a thinking long-term approach. Remember, governments are filled with people making decisions. Not robots. 11:11:49 Being too small is catastrophic, and Monero should be able to scale to existing payment networks. The reason Microsoft, Steam, and other vendors stopped accepting BTC is scaling and fee concerns. If Monero wants to be cash, it has to scale like existing networks. It's been 10 years since 2014, and Monero is no longer a pet project. > <@boog900> one is catastrophic one is not. 11:11:49 Finding a solution is way above my paygrade, though, and I don't know if it's even possible. I'll be watching the next MRL meeting closely as I consider scaling to be the second most important issue after privacy 12:19:40 steam also stopped bcs of fungibility 13:15:40 Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition 13:15:40 https://tee.fail/ 13:20:25 uhohs 13:22:01 Uniswaps L2 uses TEE's 13:32:05 I think the most notable comment is the additional forgery of attestations. 13:34:23 @basses:matrix.org: AMD not attempting to mitigate the SEV issue is very telling of their strategy. SEV-SNP are TEE on paper but their entire marketing, documentation and specifications shows that SEV is for VM/Hypervisor protection, software only. Yet people are often comparing these to intel SGX. They are just not for th [... too long, see https://mrelay.p2pool.observer/e/mJ6yzcMKbGM0SDZa ] 13:35:10 Literally all the CPUs supporting SEV supports SME 13:35:34 or if not SME, at least TSME 13:39:55 (they extracted keys, so they can attest) > I think the most notable comment is the additional forgery of attestations. 15:01:05 kayabanerve: There is a dev draft of the FCMP++ protocol considered the FCMP++ paper >>> yes, I meant that "fcmp++.pdf" in your repo 15:02:56 torir: Start with how Zero Knowledge proofs work: https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer [...] >>> Nice article! I need more building blocks towards FCMP++ papers and IACR papers. 15:03:22 btw I didn't fully understand this "proof of zero-knowledness" though 15:04:12 this -> "Verifier succeeds in extracting information after running the real protocol, then it should be able to extract the same amount of information from the simulated, rewinding-based protocol. But since there’s no information going into the simulated protocol, there’s no information to extract. Thus the information the Verifier can extract must always be zero." 17:22:57 https://x.com/MoneroKon/status/1983576553033224588 19:19:17 https://www.youtube.com/watch?v=dcivgUwlaRw 19:19:36 Livestreamed CS research meeting 22:33:06 nice, I enjoyed your recent appearance on Monero Talk 23:19:19 > <@namenet:matrix.org> Being too small is catastrophic, and Monero should be able to scale to existing payment networks. The reason Microsoft, Steam, and other vendors stopped accepting BTC is scaling and fee concerns. If Monero wants to be cash, it has to scale like existing networks. It's been 10 years since 2014, and Monero is no longer a pet project. 23:19:19 The scaling formulas to do this are already in place. They have been for a whli 23:19:37 While. 23:23:22 This being said there are people who are very uniformed about how scaling in Monero actually works. There are also those who would rather keep peer to peer in Monero very small in size. 23:23:22 My experience on this in the past is that it has been quite a fight to get the consensus for proper scaling. 23:24:28 I have worked on Monero scaling for close to a decade