03:50:14
gingeropolous:
no that prolly is right
18:03:04
articmine:
The long term median has not moved since it was created in 2019
18:03:29
articmine:
So over six years ago
18:57:59
gingeropolous:
the short term median has perhaps moved.... once?
18:59:07
articmine:
A few times and then rest
18:59:15
articmine:
Reset
19:00:39
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
19:02:39
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.
19:04:40
articmine:
Monero transaction rate has been essentially flat for like 6 years
19:04:40
articmine:
19:04:40
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.
19:06:18
articmine:
A sudden collapse of BS in the courts could disturb this equilibrium and trigger a sharp increase in on chain Monero transactions
19:08:22
articmine:
https://bitinfocharts.com/comparison/monero-transactions.html#log&alltime
19:11:21
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.
19:15:10
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
19:21:02
articmine:
In on chain transactions
19:40:42
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.
19:43:09
boog900:
or even 813x like current scaling allows
19:43:44
boog900:
like in what world is that realistic?
19:49:17
ofrnxmr:xmr.mx:
Is that 813x 300kb? Or 813x 25k tx/day
19:50:30
boog900:
813 * 300 kb
19:50:38
ofrnxmr:xmr.mx:
300kb is already like 5x
19:50:40
ofrnxmr:xmr.mx:
@boog900: Lol
19:51:00
boog900:
1024 is for artics FCMP proposal
19:51:11
boog900:
which would lead to gigabyte blocks in a year
19:52:42
ofrnxmr:xmr.mx:
It would take over 2min to upload that block to just 1peer
19:54:15
boog900:
probably an hour to verify
20:03:58
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 https://mrelay.p2pool.observer/e/6bLArM0KOW1NRFRF ]
20:06:01
jeffro256:
We can't engineer monerod fast enough for a 800x increase in tx volume to be usable
20:09:53
boog900:
Yeah and to think this is the case right now is scary IMO
21:10:32
ofrnxmr:xmr.mx:
16mb blocks is 11gb/day
22:17:20
articmine:
There are alternatives such as a soft fork cap on the blocksize growth
22:19:23
articmine:
There is no need to bake obsolescence into the consensus protocol over otherwise valid concerns regarding a sudden growth
22:21:11
articmine:
Such a soft fork can buy time to address these current code issues
22:22:52
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
22:25:25
articmine:
I do agree that the current scaling policy would deal with the likely surge in adoption if there is a collapse of BS
22:30:38
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
22:30:54
boog900:
instead of 1024x maximum growth in a year, 100x for example
22:32:27
boog900:
it still allows a massive sudden growth, just while also allowing us time to prepare the system
22:32:51
boog900:
gigabyte blocks in a year is silly
22:35:04
boog900:
why are we increasing the maximum yearly growth rate with FCMP?
22:36:26
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
22:38:44
boog900:
assuming exponential growth of our capacity is not a good idea
22:41:22
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?
22:42:08
boog900:
not looking for if this supports as many txs as you want, just if this would work
22:44:29
articmine:
@boog900: What you have just proposed is actually more aggressive than what I just proposed. Furthermore it would not work
22:44:58
boog900:
aggressive in what way?
22:45:09
boog900:
build up to max size or max size?
22:46:04
articmine:
The annual compounding rate is hit than 50%
22:46:48
articmine:
Higher than 50%
22:48:29
articmine:
It is not about the maxed out growth, it is about the variability in grothi
22:50:47
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
22:51:38
articmine:
If this is done via a Soft fork then it is easy t tighten or relax in the future
22:52:29
articmine:
In fact one can set this up so that it would require over 50 of the hashrate to override
22:53:03
articmine:
50% of the hashrate
22:54:26
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
22:54:32
boog900:
right?
22:54:48
boog900:
assuming the same penalty free zone too
22:54:52
articmine:
Not with a soft fork cap
22:55:00
articmine:
Way lower
22:55:04
boog900:
THATS NOT IN YOUR PROPOSAL
22:55:22
boog900:
so by my definition that makes your proposal more aggressive
22:55:44
boog900:
as it can reach a higher block size given the same time period
22:55:54
boog900:
much higher
22:56:01
articmine:
It was originally conceived with a sanity median cap > <@boog900> THATS NOT IN YOUR PROPOSAL
22:56:33
boog900:
the document you proposed did not contain it I don't know why you are trying to argue this
22:56:36
DataHoarder:
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
22:56:36
DataHoarder:
great, another non-profit-fueled Qubic-like entity to override :D
22:56:43
articmine:
I know
22:57:22
articmine:
Qubic would not have been able to override
22:57:26
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
22:58:44
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
22:59:45
articmine:
Because one can easily have a 30% surge a few months filled by nothing
22:59:53
boog900:
@articmine: selfish mining gives you more than 50% of the blocks for less than 50% of the hash rate
22:59:57
articmine:
Followed
23:00:14
articmine:
@boog900: For how long
23:00:39
articmine:
?
23:00:53
boog900:
forever, there is an equation, 51% of hashrate gives you 100% of blocks with selfish mining
23:01:37
boog900:
its like from 33% you can get more blocks than you should up to 50% with selfish mining.
23:01:51
articmine:
You can also HF to a massive penalty free zone like 1GB BSV
23:02:21
articmine:
With 51% over months
23:02:58
articmine:
This makes this entire discussion moot
23:04:19
boog900:
@articmine:monero.social: can you tell me what is technically incorrect with my proposal
23:05:19
articmine:
Let us say we have 10 over 2 months
23:05:24
articmine:
10x
23:05:44
boog900:
ok so your problem is that it doesn't support enough growth?
23:06:32
articmine:
By now growth for the following year
23:06:38
articmine:
Bo
23:06:43
articmine:
No
23:07:49
articmine:
No growth for a year then sharp growth for 2 months, then no growth for 6 months etc
23:09:18
articmine:
Just look at t Monero just. Five years of over 80x growth followed by 5 yt of no groy
23:09:30
articmine:
5 years
23:09:40
articmine:
Of no growth
23:10:37
articmine:
Litecoin 100x in one year then very little
23:10:58
boog900:
my proposal supports 100x growth in a year
23:11:11
boog900:
even though I still think that is unrealistic
23:11:30
boog900:
when you have very little txs adding more is easy
23:11:47
boog900:
@articmine: so your only concerns are around the amount of growth it allows?
23:15:40
articmine:
My primary concern is about the variability in growth
23:15:41
monero.arbo:matrix.org:
that's 2 million transactions a day lmao > <@boog900> my proposal supports 100x growth in a year
23:16:35
articmine:
It did happen in Litecoin when Bitcoin seized up
23:17:52
articmine:
8/ 1.4 will not address the need of both the big blockers and small blockerd
23:18:12
articmine:
Both loose
23:18:13
boog900:
@articmine: nah it will, some more numbers:
23:18:45
monero.arbo:matrix.org:
> <@articmine> My primary concern is about the variability in growth
23:18:45
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
23:18:53
monero.arbo:matrix.org:
I thought that was the whole way it was supposed to work
23:19:10
articmine:
We have a fee market
23:19:24
boog900:
Penalty free zone: 750,000
23:19:25
boog900:
Max size before long term adjusts: 12,000,000
23:19:25
boog900:
Max block size in 1 year: 90,354,432
23:19:38
boog900:
seems pretty perfect to me
23:19:52
articmine:
If you mean the Bitcoin mess that will kill peer to peer transactions just like it did in Bitcoin
23:20:07
boog900:
staying under the 100 mb packet limit in under a year is great
23:20:26
monero.arbo:matrix.org:
ArcticMine nobody means "the bitcoin mess" I am starting to feel you are being disengenuine about this
23:20:36
monero.arbo:matrix.org:
you seem to be the only one arguing for scaling paramters this large as well
23:20:41
articmine:
The way to do this is with a cap on to of my proposal
23:20:48
boog900:
@monero.arbo:matrix.org: its his way or the highway
23:21:39
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
23:21:40
boog900:
this is for FCMP FWIW > <@boog900> Penalty free zone: 750,000
23:22:01
articmine:
I am quite prepared to acct a 50x cap over a year
23:22:12
articmine:
On the blocksize
23:22:18
monero.arbo:matrix.org:
50x per year is disastrous
23:22:43
articmine:
Then 1.5 per year
23:22:54
boog900:
I like my proposal now :)
23:22:59
articmine:
Not per year
23:23:00
monero.arbo:matrix.org:
we are not going to grow from 25k tx/day to over 1.2 million organically in a year
23:23:16
monero.arbo:matrix.org:
?
23:23:29
articmine:
How do you kbt that!
23:23:44
articmine:
How do you know that?
23:23:44
monero.arbo:matrix.org:
@articmine: point out where it has ever happened to any project ever
23:23:57
monero.arbo:matrix.org:
I can't literally predict the future, but you are being unreasonable
23:24:09
articmine:
I said Litecoin 100x in a year
23:24:13
monero.arbo:matrix.org:
again, ETH only does 1.5 million and most of these are DeFi type transactions, not payments
23:24:19
boog900:
@monero.arbo:matrix.org: you see before monero: 0txs a year
23:24:19
boog900:
after the first tx: 1 tx a year
23:24:19
boog900:
infinite growth is needed
23:24:41
monero.arbo:matrix.org:
@articmine: going from 1000 a day to 100,000 a day doesn't count
23:25:12
articmine:
Why?
23:25:27
monero.arbo:matrix.org:
because it's easier for a smaller network to grow rapidly
23:25:52
monero.arbo:matrix.org:
there is no chain that organically does a million payment transactions per day, not a single one
23:26:07
monero.arbo:matrix.org:
maybe BTC if you count lightning
23:32:00
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
23:32:23
ravfx:xmr.mx:
LN have that much?
23:32:23
ravfx:xmr.mx:
Last time I did a test run it was still garbage tier
23:34:19
articmine:
The one thing that small blockers always forget is that the goalposts are changing against their position whilst they argue
23:35:31
boog900:
the thing that unrealistic blocks always forget is that scaling has pretty much never been activated
23:35:55
articmine:
In Monero because of BS
23:36:06
boog900:
does litecoin have a dynamic block size?
23:36:13
articmine:
No
23:36:48
articmine:
Just larger empty blocks
23:37:11
boog900:
so someone could have just spammed the chain for thoes blocks then?
23:37:18
boog900:
( the big ones)
23:37:43
boog900:
and also my proposal supports this amount of growth in a year
23:37:47
articmine:
Take a look at the price
23:37:49
boog900:
your proposal supports 10x it
23:37:53
articmine:
No
23:38:01
articmine:
It was not spamming
23:39:50
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!
23:40:04
articmine:
Spam Monero
23:40:24
articmine:
Vs say Litecoin
23:40:32
boog900:
I hate this argument
23:40:54
boog900:
Its too expensive it'll never happen! Just restrict it then.
23:41:23
boog900:
A miner just has to mine >50% of blocks
23:41:24
articmine:
It is too expensive to spam but I ham can happen
23:41:42
boog900:
and/or spam at the same time to compensate
23:42:08
boog900:
@articmine: at 1000x?
23:42:44
articmine:
@boog900: Depends the timeframe
23:42:44
boog900:
my proposal supports 100x in a year which is already crazy
23:42:50
boog900:
@articmine: year
23:43:21
kayabanerve:matrix.org:
I think we should limit Monero to one TX per block to encourage off-chain settlement solutions /s
23:43:52
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
23:44:08
kayabanerve:matrix.org:
But too large parameters could bring the net down, see all the work done in response to the stressnet
23:44:31
articmine:
@boog900: That is not crazy what is crazy is over 5x per year vs 1.5x
23:44:32
kayabanerve:matrix.org:
We should scale. We should scale conservatively and adjust instead of trying to be ready for a decade from now today
23:46:03
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.
23:46:38
kayabanerve:matrix.org:
Scaling parameters beyond our performance are just pointless other than as a risk to the network's safety.
23:47:01
kayabanerve:matrix.org:
Even if the protocol literally allows it, the fact nodes won't practically perform it makes it irrelevant
23:47:05
articmine:
What I am suggesting is capping scaling at 50% year after on year of up to 100x
23:47:14
articmine:
One year
23:47:58
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
23:48:02
articmine:
Also if done via a soft fork ) miner voting this can be easy adjustment as needed up or down
23:48:27
articmine:
@kayabanerve:matrix.org: I am fine t that
23:48:38
boog900:
@kayabanerve:matrix.org: current scaling is even worse than artics current proposal
23:49:02
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?
23:49:26
kayabanerve:matrix.org:
inb4 I advocate a 1 MB block limit to be done with it
23:49:48
boog900:
@kayabanerve:matrix.org: honestly this is less risky than whatever we are doing currently
23:50:06
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
23:50:07
articmine:
I can cap my orot via a soft fork
23:50:36
articmine:
I can cap my proposal via a soft fork
23:50:43
boog900:
how would you undo it?
23:51:28
articmine:
Miner override with a sustained 51%
23:51:53
boog900:
51% of blocks*
23:51:58
kayabanerve:matrix.org:
... so a hard fork?
23:52:05
articmine:
Provided that there was real demand
23:52:11
articmine:
No
23:52:31
kayabanerve:matrix.org:
Removing a soft fork does leave those who soft forked on a distinct chain which won't reconcile
23:52:34
kayabanerve:matrix.org:
That's a hard fork
23:52:46
kayabanerve:matrix.org:
If we're changing by hard forks anyways, we should be conservative
23:52:51
articmine:
No chain split
23:52:55
kayabanerve:matrix.org:
The protocol isn't ossified and won't be for years
23:53:02
boog900:
so much protocol complexity just to make this work
23:53:08
boog900:
I like my proposal more :p
23:54:24
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
23:54:45
articmine:
It is a variant on Jeffro256's idea
23:55:38
articmine:
Using the medians to creat an effective miner voting without a chain split
23:55:42
boog900:
@articmine: Jeffro256's point was we can emergency softfork if scaling got out of control right?
23:56:09
boog900:
not exactly a system I would want to put my trust in if this was what was required to keep is secure
23:56:45
articmine:
No his idea is a tight soft fork on top of a generous hard fork
23:57:41
articmine:
The beauty of this appt is one can have very limited scaling in the soft fork if needed
23:58:21
articmine:
My idea is to enforce it using the hard fork medians
23:59:50
articmine:
I am going t put this concept together