<gingeropolous> no that prolly is right

<articmine> The long term median has not moved since it was created in 2019

<articmine> So over six years ago

<gingeropolous> the short term median has perhaps moved.... once?

<articmine> A few times and then rest

<articmine> Reset

<articmine> During the last hard fork there was a pool that shut down. Then there was spam attacks that gave up slightly into the penalty

<gingeropolous> i mean yeah. i don't know really know why the lack of movement is relevant, this is indeed why these simulators would be great. so we can see how the system actually responds.

<articmine> Monero transaction rate has been essentially flat for like 6 years

<articmine>

<articmine> What I see here is dynamic equilibrium between the growth of the peer to peer decentralized / DEX market and the suppression of Monero from centralized exchanges due to the lobbying of governments by the blockchain surveillance (BS) industry.

<articmine> A sudden collapse of BS in the courts could disturb this equilibrium and trigger a sharp increase in on chain Monero transactions

<articmine> bitinfocharts.com/comparison/monero-transactions.html#log&alltime

<articmine> The current XMR / USD and XMR / BTC trends are also highly indicative of a sharp increase in price which would also trigger a sharp increase in on chain Monero transactions.

<articmine> @gingeropolous: The lack of movement is relevant in that it indicates the suppression of Monero. Remove the suppression and a sharp move is likely

<articmine> In on chain transactions

<boog900> I think the fact monero's scaling has only been activated like once because of spam and even then it barely moved shows we don't need to plan for 1024x growth in a year.

<boog900> or even 813x like current scaling allows

<boog900> like in what world is that realistic?

<ofrnxmr:xmr.mx> Is that 813x 300kb? Or 813x 25k tx/day

<boog900> 813 * 300 kb

<ofrnxmr:xmr.mx> 300kb is already like 5x

<ofrnxmr:xmr.mx> @boog900: Lol

<boog900> 1024 is for artics FCMP proposal

<boog900> which would lead to gigabyte blocks in a year

<ofrnxmr:xmr.mx> It would take over 2min to upload that block to just 1peer

<boog900> probably an hour to verify

<jeffro256> @articmine: That is fair, but perhaps you are conflating the scaling parameters themselves with the activity uptick with defeating the BS companies in the courts. The scaling parameters are NOT the bottleneck for adoption, the regulatory environment brought on by BS companies and fearmongering politicians is. The BS compan [... too long, see mrelay.p2pool.observer/e/6bLArM0KOW1NRFRF ]

<jeffro256> We can't engineer monerod fast enough for a 800x increase in tx volume to be usable

<boog900> Yeah and to think this is the case right now is scary IMO

<ofrnxmr:xmr.mx> 16mb blocks is 11gb/day

<articmine> There are alternatives such as a soft fork cap on the blocksize growth

<articmine> There is no need to bake obsolescence into the consensus protocol over otherwise valid concerns regarding a sudden growth

<articmine> Such a soft fork can buy time to address these current code issues

<articmine> By the way. 1 GB at the end of this year is equivalent to 1 MB when the Bitcoin whitepaper was released in 2008

<articmine> I do agree that the current scaling policy would deal with the likely surge in adoption if there is a collapse of BS

<boog900> we can just set the parameters less aggressive > <@articmine> There is no need to bake obsolescence into the consensus protocol over otherwise valid concerns regarding a sudden growth

<boog900> instead of 1024x maximum growth in a year, 100x for example

<boog900> it still allows a massive sudden growth, just while also allowing us time to prepare the system

<boog900> gigabyte blocks in a year is silly

<boog900> why are we increasing the maximum yearly growth rate with FCMP?

<articmine> That is best done with either a long term sanity median over 1000000 blocks of a block size cap pegged to Nielsen's Law > <@boog900> instead of 1024x maximum growth in a year, 100x for example

<boog900> assuming exponential growth of our capacity is not a good idea

<boog900> just spit-balling but would there be anything technically wrong with keeping the scaling equations the same and changing the short term median growth rate to 8 and long term median to 1.4?

