01:09:31
datahoarder:
I commented on it @jeffro256:monero.social but https://github.com/seraphis-migration/monero/pull/250 has similar issues as on https://github.com/seraphis-migration/monero/pull/245
01:25:29
datahoarder:
New changes on #245 converge to the ones in my go implementation as well :)
01:41:34
articmine:
Yes this works as a scaling cap. It is very easy to add to my proposal
01:43:13
articmine:
https://github.com/monero-project/research-lab/issues/155
01:43:13
articmine:
I am referring to the above
06:24:59
articmine:
I have updated my proposal to incorporate the above sanity cap with slightly tighter parameters.
06:25:56
articmine:
https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-01.pdf
07:17:04
spackle:
The (new) sanity limit in this proposal is solely a function of block height. Consensus that the daemon can handle 10 MB blocks will not be sufficient.
11:18:37
articmine:
It is the lower of the adaptive block weight and the sanity limit.
11:19:18
articmine:
That is the point of a sanity limit
11:21:41
articmine:
... and why it works
12:49:19
monero.arbo:matrix.org:
small note AM for the future commas or exponential notation would keep me from sitting here counting 6 or 7 zeros after a number
12:52:41
monero.arbo:matrix.org:
so in 10 years we're looking at roughly max 250 MB blocks, is that right?
12:55:23
articmine:
Correct
12:57:21
monero.arbo:matrix.org:
I'll keep chewing on it, would love to see some graphs or simulations, but my initial impression is that I find that number spooky but not suicidal
12:57:27
monero.arbo:matrix.org:
which is a notable improvement for sure
13:00:46
boog900:
I am disappointed that this very clearly moves by itself after you were very clear yesterday @articmine:monero.social that it wouldn't.
13:00:54
boog900:
I was correct to be suspicious
13:01:24
articmine:
@boog900: You are ignoring the existing scaling
13:01:39
articmine:
This is a cap
13:01:43
boog900:
No I am not. Do not twist my question
13:01:49
boog900:
Was not*
13:01:54
boog900:
Let me get the logs
13:02:28
boog900:
https://libera.monerologs.net/monero-research-lounge/20251202#c621117
13:02:30
monero.arbo:matrix.org:
I see what you both mean. AM Is saying block size doesn't go up automatically, boog is pointing out that this particular parameter does go up automatically, yeah?
13:02:30
articmine:
You have to look at the entire equation
13:02:49
boog900:
Very clearly I was talking about specifically the sanity cap
13:03:05
articmine:
@boog900: No I was not
13:03:20
articmine:
I meant the block weight
13:03:27
boog900:
To try and twist my question to mislead people is very disappointing
13:03:28
spackle:
We are having a communication issue but that is fine. In less than two years, this proposal will allow for 16 MB blocks to be generated from flooding at almost any time.
13:03:44
articmine:
@spackle: No
13:03:44
boog900:
@articmine: Yes you were not but I clearly was
13:04:57
monero.arbo:matrix.org:
What was the penalty free zone in 2015 when XMR launched? if it was 100 kB that would imply 25 MB now using AM's formula
13:04:57
monero.arbo:matrix.org:
in case that's a helpful reference for anyone, it helps me to think about it, thinking backwards instead of forwards
13:04:58
articmine:
@spackle: There is a cost
13:05:20
monero.arbo:matrix.org:
we know there is a cost but that doesn't mean it can't be "at almost any time"
13:05:48
spackle:
@articmine: As discussed earlier, I am not interested in making a short term network breaking expensive, I am interested in preventing it entirely.
13:06:03
spackle:
Short term again, meaning without moving the long term median.
13:06:35
articmine:
@spackle: This has at been the case
13:06:38
spackle:
Anyway, I trust readers to understand my meaning.
13:07:28
articmine:
You either want peer to peer cash or not
13:08:13
articmine:
Yes we have to deal with BS suppression of Monero
13:08:32
monero.arbo:matrix.org:
@articmine: a global peer to peer cash network will need a Level 2, you can't just sidestep the blockchain trilemme with scaling
13:08:49
articmine:
@monero.arbo:matrix.org: No it does not
13:09:18
monero.arbo:matrix.org:
sure, recording every transaction on the planet forever makes sense :/
13:09:48
monerobull:matrix.org:
how many transactions is 32mb
13:10:10
articmine:
32 transactions per second
13:10:13
boog900:
This is effectively a block size bomb and I will not support it over a proper limit that moves with sufficient activity.
13:11:08
articmine:
I am not wasting any more time on this
13:11:23
monerobull:matrix.org:
@articmine: right now we are at 100 times less than that
13:11:45
articmine:
Correct
13:12:30
ofrnxmr:xmr.mx:
@boog900: I'd have to disagree here, as that would also imply that we shouldnt allow 10.8mb (as we didnt have the volume last yr to reach 7mb etc)
13:13:24
monero.arbo:matrix.org:
it's not that we shouldn't allow it, I think they're saying it should require activity to scale the long term growth as well
13:13:41
articmine:
I can see the BS conflict of interest behind the scenes here
13:13:49
monero.arbo:matrix.org:
I know, it's the lesser of the two parameters, but the conversation is about whether both shoudl take TX volume to scale
13:14:03
articmine:
This is what this is really about
13:14:06
spackle:
Please be specific of whom you are accusing, and of what exactly you are accusing them.
13:14:30
articmine:
Those who fear peer to peer cash
13:16:25
monerobull:matrix.org:
we dont need more than 100 times the current throughput for a long time but setting a hard limit could spiral into bitcoin-style blocksize wars if it ever gets close to the limit
13:16:45
articmine:
@monerobull:matrix.org: If course
13:16:58
articmine:
If course
13:17:07
ofrnxmr:xmr.mx:
We're probably having that war rn
13:17:10
spackle:
Agreed, I also oppose the 32 MB hard limit proposal.
13:17:28
monerobull:matrix.org:
can we time-lock it
13:17:40
spackle:
We can do anything we agree on
13:17:49
monerobull:matrix.org:
put some dynamic scaling on it that only activates after 5 years?
13:18:06
monerobull:matrix.org:
that would prevent a war later on
13:18:09
ofrnxmr:xmr.mx:
10.8mb this yr is 15mb next yr, 21mb in 2027, 29mb is 2028 etc (using 1.4)
13:18:22
monerobull:matrix.org:
because we are not hard-locked into a specific limit
13:18:45
articmine:
@monerobull:matrix.org: It is the same issue. One can allow growth or not. One cannot do both
13:18:49
ofrnxmr:xmr.mx:
Is 10.8mb is acceptable right now, i see no reason to assume that 29mb wont be equally as feasible in 2028
13:19:04
ofrnxmr:xmr.mx:
If* 10.8
13:19:32
monero.arbo:matrix.org:
@ofrnxmr:xmr.mx: I don't think compute is growing that fast...
13:19:35
monerobull:matrix.org:
@articmine: one can have limits based on reality
13:20:01
ofrnxmr:xmr.mx:
Other proposals on the table are to allow near 100mb's this year, 32mb hard cap, or starting st 16mb. All of those can be hit before 2028
13:20:07
monero.arbo:matrix.org:
was 3 MB the limit in 2022?
13:20:11
ofrnxmr:xmr.mx:
@monerobull:matrix.org: This IS based on reality
13:20:18
monerobull:matrix.org:
if you have zero limits you end up like BTCSV
13:20:32
ofrnxmr:xmr.mx:
@monero.arbo:matrix.org: No, it was virtually unlimited
13:20:54
ofrnxmr:xmr.mx:
@monerobull:matrix.org: Youre not paying attention. There are limits. 1.4x per year
13:20:56
articmine:
They have demonstrated 4 GB blocks 3 years ago
13:21:12
monero.arbo:matrix.org:
@ofrnxmr:xmr.mx: I meant hypothetically, in terms of like a max viable number. If we're saying we can go from 10.8 to 30 in 3 years, then that implies the number 3 years ago would have been ~3
13:21:43
monero.arbo:matrix.org:
again I find it easier to think about these things by projecting backwards because we KNOW what tech was like then
13:21:47
ofrnxmr:xmr.mx:
@monero.arbo:matrix.org: could have been* and yea, 3 years ago we could have handled 3mb
13:22:23
articmine:
@monero.arbo:matrix.org: You mean like 2MB in 1979?
13:22:51
monero.arbo:matrix.org:
I feel like 3 years ago we could have handled more than 3, probably over 5, which to me implies a slower rate of growth
13:23:40
monero.arbo:matrix.org:
@articmine: I've seen you say stuff like this a couple times now but I think we all know growth is slowing, and not just because of technical hurdles. transistors are already down to the size of a few atoms. going much further will require more than just shrinking the die
13:24:01
ofrnxmr:xmr.mx:
@monero.arbo:matrix.org: Tevadors numers are below neilsons law of 1.5, so the numbera are below what they would otherwise be
13:24:10
spackle:
@ofrnxmr:xmr.mx: Are you confirming that the network can handle a steady stream of blocks that are 10MB (increasing to 16 MB within 2 years)?
13:24:37
ofrnxmr:xmr.mx:
@spackle: That is what i am implying, yes
13:24:58
monero.arbo:matrix.org:
@ofrnxmr:xmr.mx: ah well my concern from the start has been more about compute than bandwidth
13:24:59
spackle:
Are you comfortable saying it directly?
13:25:45
spackle:
That would be an important moment. As of now, I am not aware of any person who has confirmed the daemon is capable of that.
13:26:12
articmine:
We will need to split the chain like Bitcoin. Only in this case the fork is the small block supporterd
13:26:56
ofrnxmr:xmr.mx:
The master daemon has a couple bugfixes to be upstreamed, but with these bug fixes, yes monerod can handle 16 mb today
13:27:16
articmine:
I also recommend Roger Vet's book. Highjacking Bitcoin
13:27:28
articmine:
Roger Ver
13:27:29
spackle:
To be clear, I don't mean a single block. I mean a steady stream of 16 MB blocks.
13:27:30
boog900:
I did say sufficient activity, if we want to grow 10x in the short term, sure, but this proposal will have us scale so effectively there is no sanity limit even with no extra activity > <@ofrnxmr:xmr.mx> I'd have to disagree here, as that would also imply that we shouldnt allow 10.8mb (as we didnt have the volume last yr to reach 7mb etc)
13:27:56
ofrnxmr:xmr.mx:
@spackle: Yeah, same
13:29:18
articmine:
@boog900: The issue here is the suppression of Monero by BS lobbying . We have to catch up once the VS companies are out in their place by the courts
13:29:27
monero.arbo:matrix.org:
@boog900: yeah raising M_L from 1.7x to 2x does allow very fast growth within these bounds, for sure
13:29:32
articmine:
BS companies
13:29:46
articmine:
@monero.arbo:matrix.org: That is the point
13:30:01
monero.arbo:matrix.org:
I mean yes it is your point but I also udnerstand the concern
13:30:46
articmine:
Then why fight this proposal?
13:31:57
articmine:
The fact is that Monero has been suppressed for close to a decade. So has Bitcoin and I also suspect Ethereum
13:31:58
monero.arbo:matrix.org:
I did say it's better but doesn't mean I'm giving uncritical support, why would it
13:31:59
ofrnxmr:xmr.mx:
@monero.arbo:matrix.org: I think there should still be a cap of 1.4x the cap of 262800 blocks prior
13:32:25
monero.arbo:matrix.org:
@ofrnxmr:xmr.mx: those are the "bounds" I meant
13:33:11
articmine:
@ofrnxmr:xmr.mx: Then you hard code the BS suppression into the consensus
13:33:19
monero.arbo:matrix.org:
Idk like I said it would be nice to see some graphs or something, it's hard to just stare at equations and go "oh okay that looks good"
13:33:50
monero.arbo:matrix.org:
@articmine: bruh
13:34:24
monero.arbo:matrix.org:
1.4x growth per year is generous
13:34:58
ofrnxmr:xmr.mx:
@articmine: Not a cap of the median, a cap of the neilsons law cap. So if that is 10.8mb right now, then 1 year from now that should be automaticly adjusted to 15.12
13:35:15
articmine:
@monero.arbo:matrix.org: Not after 10 years of suppression
13:35:24
ofrnxmr:xmr.mx:
@ofrnxmr:xmr.mx: ^
13:35:38
ofrnxmr:xmr.mx:
Suppression doesnt matter if the cap grows regardless of activity
13:36:08
articmine:
@ofrnxmr:xmr.mx: It allows catching up
13:36:10
monero.arbo:matrix.org:
@articmine: I'm talking about for our capabilities. If we think ~11MB blocks are about what we can handle now, increasing that number by 40% year over year is extremely generous
13:36:24
monero.arbo:matrix.org:
providing more capacity than the network can handle helps preciciely nobody except people who want to see Monero fail
13:36:35
articmine:
It actually is not
13:37:50
articmine:
Realistically we need a chain split
13:37:57
monero.arbo:matrix.org:
whatever, I've got stuff to do today. I am once again getting tired of AM trying to bully the majority of the community on this
13:38:01
monero.arbo:matrix.org:
and now he keeps proposing chain splits
13:38:11
monero.arbo:matrix.org:
while calling OTHERS the destructive ones
13:38:18
monero.arbo:matrix.org:
go split the chain then bro
13:39:06
articmine:
It will happen. It happened in Bitcoin
13:39:45
articmine:
I got.out before it happened in Bitcoin.
13:39:55
articmine:
I saw it coming
13:40:36
articmine:
Unfortunately I also see it here.
13:41:31
articmine:
😂
13:42:43
boog900:
@ofrnxmr:xmr.mx: in the sort term the exponential growth is fine, but it will get out of hand. Even if bandwidth grows that much CPU power and our ability to use it might not.We can say this will happen far enough in the future it doesn't matter but it is still a bomb.
13:43:47
articmine:
I will NOT split this chain but I do not believe a split can be stopped
13:48:38
nioc:
at the end tevador's issue referenced by AM https://github.com/monero-project/research-lab/issues/155 he states ....
13:48:50
nioc:
Verification time constraints
13:48:50
nioc:
The exact same formulas I used to derive the natural block size cap can be used to derive a block verification time cap. Instead of the median download speed, the formula would use the median CPU performance and its annual growth rate.
13:49:06
nioc:
is this being taken into account?
13:50:26
nioc:
and as far as being for or against p2p cash, without a functioning network you can't have it
13:53:08
nioc:
in my mind the #1 thing that sets monero apart is that it is fungible, this it what is supposed to make BS companies useless. Are all our privacy features useless against BS?
13:55:26
nioc:
ofc we need a certain # of txs, the question is how many? Transparent chain vs Monero
13:55:44
nioc:
*Monero with FCMP++
14:06:03
spackle:
On the note of verification time, @ofrnxmr:xmr.mx I would like to examine your claim that the network can handle 16 MB blocks being produced steady state. At the last meeting it was mentioned that verifying a 16 MB block might take 93 seconds on a single thread. That would mean a miner needs to have a direct connection to the [... too long, see https://mrelay.p2pool.observer/e/3-ag8M4KUDhNcTU1 ]
14:06:30
spackle:
Does what I just wrote seem incorrect to you?
14:11:17
ofrnxmr:
Blocks should be over 10mb in a couple hrs and you'll be able to see for yourself
14:12:59
spackle:
I don't feel you've answered my question, or addressed the point I was making. Of course that is your prerogative if you don't wish to, but I was hoping that you might.
14:13:48
ofrnxmr:
Afaik, you dont reverify txs that are in blocks
14:14:25
ofrnxmr:
it might take 93 seconds for a single threaded device to verify a a 16mb block where they have not seen a of the txs yet
14:14:40
ofrnxmr:
But the (fluffy)block itself is not 16mb
14:15:05
spackle:
If a node is receiving the transactions that will constitute a 16 MB at steady state, they will need to verify all the transactions in a block at some point in time, no?
14:15:31
spackle:
Meaning that the will need to verify transactions at the rate of block production.
14:15:43
ofrnxmr:
single threaded node would take 93 seconds even if the block is never mined - they verify txs in the pool
14:16:45
spackle:
Yes, and it follows that they will need to verify txs in the pool at the rate of block production. Does it not?
14:17:59
ofrnxmr:
Are we assuming a txpool that grows at 16mb / 120seconds? If so, sure
14:18:24
articmine:
nioc: Is the current Monero more private than Pirate Chain? This is a valid question.
14:18:27
ofrnxmr:
If the txpool grows at 32mb/120seconds, no. They have to verify 32mb/120seconds
14:18:28
spackle:
That would seem be a requirement of producing a steady stream of 16MB blocks.
14:18:52
ofrnxmr:
@spackle: A minimum* requirement
14:19:18
ofrnxmr:
Theres nothing stopping txs from being produced at 40mb per minute (as an example)
14:19:53
spackle:
I am glad we agree. So returning to the point at hand, a node might need to spend, at minimum, 93/120 seconds on verification.
14:20:20
spackle:
It follows that this node can spent, at maximum, 27/120 seconds on actual mining.
14:20:41
ofrnxmr:
A single threaded* node
14:21:06
spackle:
Yes
14:22:45
ofrnxmr:
Mining on monerod is paused while adding blocks to the the chain, but i don't think its paused while verifying txs
14:22:58
ofrnxmr:
You just wouldnt include txs that arent verified in the template
14:28:55
DataHoarder:
^ if mining via xmrig or p2pool the miners keep mining
14:29:08
DataHoarder:
using the old template, as monerod has not published a new one
14:29:21
DataHoarder:
or not even template, has not published new miner data
14:30:20
spackle:
I see your point.
14:30:23
DataHoarder:
there is no "stop the miners" message on stratum, at best you can close the connection so they stop working, but them reconnecting to it can take a few seconds once you open it
14:30:43
DataHoarder:
that caused already quite a few diverging forks in stressnet as well
14:31:21
DataHoarder:
at some point it was ~25s before new miner data was ready on a 9900X3D locally
14:31:48
ofrnxmr:
Yeah i think that was fixed by relaying empty fluffyblock (?)
14:31:55
DataHoarder:
this has improved in recent versions, but it's still a major part of wasted proof of work during large blocks
14:32:05
ofrnxmr:
otherwise the nodes disconnected from one another
14:32:08
DataHoarder:
the issue is local ofrnxmr
14:32:22
DataHoarder:
like, even if not connected to network, the templates take quite long to verify
14:32:36
DataHoarder:
specially when monero itself provided the valid txs already to be used
14:33:04
ofrnxmr:
Ive been mining with xmrig without issue for a while now. I had a lot of issues on older versions of stressnet
14:33:15
DataHoarder:
you find no issues, just "delays"
14:33:36
DataHoarder:
see when xmrig finds a share
14:33:38
DataHoarder:
and when it receives a new job
14:34:06
ofrnxmr:
I mean, on older versions monerod would return bad data while it was broadcasting the block
14:34:38
DataHoarder:
yeah on ZMQ it just sent nothing, it wasn't even RPC polling
14:35:07
ofrnxmr:
Hasnt happened in quite a few weeks now
14:35:07
ofrnxmr:
Which would lead to me mining invalid or rejected shares
14:35:08
ofrnxmr:
I mean, on older versions monerod would return bad data while it was broadcasting the block
14:37:12
ofrnxmr:
(fwiw, i think im just using rpc)
14:43:47
DataHoarder:
it uses rpc indeed
14:50:13
sgp_:
> <@articmine> https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-01.pdf
14:50:13
sgp_:
this does indeed add some sanity to the proposal. It's slightly less than 40% max growth rate per year (38.89%) if my math is right. It's just super annoying to me that it took weeks of bickering that the old version was totally fine, and that I only wanted to remove the explosive growth because I want Monero to fail, when the prior proposal had obvious issues.
14:50:13
sgp_:
I still don't like the way the fee market is handled, but at least the proposal probably won't kill Monero anymore
15:31:45
articmine:
How old are single thread processors? > <@ofrnxmr> A single threaded* node
15:32:03
ofrnxmr:
Like 2002? Lol
15:32:03
articmine:
Seriously
15:34:15
ofrnxmr:
Probably older actually, i think we had dual core processors before y2k
15:37:07
ofrnxmr:
Anyway, single threaded numbers are only good for "per thread" analysis. So 16mb per thread is still possible, but would increase time til confirmation by 93 seconds iiuc
15:38:27
ofrnxmr:
these numbers also would imply that a 16 thread system would take 93 seconds to verify 256mb
15:41:55
spackle:
My thought was that single threaded performance was worth discussing because daemon multi-threading was limited in both scope and performance. If that has changed I am delighted to hear it.
15:52:22
ofrnxmr:
Monero's multithreading has a very silly default config of 4 threads
15:52:52
ofrnxmr:
Changing this to max threads increases sync speed by 40-70%
15:53:53
ofrnxmr:
Running single threaded is much slower than 4 threads, as evidenced by @mayhem69:matrix.org 1vcpu 2gb ram tests. I also tested and can confirm that 1 thread is much slower than 4
15:54:42
boog900:
@ofrnxmr: its not just that, monero takes locks in places too, like when adding a tx to the pool
15:54:48
ofrnxmr:
This is without checkpoints and im not sure if it effects tip/tx syncing, or if its only relevant for syncing batch txs / blocks
15:55:35
boog900:
@boog900: changing this is going to be harder as you need to make sure data stays in sync
15:56:01
ofrnxmr:
@boog900: My main point is that "catch-up" sync or ibd w/o checkpoints is much faster with more threads
15:58:49
articmine:
@spackle: I have been arguing this for years. It is not an excuse to throttle scaling
16:00:27
jbabb:cypherstack.com:
Has block size been an actual limit to transaction throughput yet?
16:00:59
boog900:
scaling has only been activated like once during the last spam wave
16:01:16
boog900:
even then it didn't even really move
16:02:10
boog900:
@articmine: Its a bottleneck, just like every other bottleneck. Until it is fixed we should not ignore it.
16:02:28
rucknium:
AFAIK, FCMP can also do batch verification if you have all the txs together, like in initial block download. I don't know how much that speeds up the processing. The numbers I quoted are for single txs as they arrive in the txpool AFAIK, where you cannot easily perform batch verification.
16:06:22
ofrnxmr:
Fwiw, theres currently 112k txs in the pool
16:10:15
rucknium:
Stressnet? My nodes with default txpool size are showing 60K txs. So there are a lot more txs out there is non-default txpools.
16:15:46
ofrnxmr:xmr.mx:
Yeah, my explorer node has a 3gb limit
16:28:06
boog900:
During that last spam the locks was causing issues with public nodes, that was never fixed right?
16:28:37
boog900:
We didn't even have that big of blocks then too, just over the current median IIRC
16:47:56
articmine:
@boog900: Which is why it needs to be fixed. What I cannot support is to ignore it and then try to hide it by preventing people from using Monero
16:51:32
boog900:
Yes but we have already been over this. The scaling is dangerous _now_, we need to plan for what we can handle _now_.
16:53:01
boog900:
The amount of throughput we can handle will not scale perfectly with the number of threads. We don't know how much a fix increasing parallel processing would give us.
16:55:21
jbabb:cypherstack.com:
Can we mitigate the effects of key image / input reuse across blockchain forks? > <@articmine> I will NOT split this chain but I do not believe a split can be stopped
16:55:27
jbabb:cypherstack.com:
The most famous result of a big block split shows a dismal future for the minority chain:
16:55:27
jbabb:cypherstack.com:
https://bitinfocharts.com/comparison/bitcoin%20cash-transactions.html#alltime
16:55:27
jbabb:cypherstack.com:
https://bitinfocharts.com/comparison/bitcoin-transactions.html#alltime
16:57:03
jbabb:cypherstack.com:
the implications for our current privacy protocol are more dire: splits for Monero in its current state would threaten to degrade the privacy that's the bedrock of Monero's use case.
16:58:52
jbabb:cypherstack.com:
the problem, frankly, is not that there are too many real-world people wanting to use the protocol and the block sizes are just too small such that they're suppressing usage and restricting access--at least, I don't see proof for that
17:05:57
articmine:
@jbabb:cypherstack.com: No the problem is that the blockchain surveillance companies have lobbied governments all over the world to de list Monero from exchanges.
17:05:57
articmine:
This prevents and frustrates people from using Monero. When the lobbying hit Canada I know of people who were forced to sell their XMR.
17:05:57
articmine:
The Monero community has valiantly responded to this attack by promoting de centralized exchanges.[... more lines follow, see https://mrelay.p2pool.observer/e/zvKz9c4KUC1oTzFa ]
17:06:15
ofrnxmr:
Delistings are proof enough that usage is heavily surpressed
17:07:10
ofrnxmr:
An example for canada: coincards operates out of canada and still accepts xmr but charges ~3% extra because they have to swap it out on trocador etc
17:07:23
jbabb:cypherstack.com:
re: delistings, we can't have our cake and eat it too.
17:07:23
jbabb:cypherstack.com:
that is, if we provide true privacy, it should be a foregone conclusion that sans political organizing, most nation states will ban true privacy.
17:08:55
ofrnxmr:
If all cexes delist monero, businesses which accept monero would have a hard time doing so, as they need a liquid way to convert monero into money that they can use to pay bills in
17:10:02
ofrnxmr:
I'm not "pro cex", but delisting are probably the easiest way to stifle adoption
17:10:03
jbabb:cypherstack.com:
OK, I see how that sort of political suppression does contribute to the claimed technical suppression--that because it's made illegal in certain ways and in certain places, less real world people want access to the shared block space
17:10:03
jbabb:cypherstack.com:
but raising the block size wouldn't reverse those ultimately political problems
17:10:18
jbabb:cypherstack.com:
it's a technical solution for a political problem and I don't see how it would lead to increased usage in and of itself
17:10:47
ofrnxmr:
Were technically adding a block size cap.
17:11:14
jbabb:cypherstack.com:
technical solutions would include bridging XMR to other chains so we can let users route around political barriers
17:11:22
ofrnxmr:
these proposals dont increase scaling, they all throttle it back and latest one puts a cap ln the max growth per yr
17:12:00
ofrnxmr:
(editing spams irc)
17:12:47
ofrnxmr:
Instead of being abke to reach 30mb blocks in 20hrs, the latest proposal maxes out at 10.8mb
17:15:37
boog900:
Only in the first year
17:16:01
ofrnxmr:
yeah, 40% growth per year
17:16:28
ofrnxmr:
in contrast to.. what 500mb in yr 1 currently?
17:17:15
boog900:
Yeah a lot better but we should not settle for what article agrees to if we can do better
17:17:24
boog900:
Artic*
17:18:25
ofrnxmr:
Kayabas proposal is to add 32mb cap (which would put us in 2028 or 2029)
17:18:25
ofrnxmr:
other proposals call for immediate cap of 16-32mb and max up to ~100mb
17:18:56
gingeropolous:
i am against the idea of a hard cap. it should always be dynamic in some regard
17:19:19
spackle:
I agree, and I think the vast majority of the community does as well.
17:19:43
boog900:
We can reduce the long term growth rate to 1.4x a year and then we move at the same rate but only when there is usage
17:19:48
ofrnxmr:
If we cant scale to 32, 48, 64 mb in '28 29 30, then we just soft fork to limit it further, no? Thats 3,4,5years out
17:19:52
boog900:
There are infinite options
17:20:20
boog900:
@ofrnxmr: Yeah but I would rather have a good algo now than code in a block bomb
17:20:23
gingeropolous:
indeed.
17:21:06
ofrnxmr:
i think agreeing to start at 10.8, 16, 32 etx mb is already inline with the block bomb
17:21:42
gingeropolous:
as a sanity limit? because it doesn't get to 10.8 for free
17:21:53
ofrnxmr:
And theres no reason to assume that, if this proposal was made in 2026, that we wouldnt start at 15mb
17:21:59
ofrnxmr:
@gingeropolous: Yes
17:24:29
boog900:
@ofrnxmr: It gets harder to predict the more years you try look ahead. Even if you support this, why add all this complication to an already complicated system
17:25:29
gingeropolous:
i mean, its no more complicated than what we already heave (the double median). It just adds a third, final cap.
17:26:53
boog900:
Its the change of the algorithms for the original proposal that allows gigabyte blocks in a year too
17:27:25
gingeropolous:
yeah, the 50x changed to 16x?
17:27:38
boog900:
And the 1.7 to 2
17:27:55
boog900:
And the calculation of the block limit
17:28:15
boog900:
Its not just 2x the median in the gigabyte proposal
17:29:32
boog900:
Why make all these changes to satisfy artic?
17:30:33
DataHoarder:
16:39:09 <datahoarder> The conflict of interest here is delaying FCMP++ due to scaling issues which would already cover the part of breaking surveillance for rings, so that must be prioritized. Adding sanity scaling parameters/adjustments so that can exist happily with current implementations can speed the process of deploying this in an agreeable
17:30:33
DataHoarder:
way and stopping BS
17:30:33
DataHoarder:
18:12:35 <articmine> There may be a case to defer FCMP++ until we obtain these proofs
17:32:18
datahoarder:
it got shuffled around, but ^ delaying FCMP++ is a -- given previous BS statements. FCMP++ actively deals with BS so I can't understand how ArticMine wants to give BS more power for longer
17:33:03
DataHoarder:
if anything the improvements listed open the way for another hardfork for the areas which require one
17:33:27
ofrnxmr:xmr.mx:
@boog900: I'm mostly in aggreeance with the 40% yearly growth of the sanity cap, but the other changes i cant say i understand why they are the way they are
17:34:04
gingeropolous:
yeah me neither. the existing parameters allowed for pretty expansive growth
17:35:52
datahoarder:
not on new bridge, which doesn't pass the edits at the moment (I'm trying to make a regex finder for small edits, or post link to edits, which always include the latest version) > <@ofrnxmr> (editing spams irc)
17:36:49
boog900:
I think the 40% is probably fine for 5 or so years, after that 🤷♂️ after 15 its pretty much not there.
17:37:36
ofrnxmr:xmr.mx:
Well, in 5yrs monero will also be 40% older
17:38:14
ofrnxmr:xmr.mx:
.. :P
17:38:27
boog900:
I doubt we will have the performance improvements required to keep up with the exponential growth
17:38:52
ofrnxmr:xmr.mx:
And 5yrs is "only" 58mb
17:40:16
ofrnxmr:xmr.mx:
i personally think 5yrs is plenty lf lead-in to figure that out and modify if necessary
17:40:54
ofrnxmr:xmr.mx:
The last hard fork was 2022, just 3yrs ago
17:42:35
boog900:
Why not just set a hard limit in that case, we can remove it once we know we can handle it
17:43:20
boog900:
Instead of exponential growth, exponential growth to a point which we the HF to remove if we can handle it
17:48:29
ofrnxmr:xmr.mx:
Exponential growth to 99mb?
17:48:58
ofrnxmr:xmr.mx:
Since we, at min, need to remove the packet size limit before we can scale above it
17:50:21
ofrnxmr:xmr.mx:
I also want to see if the serialization causes single blocks to break stressnet at ~30mb. Spamming now for that 🙃
17:52:41
boog900:
@ofrnxmr:xmr.mx: It depends on the size of the txs too as it was the string limit that was hit IIRC
18:02:32
ofrnxmr:
i honestly dont remember. Might be documented on one if the prs to increase the limits
21:39:54
DataHoarder:
https://seekingalpha.com/pr/20327743-micron-announces-exit-from-crucial-consumer-business
21:40:16
DataHoarder:
Micron stops making consumer-directed memory (ram) and SSD chips
21:40:28
DataHoarder:
they will be solely dedicated on AI and server-grade ones now.
21:40:44
DataHoarder:
there goes one major vendor less...
21:40:48
DataHoarder:
so SSD + HDD seems to be in the future :)
22:14:33
elongated:matrix.org:
With cloud based storage accessible, high storage consumers ssd will be a niche in near future ?