-
br-m<boog900> @articmine: its really not
-
br-m<boog900> I bet scaling to monerod's limits in the short/medium term still allows a lot of scaling
-
br-m<boog900> also it hasn't worked for 11 years it is broken
-
br-m<boog900> it just hasn't been used
-
br-m<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
-
br-m<articmine> Of course we fix them > <@boog900> we have had vulnerabilities for years should we just not fix them?
-
br-m<ofrnxmr:xmr.mx> Monero has blocks cant go from 300kb to 300mb overnight
-
br-m<boog900> @ofrnxmr:xmr.mx: not by me FWIW
-
br-m<ofrnxmr:xmr.mx> Monero's
-
br-m<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
-
br-m<boog900> I do think current scaling is too fast
-
br-m<ofrnxmr:xmr.mx> I don't know how the current limits work
-
br-m<ofrnxmr:xmr.mx> What the effective max block size is with 100k blocks
-
br-m<ofrnxmr:xmr.mx> @boog900: Short term? Or long?
-
br-m<ofrnxmr:xmr.mx> Short term = 2x median of last 100 blocks, right?
-
br-m<ofrnxmr:xmr.mx> (But is capped somewhere)
-
br-m<ofrnxmr:xmr.mx> Its also not easy to do.
-
br-m<ofrnxmr:xmr.mx> Unless you control majority of the hashpower and have enough outputs
-
br-m<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
-
br-m<ofrnxmr:xmr.mx> Which (ofc) im mining myself, so it costs me nothing
-
br-m<boog900> whatever is allowing us to hit the block size stressnet was seeing > <@ofrnxmr:xmr.mx> Short term? Or long?
-
br-m<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)
-
br-m<boog900> tbf if you mine you can create a miner tx with loads of outputs to yourself
-
br-m<ofrnxmr:xmr.mx> @boog900: Short term. But streasnet has only hit like 12mb (and those are actually misrepresented)
-
br-m<ofrnxmr:xmr.mx> the sum of the tx sizes =! The reported block size. Theres something wrong there
-
br-m<ofrnxmr:xmr.mx> 100x 7kb txs will ahow as like 10mb. Probably some weight vs size issue
-
br-m<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
-
br-m<ofrnxmr:xmr.mx> @boog900: Less than 3000 blocks at lvl 3
-
br-m<boog900> wayy too fast IMO
-
br-m<ofrnxmr:xmr.mx> 1. I think that doesnt make sense
-
br-m<ofrnxmr:xmr.mx> 2. The fees arent enough to justify that imo
-
br-m<ofrnxmr:xmr.mx> I agree with you there. Maybe that 100 block short term median should be 10000
-
br-m<ofrnxmr:xmr.mx> or cap the doubling to once every 2160 blocks or smthn
-
br-m<boog900> honestly I don't think we should be going beyond 10 to 15 MB on the month(s) scale
-
br-m<ofrnxmr:xmr.mx> i can agree with a long term median cap of like 10-15mb, which is 10gb/day
-
br-m<articmine> @boog900: Dropping the surge of the short term median from 50 to 16 will do that
-
br-m<articmine> That is what I proposed
-
br-m<articmine> It caps the short term median at 16 MB for over 2 months
-
br-m<articmine> While not dropping fees
-
br-m<articmine> After growth is limited to 2x for another 50000 blocks
-
br-m<articmine> My existing proposal is actually stricter
-
br-m<boog900> that sounds good, we can agree on the outcome then if we don't agree on the method
-
br-m<boog900> I will have to take a closer look at that proposal
-
br-m<articmine> The reason we need the fast surge is for holiday shopping that can peak in 1-2 days and then drop off
-
br-m<articmine> So we restrict the growth of the short term median rather than making the short term median longer
-
br-m<articmine> The current situation is that the fees don't adjust until long term median changes to deter spam
-
br-m<articmine> This of course stays
-
DataHoardernioc: nanopool api is back and blocks got re-labeled
-
niocthx 4 update
-
br-m<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?
-
br-m<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.
-
br-m<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.
-
br-m<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
-
br-m<monerobull:matrix.org> steam also stopped bcs of fungibility
19 minutes ago