<boog900> not looking for if this supports as many txs as you want, just if this would work

<articmine> @boog900: What you have just proposed is actually more aggressive than what I just proposed. Furthermore it would not work

<boog900> aggressive in what way?

<boog900> build up to max size or max size?

<articmine> The annual compounding rate is hit than 50%

<articmine> Higher than 50%

<articmine> It is not about the maxed out growth, it is about the variability in grothi

<articmine> Nielsen' Law is a good choice because it reflects the historical growth in bandwidth, and is below the historical growth rate of computing power and storage

<articmine> If this is done via a Soft fork then it is easy t tighten or relax in the future

<articmine> In fact one can set this up so that it would require over 50 of the hashrate to override

<articmine> 50% of the hashrate

<boog900> ok so your proposal would lead to larger blocks if someone was to produce maximum size blocks under both proposals > <@articmine> It is not about the maxed out growth, it is about the variability in grothi

<boog900> right?

<boog900> assuming the same penalty free zone too

<articmine> Not with a soft fork cap

<articmine> Way lower

<boog900> THATS NOT IN YOUR PROPOSAL

<boog900> so by my definition that makes your proposal more aggressive

<boog900> as it can reach a higher block size given the same time period

<boog900> much higher

<articmine> It was originally conceived with a sanity median cap > <@boog900> THATS NOT IN YOUR PROPOSAL

<boog900> the document you proposed did not contain it I don't know why you are trying to argue this

23:52:34 <br-m> <articmine> In fact one can set this up so that it would require over 50 of the hashrate to override

great, another non-profit-fueled Qubic-like entity to override :D

<articmine> I know

<articmine> Qubic would not have been able to override

<boog900> ok now we have that settled, why wont it work? > <@articmine> What you have just proposed is actually more aggressive than what I just proposed. Furthermore it would not work

<articmine> You need to keep this up for months in order to move the long term median. That is with a sustained over 50 of the hashrate over that period of time

<articmine> Because one can easily have a 30% surge a few months filled by nothing

<boog900> @articmine: selfish mining gives you more than 50% of the blocks for less than 50% of the hash rate

<articmine> Followed

<articmine> @boog900: For how long

<articmine> ?

<boog900> forever, there is an equation, 51% of hashrate gives you 100% of blocks with selfish mining

<boog900> its like from 33% you can get more blocks than you should up to 50% with selfish mining.

<articmine> You can also HF to a massive penalty free zone like 1GB BSV

<articmine> With 51% over months

<articmine> This makes this entire discussion moot

<boog900> @articmine:monero.social: can you tell me what is technically incorrect with my proposal

<articmine> Let us say we have 10 over 2 months

<articmine> 10x

<boog900> ok so your problem is that it doesn't support enough growth?

<articmine> By now growth for the following year

<articmine> Bo

<articmine> No

<articmine> No growth for a year then sharp growth for 2 months, then no growth for 6 months etc

<articmine> Just look at t Monero just. Five years of over 80x growth followed by 5 yt of no groy

<articmine> 5 years

<articmine> Of no growth

<articmine> Litecoin 100x in one year then very little

<boog900> my proposal supports 100x growth in a year

<boog900> even though I still think that is unrealistic

<boog900> when you have very little txs adding more is easy

<boog900> @articmine: so your only concerns are around the amount of growth it allows?

<articmine> My primary concern is about the variability in growth

<monero.arbo:matrix.org> that's 2 million transactions a day lmao > <@boog900> my proposal supports 100x growth in a year

<articmine> It did happen in Litecoin when Bitcoin seized up

<articmine> 8/ 1.4 will not address the need of both the big blockers and small blockerd

<articmine> Both loose

<boog900> @articmine: nah it will, some more numbers:

<monero.arbo:matrix.org> > <@articmine> My primary concern is about the variability in growth

