<boog900> @articmine: its really not

<boog900> I bet scaling to monerod's limits in the short/medium term still allows a lot of scaling

<boog900> also it hasn't worked for 11 years it is broken

<boog900> it just hasn't been used

<ofrnxmr:xmr.mx> 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

<articmine> Of course we fix them > <@boog900> we have had vulnerabilities for years should we just not fix them?

<ofrnxmr:xmr.mx> Monero has blocks cant go from 300kb to 300mb overnight

<boog900> @ofrnxmr:xmr.mx: not by me FWIW

<ofrnxmr:xmr.mx> Monero's

<ofrnxmr:xmr.mx> The insinuation that we want to be able to instantly produce a 1tb block isnt based in reality or proposed, nor |is it possible

<boog900> I do think current scaling is too fast

<ofrnxmr:xmr.mx> I don't know how the current limits work

<ofrnxmr:xmr.mx> What the effective max block size is with 100k blocks

<ofrnxmr:xmr.mx> @boog900: Short term? Or long?

<ofrnxmr:xmr.mx> Short term = 2x median of last 100 blocks, right?

<ofrnxmr:xmr.mx> (But is capped somewhere)

<ofrnxmr:xmr.mx> Its also not easy to do.

<ofrnxmr:xmr.mx> Unless you control majority of the hashpower and have enough outputs

<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

<ofrnxmr:xmr.mx> Which (ofc) im mining myself, so it costs me nothing

<boog900> whatever is allowing us to hit the block size stressnet was seeing > <@ofrnxmr:xmr.mx> Short term? Or long?

<ofrnxmr:xmr.mx> The cost of a scaling attack requires mining all of your inputs, else youll rin out of steam (since emission would be 0)

<boog900> tbf if you mine you can create a miner tx with loads of outputs to yourself

<ofrnxmr:xmr.mx> @boog900: Short term. But streasnet has only hit like 12mb (and those are actually misrepresented)

<ofrnxmr:xmr.mx> the sum of the tx sizes =! The reported block size. Theres something wrong there

<ofrnxmr:xmr.mx> 100x 7kb txs will ahow as like 10mb. Probably some weight vs size issue

<boog900> 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

<ofrnxmr:xmr.mx> @boog900: Less than 3000 blocks at lvl 3

<boog900> wayy too fast IMO

<ofrnxmr:xmr.mx> 1. I think that doesnt make sense

<ofrnxmr:xmr.mx> 2. The fees arent enough to justify that imo

<ofrnxmr:xmr.mx> I agree with you there. Maybe that 100 block short term median should be 10000

<ofrnxmr:xmr.mx> or cap the doubling to once every 2160 blocks or smthn

<boog900> honestly I don't think we should be going beyond 10 to 15 MB on the month(s) scale

<ofrnxmr:xmr.mx> i can agree with a long term median cap of like 10-15mb, which is 10gb/day

<articmine> @boog900: Dropping the surge of the short term median from 50 to 16 will do that

<articmine> That is what I proposed

<articmine> It caps the short term median at 16 MB for over 2 months

<articmine> While not dropping fees

<articmine> After growth is limited to 2x for another 50000 blocks

<articmine> My existing proposal is actually stricter

<boog900> that sounds good, we can agree on the outcome then if we don't agree on the method

<boog900> I will have to take a closer look at that proposal

<articmine> The reason we need the fast surge is for holiday shopping that can peak in 1-2 days and then drop off

<articmine> So we restrict the growth of the short term median rather than making the short term median longer

<articmine> The current situation is that the fees don't adjust until long term median changes to deter spam

<articmine> This of course stays

nioc: nanopool api is back and blocks got re-labeled

thx 4 update

<namenet:matrix.org> 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?

<namenet:matrix.org> > 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.

<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. > <@boog900> one is catastrophic one is not.

<namenet:matrix.org> 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

<monerobull:matrix.org> steam also stopped bcs of fungibility

<basses:matrix.org> Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition

<basses:matrix.org> tee.fail

uhohs

Uniswaps L2 uses TEE's

<kayabanerve:matrix.org> I think the most notable comment is the additional forgery of attestations.

<syntheticbird> @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 mrelay.p2pool.observer/e/mJ6yzcMKbGM0SDZa ]

<syntheticbird> Literally all the CPUs supporting SEV supports SME

<syntheticbird> or if not SME, at least TSME

(they extracted keys, so they can attest) > I think the most notable comment is the additional forgery of attestations.

kayabanerve: There is a dev draft of the FCMP++ protocol considered the FCMP++ paper >>> yes, I meant that "fcmp++.pdf" in your repo

torir: Start with how Zero Knowledge proofs work: blog.cryptographyengineering.com/20…knowledge-proofs-illustrated-primer [...] >>> Nice article! I need more building blocks towards FCMP++ papers and IACR papers.

btw I didn't fully understand this "proof of zero-knowledness" though

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."

<diego:cypherstack.com> youtube.com/watch?v=dcivgUwlaRw

<diego:cypherstack.com> Livestreamed CS research meeting

<sneedlewoods_xmr:matrix.org> nice, I enjoyed your recent appearance on Monero Talk

<articmine> > <@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.

<articmine> The scaling formulas to do this are already in place. They have been for a whli

<articmine> While.

<articmine> 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.

<articmine> My experience on this in the past is that it has been quite a fight to get the consensus for proper scaling.

<articmine> I have worked on Monero scaling for close to a decade