<monero.arbo:matrix.org> why is a temporary fee market in times of large growth bad? genuinely seems like supply and demand to me. you high fees to actually drive up the block size anyway. I think instead of quickly responding to demand by dramatically increasing block size, there should need to be a sustained period to show it's not just a transient surge

<monero.arbo:matrix.org> I thought that was the whole way it was supposed to work

<articmine> We have a fee market

<boog900> Penalty free zone: 750,000

<boog900> Max size before long term adjusts: 12,000,000

<boog900> Max block size in 1 year: 90,354,432

<boog900> seems pretty perfect to me

<articmine> If you mean the Bitcoin mess that will kill peer to peer transactions just like it did in Bitcoin

<boog900> staying under the 100 mb packet limit in under a year is great

<monero.arbo:matrix.org> ArcticMine nobody means "the bitcoin mess" I am starting to feel you are being disengenuine about this

<monero.arbo:matrix.org> you seem to be the only one arguing for scaling paramters this large as well

<articmine> The way to do this is with a cap on to of my proposal

<boog900> @monero.arbo:matrix.org: its his way or the highway

<monero.arbo:matrix.org> @boog900: yes, he seems to think he can hold the whole project hostage by witholding consensus on anything that doesn't allow extreme scaling

<boog900> this is for FCMP FWIW > <@boog900> Penalty free zone: 750,000

<articmine> I am quite prepared to acct a 50x cap over a year

<articmine> On the blocksize

<monero.arbo:matrix.org> 50x per year is disastrous

<articmine> Then 1.5 per year

<boog900> I like my proposal now :)

<articmine> Not per year

<monero.arbo:matrix.org> we are not going to grow from 25k tx/day to over 1.2 million organically in a year

<monero.arbo:matrix.org> ?

<articmine> How do you kbt that!

<articmine> How do you know that?

<monero.arbo:matrix.org> @articmine: point out where it has ever happened to any project ever

<monero.arbo:matrix.org> I can't literally predict the future, but you are being unreasonable

<articmine> I said Litecoin 100x in a year

<monero.arbo:matrix.org> again, ETH only does 1.5 million and most of these are DeFi type transactions, not payments

<boog900> @monero.arbo:matrix.org: you see before monero: 0txs a year

<boog900> after the first tx: 1 tx a year

<boog900> infinite growth is needed

<monero.arbo:matrix.org> @articmine: going from 1000 a day to 100,000 a day doesn't count

<articmine> Why?

<monero.arbo:matrix.org> because it's easier for a smaller network to grow rapidly

<monero.arbo:matrix.org> there is no chain that organically does a million payment transactions per day, not a single one

<monero.arbo:matrix.org> maybe BTC if you count lightning

<articmine> It is actually the same if one factor in Nielsen's Law. This happened 8 years ago. So 1000 to 100000 is the same as 25000 to 2500000 > <@monero.arbo:matrix.org> going from 1000 a day to 100,000 a day doesn't count

<ravfx:xmr.mx> LN have that much?

<ravfx:xmr.mx> Last time I did a test run it was still garbage tier

<articmine> The one thing that small blockers always forget is that the goalposts are changing against their position whilst they argue

<boog900> the thing that unrealistic blocks always forget is that scaling has pretty much never been activated

<articmine> In Monero because of BS

<boog900> does litecoin have a dynamic block size?

<articmine> No

<articmine> Just larger empty blocks

<boog900> so someone could have just spammed the chain for thoes blocks then?

<boog900> ( the big ones)

<boog900> and also my proposal supports this amount of growth in a year

<articmine> Take a look at the price

<boog900> your proposal supports 10x it

<articmine> No

<articmine> It was not spamming

<articmine> Do you have any idea what it would cost to Monero just to get a 4x in the long term median under my proposal!

<articmine> Spam Monero

<articmine> Vs say Litecoin

<boog900> I hate this argument

<boog900> Its too expensive it'll never happen! Just restrict it then.

<boog900> A miner just has to mine >50% of blocks

<articmine> It is too expensive to spam but I ham can happen

<boog900> and/or spam at the same time to compensate

<boog900> @articmine: at 1000x?

<articmine> @boog900: Depends the timeframe

<boog900> my proposal supports 100x in a year which is already crazy

<boog900> @articmine: year

<kayabanerve:matrix.org> I think we should limit Monero to one TX per block to encourage off-chain settlement solutions /s

<kayabanerve:matrix.org> Since the protocol isn't stagnant and isn't ossifying, while dynamic scaling is a goal and should be present, I don't believe any 'too small' parameters risk killing Monero

<kayabanerve:matrix.org> But too large parameters could bring the net down, see all the work done in response to the stressnet

<articmine> @boog900: That is not crazy what is crazy is over 5x per year vs 1.5x

<kayabanerve:matrix.org> We should scale. We should scale conservatively and adjust instead of trying to be ready for a decade from now today

<kayabanerve:matrix.org> If we think hardware will get faster, and our node will improve, we can align to current expectations of performance (not expectations of desired use), and if usage exceeds our capacity, that isn't a failing of scaling parameters. That's a failure of the node's performance and attempts to overload a single chokepoint, the Monero L1.

<kayabanerve:matrix.org> Scaling parameters beyond our performance are just pointless other than as a risk to the network's safety.

<kayabanerve:matrix.org> Even if the protocol literally allows it, the fact nodes won't practically perform it makes it irrelevant

<articmine> What I am suggesting is capping scaling at 50% year after on year of up to 100x

<articmine> One year

<kayabanerve:matrix.org> inb4 I advocate literally no scaling changes other than a 5x bump from RingCT to FCMP (or whatever it is) to point how absurd the contention has gotten

<articmine> Also if done via a soft fork ) miner voting this can be easy adjustment as needed up or down

<articmine> @kayabanerve:matrix.org: I am fine t that

<boog900> @kayabanerve:matrix.org: current scaling is even worse than artics current proposal

<kayabanerve:matrix.org> ... Wouldn't that be reached after just a decade or so? Do we think nodes will support 100x more transactions in ten years, and there won't be another HF in ten years, demanding we change this now?

<kayabanerve:matrix.org> inb4 I advocate a 1 MB block limit to be done with it

<boog900> @kayabanerve:matrix.org: honestly this is less risky than whatever we are doing currently

<kayabanerve:matrix.org> I've stayed out of the scaling discussions and don't have an actual vote to cast here, I just want to be clear scalability should be derived from performance, not theoretical usage

<articmine> I can cap my orot via a soft fork

<articmine> I can cap my proposal via a soft fork

<boog900> how would you undo it?

<articmine> Miner override with a sustained 51%

<boog900> 51% of blocks*

<kayabanerve:matrix.org> ... so a hard fork?

<articmine> Provided that there was real demand

<articmine> No

<kayabanerve:matrix.org> Removing a soft fork does leave those who soft forked on a distinct chain which won't reconcile

<kayabanerve:matrix.org> That's a hard fork

<kayabanerve:matrix.org> If we're changing by hard forks anyways, we should be conservative

<articmine> No chain split

<kayabanerve:matrix.org> The protocol isn't ossified and won't be for years

<boog900> so much protocol complexity just to make this work

<boog900> I like my proposal more :p

<kayabanerve:matrix.org> I don't see why any network would need to make more than say, five transactions a day and will be advocating for 30 KB of block space every 24 hours personally /s

<articmine> It is a variant on Jeffro256's idea

<articmine> Using the medians to creat an effective miner voting without a chain split

<boog900> @articmine: Jeffro256's point was we can emergency softfork if scaling got out of control right?

<boog900> not exactly a system I would want to put my trust in if this was what was required to keep is secure

<articmine> No his idea is a tight soft fork on top of a generous hard fork

<articmine> The beauty of this appt is one can have very limited scaling in the soft fork if needed

<articmine> My idea is to enforce it using the hard fork medians

<articmine> I am going t put this concept together