00:00:01
boog900:
A soft fork is a change that is backwards compatible with old nodes
00:00:11
boog900:
not a temporary change
00:00:33
DataHoarder:
bring back "token" hardforks every 6 months :P
00:00:45
articmine:
It is backwards compatible with the existing scaling and my proposal
00:01:30
boog900:
but why have the extra softfork just include it in the hardfork?
00:01:58
articmine:
To prevent attack on the existing scaling
00:02:13
boog900:
wat
00:02:16
kayabanerve:matrix.org:
But the further 'soft forks' also have to be sequentially compatible
00:02:29
articmine:
Regarding the identified vulnerabilites
00:02:53
articmine:
@kayabanerve:matrix.org: Yes
00:03:14
boog900:
you can include the restrictions on growth in the HF then remove them with miner consensus. Using the term soft fork is confusing as it doesn't need to be a softfork
00:03:33
boog900:
still this is so much protocol complexity
00:04:03
articmine:
Miner majori not consensus
00:04:04
boog900:
For what? why not just change the short and long term multipliers?
00:04:36
boog900:
@articmine: miner majority is pretty much consensus otherwise we can get chainsplits
00:04:51
selsta:
Out of selfish reasons I want to say I prefer conservative scaling proposals because if it it is too easy to spam the blockchain I feel like I'm the one who always has to work on the emergency releases.
00:04:52
articmine:
@boog900: This does not address the smart blocker concerns
00:05:14
articmine:
selsta: Spam is not the issue
00:05:25
ofrnxmr:xmr.mx:
Neilsons law says you get a 50% bump every year
00:05:25
ofrnxmr:xmr.mx:
So why not do
00:05:25
ofrnxmr:xmr.mx:
Why not let long term median to 525600 (2yr) blocks @1.5x (meduan = 262800 blocks, 1yr) and max short term median to 16mb
00:05:29
boog900:
@articmine: who are you to say?
00:05:48
boog900:
I literally made it and it addresses my concerns (mostly)
00:05:52
articmine:
It is genuine growth that is too fast t the network
00:06:22
articmine:
@boog900: You are not the only one
00:06:22
boog900:
we are not going to get 1000x growth in a year
00:06:25
selsta:
monero is nowhere near the quality where l scaling becomes purely theoretical, as shown on stressnet
00:06:27
ofrnxmr:xmr.mx:
@ofrnxmr:xmr.mx: and we can hf to increase that if we have some breakthroughs
00:06:28
boog900:
we aren't going to get 100x
00:07:21
321bob321:
Where going visa level soon
00:07:46
articmine:
I will put something together
00:07:52
selsta:
even during the low effort spam attack a couple years ago we ran into a lot of issues like nodes crashing due too too large txpool
00:08:11
selsta:
so before our software is optimized i prefer slower scaling
00:08:22
boog900:
Ok, I will also discuss my proposal with people
00:08:45
ofrnxmr:xmr.mx:
@ofrnxmr:xmr.mx: @boog900:monero.social @articmine:monero.social ^ thoughts?
00:10:03
ofrnxmr:xmr.mx:
if we increase txpool size and extend expiration time to longer than 72hrs, we can also expand shirt term meduan from 100 blocks to like.. 720 (1day)
00:10:22
boog900:
@ofrnxmr:xmr.mx: that would be quite slow scaling, I am not against it but I think a few would be
00:10:29
articmine:
We just put a cap that meets the above numbers and grows by 50% a year
00:10:54
boog900:
also I do like how my proposal keeps a lot of stuff the same, there is a big benefit in keeping changes simple
00:11:01
articmine:
It can meet boog900 numbers
00:11:22
articmine:
It is t very simple change
00:11:28
ofrnxmr:xmr.mx:
16mb is 100x current volume (ringct)
00:11:46
ofrnxmr:xmr.mx:
And is 11gb per day
00:12:11
selsta:
to add to what I wanted to say, long term scaling (over a year) is less relevant for me if it allows larger growth because it allows us to do emergency changes if it is not authentic growth
00:12:24
boog900:
@ofrnxmr:xmr.mx: I would just lower the long term growth rate even more if you wanted slower scaling
00:13:23
boog900:
With my proposal, short term is 8 long term is 1.4 with 750,000 penalty free zone. This means 12mb blocks in ~2 months and ~90mb blocks in a year.
00:13:49
boog900:
still high, but better than gigabyte blocks in a year
00:13:49
selsta:
can the current software support 90mb blocks?
00:13:57
boog900:
no
00:13:58
ofrnxmr:xmr.mx:
i think 90mb blocks in a year is overkill w/o a hard fork
00:14:05
ofrnxmr:xmr.mx:
selsta: No
00:14:20
selsta:
yea then we have to limit it realistically before the software supports it :D
00:14:45
selsta:
unless the discussion currently is purely theoretical limits
00:15:13
ofrnxmr:xmr.mx:
currently i think current scaling allows much larger than 90mb
00:15:45
ofrnxmr:xmr.mx:
If we really want to test it, we should just ramp up scaling dramatocally on strwssnet and push blocks as large as we can until it breaks
00:16:09
boog900:
I took 100 mb as a hard ceiling for a year as thats the packet size limit so getting above that would be extremely hard in a short amount of time, I would support even slower scaling though
00:16:22
boog900:
@ofrnxmr:xmr.mx: its like 240mb in a year
00:17:24
boog900:
using a long term growth rate of 1.2 instead of 1.4 would be ~35 mb
00:17:44
ofrnxmr:xmr.mx:
i personally dont think we need to support over 16mb within the first year, and 50% YoY increase until we hard fork with breakthroughs that allow us to support 100mb blocks
00:17:52
ofrnxmr:xmr.mx:
50% YoY is neilsons law
00:19:01
ofrnxmr:xmr.mx:
32mb might be do-able, and once the weight changes are on stressnet can be tested accurately
00:19:09
kayabanerve:matrix.org:
I thought that was called a fallacy
00:43:25
articmine:
@boog900: So 100 Mb per block until the end of 2026
00:44:06
boog900:
no 100 MB per block as long as current median is at minimum value
00:44:31
boog900:
but as you can see selsta and ofrn both want lower
00:44:41
boog900:
like 30 MB
00:45:10
boog900:
which I wouldn't mind, which would put the long term max growth at 1.17
00:46:37
articmine:
It is 16 MB for 69 days from 1 MB ZM
00:47:04
articmine:
Just on my proposal
00:47:55
boog900:
yeah but that increases 2x every 2 months after
00:48:44
articmine:
To meet the 100 MB cap we have to set cap on the soft fork at 50MB
00:48:58
ofrnxmr:
where does the 100k blocks number come from? (why 100k? Why not 262800? Etc)
00:49:56
boog900:
@articmine: I feel like you have managed to ignore everything I have said today
00:50:15
articmine:
Not at all
00:50:32
boog900:
@ofrnxmr: tbf seen as it is already chosen, unless there is a good reason, I would just keep it as is
00:51:22
articmine:
The 100 MB is a bug that cannot be easily fit
00:51:30
articmine:
Fixed
00:51:48
boog900:
@boog900: The shorter it is the more reactive, the longer the less reactive, but you can just change the rate it is scaled by so you get the same outcome
00:52:46
boog900:
when just looking at max block size*
00:53:13
articmine:
On just sets a global cap to meet the 100 MB limit and then scarlet it at 50% per year
00:53:34
articmine:
Scales
00:54:01
boog900:
yeah but now in the second year that is a 150 MB limit
00:54:20
boog900:
etc etc for following years growing exponentially
00:54:24
articmine:
At the end of the second year
00:54:48
boog900:
I really feel just changing the current short/long multipliers is the simplest solution
00:54:49
articmine:
It is way less than your proposal
00:55:18
articmine:
And it follows Neilsen's law
00:56:39
boog900:
my proposal will have the same yearly maximum from starting at the penalty free zone forever, after 7 years yours allows gigabyte blocks again in a year
00:57:15
articmine:
What my approach will do is provide the necessary flexibility within the limits
00:58:04
boog900:
not really, it is still higher than selsta and ofrn want and it will only meet my proposal for the first year
00:58:16
articmine:
@boog900: Your proposal is over 5x vs 1.5 x per year
00:59:01
boog900:
@articmine: if someone is fully spamming block mine allows 5x, sure, someone does not need to spam with your proposal to get the 1.5x
00:59:13
boog900:
framing it as the same is disingenuous
01:00:23
articmine:
@boog900: They do because they also have to deal with my current proposal
01:00:39
boog900:
which allows gigabyte blocks in a year
01:00:52
articmine:
That stays . It is the lower of the two
01:01:29
articmine:
Min ( P1,P2)
01:01:30
boog900:
and the 100mb limit increases no matter the spam, after some years its above the gigabyte
01:01:48
boog900:
you know its not safer
01:01:58
articmine:
Come on
01:02:33
articmine:
I am not going to argue this. It is way safer since it is the lower of the two
01:03:16
boog900:
its the same in the first year, after that it is worse when we take starting from 0 and spamming for a year, correct?
01:03:51
kayabanerve:matrix.org:
Shouldn't 100 MB be a hard ceiling entirely as we're no where close to that and existing code inherently assumes blocks don't get that big?
01:04:01
boog900:
for year 1 a spammer spamming for a year can reach ~100 mb with both
01:04:01
boog900:
for year 2 a spammer spamming for a year can reach ~100 mb with mine and 150mb with yours
01:04:09
kayabanerve:matrix.org:
Yes, we can say that's a bug to fix, but this is once again designing for theoretical usage and not our actual performance
01:04:39
kayabanerve:matrix.org:
*and also, it'd have to be a bit under 100 MB so with overhead, it doesn't exceed 100 MB
01:05:45
kayabanerve:matrix.org:
I'd vote 1 MB, which is under 100 MB and should even be currently supported /s
01:05:45
kayabanerve:matrix.org:
*I'd probably look at 50, 64, or 96 MB
01:06:18
boog900:
probably but adding a hard limit would have some push back, and the limit should be way lower if we are doing that. Around 30 mb is the maximum currently before breakage IIRC. > <@kayabanerve:matrix.org> Shouldn't 100 MB be a hard ceiling entirely as we're no where close to that and existing code inherently assumes blocks don't get that big?
01:06:32
boog900:
on mainnet it is lower than that again
01:06:46
kayabanerve:matrix.org:
Eh, I don't mind having the hard limit reasonably past current perf
01:07:13
kayabanerve:matrix.org:
2x current perf is its own discussion, I'm just saying if we have a year to find 5-10% and known improvements on the way, who minds
01:07:46
kayabanerve:matrix.org:
But that'd suggest 32 MB as a hard cap on the block size limit, to be reevaluated at the next HF?
01:08:15
kayabanerve:matrix.org:
And yes, that doesn't infinitely scale, it literally is finite, but monerod doesn't infinitely scale
01:10:25
articmine:
What t current performance in a 2, 4, 6, 8, 10, 12 months time frame
01:10:57
articmine:
Provide this and I can design the cap
01:11:12
boog900:
let me get my magic ball rq
01:11:21
articmine:
Arguing endlessly is pointless
01:12:46
boog900:
absolutely I think I have a nice simple solution. Just adjusting the existing system is way simpler than bodging a dodgy safety cap on top.
01:22:29
articmine:
@boog900: I disagree. A soft fork cap can solve this. What I need is the maximum allowable blocksize vs time, based upon the stressnet work and identified issues
01:24:57
boog900:
right now IMO we should have advanced warning of blocks going to 20 to 30 MB than wayy in advanced warning of blocks going to 100 mb
01:25:15
boog900:
those limits should not change year on year
01:26:15
boog900:
As you can see my proposal covers this as although it may allow more grow other 2 years of spam, your proposal allows someone to wait a year and then they can spam that year upto 150 mb
01:26:52
articmine:
No
01:49:42
sgp_:
What about us more fundamentally agreeing that a more reasonable max of 2x in a year is acceptable. We don't need to more than double in a year even under max demand conductions. If demand is high to justify that, the doubling is faster than the rate of historical tech advancement anyway. We don't need 100x or other massive increases within a year
01:50:52
sgp_:
I'm not even for 2x, I think that's too much still. But 2x is way better than the proposed max
01:52:02
sgp_:
@ofrnxmr:xmr.mx: Or 50% max. Again, closer to reason
01:52:46
ofrnxmr:
@sgp_: 1.5x is Neilson's law tho
01:53:16
sgp_:
Yeah so even 2x max per year is too high by that metric
01:54:51
ofrnxmr:
If were using neilsons law to justify #s, then we should be consistent. I think 32mb within a year is a safe number
01:55:15
ofrnxmr:
Safe, as in, we shouldnt need more than that, and its "survivable"
01:55:54
boog900:
> <@sgp_> What about us more fundamentally agreeing that a more reasonable max of 2x in a year is acceptable. We don't need to more than double in a year even under max demand conductions. If demand is high to justify that, the doubling is faster than the rate of historical tech advancement anyway. We don't need 100x or other massive increases within a year
01:55:54
boog900:
TBC my proposal was more around using the existing system but just changing the growth rates. 100x is high, its literally the highest I wanted to go.
01:56:21
boog900:
I would support targeting 32 MB or 2x the max short term growth instead
01:57:13
ofrnxmr:
Im not saying 1.5x the penalty free zone, thats much too small. But 1.5x the max (ideally 32mb) short term limit
01:57:44
ofrnxmr:
32mb is 100x the current penalty zone, and like 200x the actual volume
01:59:01
ofrnxmr:
im also in favor of hard forking to increase these limits as soon as the software and hardware can handle them
01:59:05
boog900:
I think a short term limit of 32 is pretty high ngl
01:59:47
boog900:
I would rather be in the 16 MB range for short term
02:00:31
articmine:
@boog900: You will be
02:00:38
sgp_:
Yeah I don't care as much about the initial M(L) (though I still care somewhat). I care more about preventing it from growing faster than is reasonable. 2x max growth per year should be plenty to allow for ArticMine to support it as a "catching up" function. Even that would literally allow for faster growth than the historical rate of tech advancement
02:00:42
boog900:
Having a penalty free zone of 750,000 with a short term growth rate of 8 gives us 12mb, do we think this is enough?
02:01:37
boog900:
For a short term limit^
02:02:21
boog900:
Then max block size is 24mb at the end of the year if we ho with 2x
02:03:02
sgp_:
Max growth rate of M(L) could be reduced by lengthing the long term median blocks and/or reducing the allowed growth rate per that time period
02:03:25
articmine:
Conflict of interest
02:03:34
sgp_:
What's the current justification from growing M(L) from 1.7 to 2
02:03:35
articmine:
Is a serious issue here
02:03:36
boog900:
@articmine: Let's us talk
02:05:01
sgp_:
1.7 to the third is roughly 4.9x-ish per year, above 1.5x (Moore's law ish) and 2x per year
02:05:16
boog900:
@sgp_: https://github.com/seraphis-migration/monero/issues/44#issuecomment-3561821958
02:06:06
sgp_:
Ok so it's just due to perceived capacity shortages
02:06:32
boog900:
Pretty much
02:06:56
boog900:
Need that 1000x gigabyte blocks in a year
02:07:24
sgp_:
Lowering to 1.2 would be more sensible in my view. That's still more growth than the rate of Moore's law
02:10:28
sgp_:
Does anyone else want to allow more than 50% or 100% growth a year?
02:11:57
sgp_:
(ignoring the first base adjustment to compensate for FCMP)
02:14:28
boog900:
@sgp_: Do you have opinions on the penalty free zone or short term?
02:17:21
sgp_:
My personal opinion is that you need to assume that the penalty free and short term allowances will be filled with spam at near zero cost. Even if that's not what happens in practice, it's important to prepare for as a possibility if the price of XMR is too low to be a meaningful deterrent.
02:17:21
sgp_:
This, I'm for more conservative values there too, but I do understand others' practical desire for a temporary increase due to surge demand. I think it's unrealistic to allow, but if the limit is kept low, then the risk of network harm is minimized enough to the point of "just" being slightly annoying spam
02:19:32
sgp_:
I personally see "cheap surge space" as the same as "cheap spammer space" in practice. But if it's only 2x or whatever and temporary, then there's limited network harm and it's "just" an annoyance
02:20:36
sgp_:
The design goal needs to be that the chosen values can't cause network harm. After that I don't really care
02:36:02
sgp_:
To get to the first penalty free zone number, if probably start with the top ~10% of busiest days of Monero transactions in the last year and pick the penalty free zone weight with fcmps to allow for that. I think that's a reasonable enough place to start
02:38:58
sgp_:
With that, you'd be starting from a generous initial position, while allowing for generous long term growth (but not disastrously large if set to ~1.2), while still allowing short term surges (if you want to still allow those, maybe set to 2x). I really think that's not even a compromise, that's getting all the scaling you could reasonably want
02:45:30
ofrnxmr:
weve never had a sustained full blocks aside from some half baked spam
02:47:27
ofrnxmr:
There have been minutes where the txpool grew to a mb or 2, but never sustained (aside from >1yr old spam)
02:49:19
sgp_:
Right so there's little need to start fcmps with the same capacity even. But I wouldn't be opposed to it if you wanted to maintain the same capacity
03:59:31
articmine:
https://www.naxo.com/
04:00:14
articmine:
Please review the above carefully. Then we can talk > <@boog900> Let's us talk
04:01:46
articmine:
Pay close attention to the staff , partners and the FAQ particularly with regard to Monero and privacy
04:05:33
articmine:
By the way this is already all over https://www.reddit.com/r/btc/comments/1p6gs6y/monero_subreddit_purges_all_mentions_that_their/
04:08:57
DataHoarder:
ofc that thread has fireice_uk
04:11:05
testtank:matrix.org:
Can someone point me to a trial where the tracking of XMR provided by a BS company led to a convinction? If the answer is no than all of this is just FUD, and whoever keeps spreading rumors that the devs are selling the secret souce to trace monero should be considerer bad actors
04:11:19
articmine:
Also the complexity of BS scales as n!/((N-K)!*k!) Where n is the number of outputs in the blockchain and k I the number of allegedly illicit outputs in the block chain
04:12:35
articmine:
It is not a rumour just go to the site above and do you own research
04:12:53
articmine:
That is what I did
04:13:53
articmine:
Yes I know that the people who brought this to my attention are not friends of Monero.
04:14:43
articmine:
I just have to go with what I read from the source with my own eyes
04:17:02
testtank:matrix.org:
@articmine: exactly why i won’t believe xmr can be traced, even if the devs are rogue, until i see actual proof in a court case
04:20:00
articmine:
> <@sgp_> Yeah I don't care as much about the initial M(L) (though I still care somewhat). I care more about preventing it from growing faster than is reasonable. 2x max growth per year should be plenty to allow for ArticMine to support it as a "catching up" function. Even that would literally allow for faster growth than the historical rate of tech advancement
04:20:00
articmine:
The longer the delisting and suppression of Monero continues the sharper and more drastic the catch up will need to be once BS is put in its place by the courts
04:20:39
articmine:
@testtank:matrix.org: I do not believe Bitcoin can be traced
04:21:35
articmine:
That has not prevented this BS industry from making all sorts of claims
04:22:14
articmine:
Claims that have been very detrimental to Monero
04:26:09
articmine:
What I do know is that mas scaling of Monero on layer 1 will be the end of BS. The long term growth is the key here hence the conflict of interest
04:26:42
articmine:
Especially over the long term median growth factor
04:30:23
articmine:
Given that there are ways of dealing with the very legitimate concerns of many t the devs without touching this parameter, I cannot and will not cave in to this conduct of interest and agree to change the growth rate of ML away from 2
04:46:47
articmine:
Here is the standard that I use https://www.canada.ca/en/treasury-board-secretariat/services/values-ethics/conflict-interest-post-employment/apparent-conflict-interest.html
04:47:33
articmine:
I believe that we should meet if not exceed the standard that the state uses
04:52:27
articmine:
By the way Monero is an international project. So if other people have other conflicts of interest here standards we should choose the stricter standard
05:24:18
articmine:
As I mentioned before I am working on a solution that will have a realistic chance of getting consensus.
13:51:05
basses:matrix.org:
https://www.johndcook.com/blog/2025/11/24/monero-stealth-addresses/ , https://news.ycombinator.com/item?id=46038868
13:59:23
monero.arbo:matrix.org:
sgp isn't a dev? who are we talking about > <@articmine> By the way this is already all over https://www.reddit.com/r/btc/comments/1p6gs6y/monero_subreddit_purges_all_mentions_that_their/
14:00:20
monero.arbo:matrix.org:
regardless, I don't think having a conflict of interest should prevent someone from presenting an idea. people who don't have that conflict are there to evaluate the ideas objectively.
14:04:17
monero.arbo:matrix.org:
> <@sgp_> Does anyone else want to allow more than 50% or 100% growth a year?
14:04:17
monero.arbo:matrix.org:
10 MB blocks are working on testnet okay on some real shit ass hardware so the first 10x from 1 MB to 10 MB doesn't seem like thaaaat big a deal, but the next 10x would be very bad for network health I think. in the long run though, 100% (2x) growth YoY would be unsustainable. in 8 years you could be looking theoretically at 256 MB blocks
14:06:28
monero.arbo:matrix.org:
I think a system could be worked out where short term bursts of block space are possible, but long term growth is still restricted.
14:08:20
monero.arbo:matrix.org:
I guess by eating the block penalty with higher fees you get, what, up to 2x block size instantaneously? if fees are high enough. so that's your short term burst. would it be feasible to increase that by lowering the penalty, so that by the time you sacrifice the full 0.6 block reward, the block is say 3x the penalty free size?
14:11:14
elongated:matrix.org:
Assume price doesn’t increase and someone keeps spamming for cents, it will make xmr unusable for most ppl.
14:11:14
elongated:matrix.org:
Noobs struggle syncing wallet with current block size.
14:13:54
monero.arbo:matrix.org:
there's a lot of syncing improvements that aren't on mainnet right now but yeah, there's definitely a tention between the desire for low fees and the ability to drive up block size for very cheap
14:15:06
monero.arbo:matrix.org:
that's why I keep saying the fee market is an important part of restricting block size growth. the growth rate needs to be slow enough that fees are driven up in order to increase block size, implying the demand is more likely to be "real", since people are paying real money for it, not pennies
14:15:50
monero.arbo:matrix.org:
low fees ---> high fees while blocks grow slowly to meet demand ---> low fees again
14:15:50
monero.arbo:matrix.org:
but the high fee period is actually important
14:40:04
articmine:
We are talking about sgp > <@monero.arbo:matrix.org> sgp isn't a dev? who are we talking about
14:43:53
articmine:
@monero.arbo:matrix.org: High fees can kill the peer to peer decentralized economy
14:44:18
articmine:
This is what happened in Bitcoin
14:45:29
articmine:
People leave and don't come back
14:46:46
monero.arbo:matrix.org:
the bitcoin economy is dead?
14:47:07
articmine:
As peer to peer cash yes
14:48:10
monero.arbo:matrix.org:
adoption seems higher than ever from where I'm sitting. I get more BTC payments than XMR payments, I can tell you that 100% for sure
14:49:23
articmine:
@monero.arbo:matrix.org: because XMR has been suppressed, by the BS lobbying
14:49:44
monero.arbo:matrix.org:
I'm not saying I want $50 fees like Bitcoin had at some point, but I am saying their usage is waaaay higher than ours so it seems funny to me to call it dead
14:50:29
monero.arbo:matrix.org:
@articmine: that feels like cope, especially if you think that this ending is likely to lead to something like 100x surge. you're not being grounded in reality
14:51:26
articmine:
I bought dinner in a restaurant in downtown Vancouver with Bitcoin 13 years ago. Not possible today
14:52:02
boog900:
@monero.arbo:matrix.org: At a certain point I don't see how you can get around this, for example if the short term growth is maxed out and every one is paying $50, what choice do you have?
14:52:40
monero.arbo:matrix.org:
that doesn't actually mean fees killed it. there's a lot of things, like laws around keeping track of capital gains losses, spending BTC counting as selling it, lots of reasons besides the fee narrative
14:53:24
monero.arbo:matrix.org:
@boog900: fair enough, but BTC had a very restrictive and ungrowing cap, which we don't. but yes, they could get that high under pretty much any plan except infinite blocks
14:54:12
boog900:
@monero.arbo:matrix.org: oh yeah I wasn't trying to say bitcoin was good
14:54:22
articmine:
@monero.arbo:matrix.org: Had? No has.
14:54:25
monero.arbo:matrix.org:
oh I know dw
14:56:31
monero.arbo:matrix.org:
anyway AM don't you think the fact that using Bitcoin (or XMR for that matter) as cash is a tax nightmare has at least as much to do with it as the high fees?
14:56:32
boog900:
I actually think our algorithms are bad in this case, you should be able to pay stupid high fees to get your tx included.
14:56:53
monero.arbo:matrix.org:
aside from the preference for stability, I think this is the other major reason stablecoins have taken over for payments. no accounting headaches
14:57:18
monero.arbo:matrix.org:
@boog900: interesting point
14:57:28
gingeropolous:
yeah. I dunno how things are gonna shake out while we're still in this transition period with everything being a reference currency
14:57:39
boog900:
fees should be based on when you want the tx in a block, within 1 block, 10, 100 etc
14:57:58
boog900:
then we also need RBF
14:58:13
articmine:
@boog900: Try paying with USD in Canada. Same tax accounting issue
14:59:13
gingeropolous:
well a stupid high fee will will get your tx in the next block
14:59:51
boog900:
@gingeropolous: the wallet software maxes out at an algorithm that does not take into account the txpool
15:00:07
gingeropolous:
i thought it does take into account the txpool
15:00:33
monero.arbo:matrix.org:
I think the point is the max fee might not be maximum enough
15:00:33
gingeropolous:
when I use the CLI, it'll say "with this fee you can expect your tx to be in a block within x blocks. Is this ok?"
15:00:43
articmine:
We have fee tiers in Monero because of privacy
15:00:55
boog900:
its all on block medians AFAIK
15:01:10
boog900:
you can't overcut everyone in the pool
15:01:13
gingeropolous:
uhhhh i don't think so, because the median hasn't moved
15:01:20
rucknium:
AFAIK, the max fee with always get your tx into the next block unless everyone is paying max fee. That's how the penalty is designed.
15:01:22
gingeropolous:
and ive seen that message
15:01:24
articmine:
You got to choose fee levels
15:01:42
articmine:
This is a privacy issue
15:01:52
boog900:
@rucknium: yeah exactly you should be able to outbid even if everyone pays the max fee
15:02:04
gingeropolous:
then we need supermax
15:02:06
articmine:
I am actually proposing an extra fee level
15:02:08
gingeropolous:
max ultra fee
15:02:08
rucknium:
With max fee you pay enough to the miner to fully compensate for the penalty they will take when they include your tx in a block.
15:02:10
boog900:
@articmine: if everyone uses the same algo for levels it shouldn't be
15:02:13
monero.arbo:matrix.org:
@rucknium: not "everyone", just more people than can fit in a block
15:02:52
ofrnxmr:
It does > <@gingeropolous> i thought it does take into account the txpool
15:02:55
boog900:
@rucknium: yes but you should be able to outbid people so miners want to include your tx more
15:03:28
rucknium:
If enough people are paying the max fee, soon the short-term (100 block) median should rise and that would relieve the demand pressure.
15:04:13
boog900:
@rucknium: what if growth of the short term is maxed out or you can't wait for that to happen?
15:04:27
gingeropolous:
so worse case scenario, we're talking 50 blocks * 2 minutes = 1 hour if everyones at max fee for first inclusion
15:05:00
boog900:
@gingeropolous: no, you still need to wait for txs before yours to confirm
15:05:02
ofrnxmr:
50 blocks * 2 min = 1 hour? You mean 30 blocks?
15:05:03
rucknium:
IMHO, the actual problem with the short term median is that if there a brief pause in tx volume, the median resets all the way back to the original block size.
15:05:06
articmine:
@rucknium: This is true as long as we do not hit the maximum limit of the short term median
15:05:18
gingeropolous:
well for better or worse fee levels aren't enforced by consensus at this point. so a wallet provider could create a feature called Next Block Guarantee and pay like 100x fees
15:05:59
articmine:
If we do the Bitcoin like fee market will last until the long term median. Moves
15:06:03
ofrnxmr:
@rucknium: Technically you can have 49 empty blocks w/o losing the median
15:06:16
monero.arbo:matrix.org:
@rucknium: so there should be some limit to the block de-growth rate?
15:06:32
gingeropolous:
yeah the long tail has been something i tried to figure out once
15:06:34
gingeropolous:
the decay
15:06:36
ofrnxmr:
@gingeropolous: 1000x is the max fee priority /lvl 4
15:06:49
boog900:
The algorithms to decide fee rate don't, you can just look at the scaling doc > <@ofrnxmr> It does
15:06:55
gingeropolous:
ok, so 10,000x!
15:07:06
boog900:
the wallet may tell you when it expects to be included though
15:07:38
rucknium:
IMHO, it could make sense to have elastic supply throughout the length of the supply curve (i.e. at any point, you can pay a higher fee to get your tx into the next block), but it's a minor problem compared to the main points of contention.
15:07:45
gingeropolous:
scaling doc? since when does our code match the docs....
15:07:47
ofrnxmr:
@boog900: Yeah, they only bump to lvl 2 if recent blocks are 80% full, or txpool has a backlog
15:08:43
ofrnxmr:
Theres a pr to set auto to lvl 3 (16x) is there a backlog over 12hrs at lvl 2
15:08:57
boog900:
@ofrnxmr: ok the algorithms to decide between which fee levels may take into account the pool but the 3 fee rates themselves don't
15:09:12
sgp_:
This is why I suggested the power of two fee denomination idea lol
15:09:40
articmine:
@sgp_: Conflict of interest
15:09:58
sgp_:
Lmao how does setting a power of two fee kill Monero. Ffs
15:10:28
boog900:
@rucknium: There was talk yesterday of significantly reducing scaling, so it does become more relevant then.
15:11:59
DataHoarder:
seems for articmine anything you say in this room now is conflict of interest sgp_
15:12:19
sgp_:
In a competitive enough market, people will just bribe miners if the allowable fee tiers aren't sufficient. Which should be reduced if possible for decentralization
15:12:41
DataHoarder:
if it's about that MRL issue about allowing all powers of two, that had other issues around traceability /signatures, but allowing higher fees? yeah :D
15:13:15
sgp_:
There should be no "max fee" imo
15:13:20
gingeropolous:
and there should be some math on whether miners are ever incentivized to keep blocks small in order to drive up tx fees for their benefit.
15:13:35
DataHoarder:
yes. max monero generated coins :P
15:13:45
sgp_:
Yup that should be the only max :)
15:13:57
gingeropolous:
like if the tx pool is full of max fee txs, the miners could just mine those in a block and gobble up the fees and not expand at all
15:14:44
sgp_:
@gingeropolous: A competitive mining market prevents cartels keeping blocks small. Else mining is not competitive and pow is broken
15:14:51
gingeropolous:
though i think i've brought this up before and the consensus was that miners would prefer to mine the low fee txs so that other miners don't get them
15:14:58
sgp_:
So we get that solved "for free" with the pow security assumptions
15:15:03
DataHoarder:
if 51% yes, gingeropolous
15:15:09
DataHoarder:
as they can eliminate other blocks
15:15:16
DataHoarder:
otherwise other miners will snatch them
15:15:29
sgp_:
Basically if that's a concern, then pow is already broken
15:15:32
DataHoarder:
up to the point that growing the block gives them less reward
15:16:03
rucknium:
@gingeropolous: This paper has that math for Bitcoin. Theorem 1: https://moneroresearch.info/78 Huberman, G., Leshno, J. D., & Moallemi, C. (2021). Monopoly without a Monopolist: An Economic Analysis of the Bitcoin Payment System, The Review of Economic Studies, 88(6), 3011–3040.
15:16:25
articmine:
One needs an insane fee if one restricts growth until one drives the user's away
15:16:29
gingeropolous:
noice
15:16:39
sgp_:
There's no way to prevent high fees
15:17:15
sgp_:
Even if there's a "max fee" of $1-ish (just an example), those txs won't be mined if the actual price is $10 since miners will be paid out of band
15:17:28
articmine:
Restricting growth is necessary to attempt to keep BS alive
15:17:29
gingeropolous:
prevent high fees temporarily. eventually the protocol reaches a new steady state and fees go down.
15:17:30
DataHoarder:
on the topic of 51%, Qubic has still not released view keys since Wednesday, and last few weeks they had downtimes of 1d+ due to not checking. I think they lost interest besides keeping up appearances that they are still mining monero
15:17:46
DataHoarder:
with FCMP++ as well, ArticMine?
15:17:51
sgp_:
You need unlimited block capacity to fully prevent high fees. Unlimited
15:17:56
monero.arbo:matrix.org:
I don't wanna get all econ 101 but it's a supply and demand issue. We should (imo) expand supply as much as is reasonable (which people may disagree on) but ultimately we don't really control the demand side, so it's always possible that it could exceed supply
15:18:01
sgp_:
Not high. Unlimited
15:18:04
gingeropolous:
in a spam attack
15:18:52
gingeropolous:
if the network reaches a steady state of 500kb blocks, then that is the new penalty free zone. So, no high fees
15:20:08
gingeropolous:
and the algorithm automagically actually lowers the fee as the block size grows
15:20:13
gingeropolous:
the base fee
15:20:28
gingeropolous:
to account for "big blocks equal number go up"
15:20:42
gingeropolous:
according to the blockchain reality
15:21:16
gingeropolous:
and i know this idea has been bandied about and i've heard good arguments against it... but coupling PoW and base fee.......
15:23:13
articmine:
@monero.arbo:matrix.org: The existing and my proposed scaling increase supply in exchange for cost. This is how an economy works with a proper fee market
15:23:50
articmine:
Bitcoin is very unusual. No increase in price will increase supply
15:24:02
monero.arbo:matrix.org:
@articmine: I hear you I just think the maximum allowable scaling is too aggressive
15:24:37
monero.arbo:matrix.org:
at some point more demand shouldn't actually equal more supply, if the network does not have the capacity
15:25:25
monero.arbo:matrix.org:
it's just a question of, do you put in a limit, or do you just let the network start fracturing naturally as nodes fall off the network and sync times balloon
15:25:25
articmine:
@monero.arbo:matrix.org: I hear you. This being said to reach consensus on has to eliminate conflicts of interest
15:25:49
monero.arbo:matrix.org:
you're worried about high fees as effectively a DoS attack, but having a blockchain that's more bloated than users can process is also an effective DoS
15:26:17
monero.arbo:matrix.org:
@articmine: I said earlier, my opinion is that conflicts or not, people should be able to present their ideas. As long as they aren't in charge of decision making, which sgp isn't
15:27:07
monero.arbo:matrix.org:
it's important that conflicts are acknowledged, but we all know
15:27:36
articmine:
If you influence or attempt to influence the decision makers that triggers a conflict of interest
15:28:18
monero.arbo:matrix.org:
arguing your position logically isn;t "attempting to influence" in that I don't view it as a sort of corruption the way say, waiving money around would be
15:28:46
monero.arbo:matrix.org:
technically it's attempting to influence, sure, but people can read arguments and draw their own conclusions
15:29:55
monero.arbo:matrix.org:
I just think it would be more productive to acknowledge your points and move on. Or what solution do you propose, that sgp just isn't allwoed to speak on the topic?
15:30:04
monero.arbo:matrix.org:
/genuine
15:30:49
DataHoarder:
effectively everyone else but you is saying to limit a bit more. but you say this is not valid due to conflict of interest on sgp
15:31:32
DataHoarder:
but ... it's not just sgp, seems to me it's being used as a way to just push higher scaling that network can't support yet, even when the rest of people agreed and showed on stressnet without sgp even
15:33:13
articmine:
DataHoarder: One cannot have a rational conversation to reach consensus when at the same time someone else is aggressively pushing a conflict of interest and has done so far years
15:33:56
monero.arbo:matrix.org:
okay I hear you but I wouldn't really say sgp seems aggressive about his ideas
15:33:57
rottenwheel:unredacted.org:
@articmine: > aggressively
15:33:59
rottenwheel:unredacted.org:
what?
15:34:00
DataHoarder:
this point has been acknowledged and sgp saying the same thing as the rest of the room doesn't invalidate the position of the rest of the room
15:34:09
monero.arbo:matrix.org:
he's like not even really defending himself as you talk shit
15:35:11
articmine:
This is the harm that conflict of interest creats
15:35:14
datahoarder:
if it makes articmine happy maybe @sgp_:monero.social can change display name here to "sgp (conflict of interest)" so they can stop bringing that point up each message
15:35:17
rottenwheel:unredacted.org:
jesus christ, how many times do we have to break it down for this dude? it's literally like talking to a wall...
15:35:32
gingeropolous:
imo the existing scaling algorithm is a lot. If we can trust that webpage i made, in 1000 blocks with max flood we get to 30 MB blocks with 600 xmr spent.
15:35:40
quadriocellata:matrix.org:
DataHoarder: agreed
15:36:44
gingeropolous:
i mean i guess that is 250k USD, which isn't nothing
15:36:46
monero.arbo:matrix.org:
ArticMine: I know I've been annoyed with you recently but I like and appreciate you but you gotta take a step back and read the room brother
15:36:59
monero.arbo:matrix.org:
Also I jsut realized your name is Artic and not Arctic
15:37:08
articmine:
@datahoarder: He needs to recuse himself from attempting to influence the Monero code
15:37:23
rottenwheel:unredacted.org:
@articmine: Unbelievable.
15:37:54
articmine:
That is the proper way to deal with a conflict of interest
15:37:54
gingeropolous:
so make the argument why he shouldn't
15:38:39
monero.arbo:matrix.org:
god forbid a man have an idea
15:38:56
rottenwheel:unredacted.org:
@articmine: There's no conflict of interest and nobody is trying to influence any code, because he cannot make decisions, he's only proposing something. How many times and how many people do you need to read it from until it gets through your obtuse skull?
15:39:03
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 way and stopping BS
15:39:55
gingeropolous:
there's no emoji for "here here" or is it "hear here"
15:40:21
rottenwheel:unredacted.org:
@gingeropolous: I did it for you. Tap on it.
15:40:34
datahoarder:
At this point I just see more delays every week and infinite discussion around general consensus already, except bringing up the "this is not enough in a hypothetical growth (that cannot be supported)"
15:41:22
gingeropolous:
yeah. i mean the reality is we all know that our hardforks are getting few and far between, so we see an opportunity to improve the resilience of the network and we're all bouncing around the room trying to figure it out
15:41:31
monero.arbo:matrix.org:
It was mentioned a few days ago that the people (myself included) who want more modest scaling parameters need a concrete counter proposal
15:42:18
monero.arbo:matrix.org:
unless I missed what the counter to AMs proposal was, other than sgp's
15:43:07
monero.arbo:matrix.org:
AM mentioned they were working on something so hopefully they take the feedback from the room seriously
15:43:24
articmine:
I am
15:43:29
sgp_:
I suggested lowering the long term growth rate from 2 to 1.2 and got the response "nack because Justin big bad". Artic has no interest in anything other than their near infinite scaling death cult
15:43:52
monero.arbo:matrix.org:
@articmine: well then go work on it and stop fighting us <3 <3
15:44:18
articmine:
@sgp_: You proposed to cap the growth at 2x per year
15:44:20
sgp_:
I pay everyone else in the channel to oppose you as well, you got me!
15:44:59
articmine:
After Monero is supposed for an undefined amount of time
15:45:33
boog900:
@sgp_: I also suggested 1.4 yesterday with willingness to drop it even lower if there was consensus
15:45:36
articmine:
Suppressed
15:46:24
sgp_:
@boog900: Thanks, make sure to send me your address for payment
15:46:30
boog900:
selsta thought even 1.4 was too high
15:47:05
sgp_:
1.4 is too high lol
15:47:11
gingeropolous:
aight. what are the goals. 1. low fees to promote p2p cash-like usage, 2. sustainabile block growth to handle p2p cash-like usage 3. limited block growth to prevent network catastrophe
15:47:24
boog900:
it kept us under 90 mb in a year :p
15:47:32
boog900:
not under, around
15:48:16
boog900:
which is extremely high but I felt was a good compromise
15:48:34
sgp_:
Fwiw it is way better than 2 which isn't saying much
15:48:40
boog900:
as artics allows gigabyte blocks in year
15:48:45
articmine:
I can work with less. > <@boog900> it kept us under 90 mb in a year :p
15:48:50
gingeropolous:
i think 3 is the main unknown. Surely there are numbers on the theoretical bandwidth limitations. That should be like the maximum theoretical cap. The cap underneath that, which is what we ideally want to target, is the processing capacity.
15:49:22
gingeropolous:
and we can't get stressnet to get my 18 yr old CPU from falling behind
15:49:25
sgp_:
Ironically 3 is the most knowable of the three. 1 and 2 are just demand predictions
15:49:52
articmine:
I cannot agree to throttle scaling at the back end which Monero is being suppressed by the BS companies and their lobbying
15:50:19
ofrnxmr:
@gingeropolous: reword this plz
15:50:45
gingeropolous:
ideally we'd find the blocksize in stressnet that would make my scrap heap unable to stay synchronized
15:51:03
monero.arbo:matrix.org:
@gingeropolous: part of that is, what kind of hardware do we want a node to be able to run on. one concern I have is that a lot of XMR users don't have access to very good hardware. or would we expect them to user some sort of light wallet under carot?
15:51:46
datahoarder:
@articmine: If FCMP++ needs that it might end up being done with conservative parameters. At the moment this is just a small version of what BS or exchanges could be done with tagged known outputs https://p2pool.observer/sweeps
15:51:50
ofrnxmr:
@gingeropolous: a few weeks ago, it couldnt
15:52:31
gingeropolous:
because currently this "Intel(R) Pentium(R) CPU G6950 @ 2.80GHz, 4GB ram, 300GB SATA HDD" syncd and is staying sycnhronized
15:52:32
monero.arbo:matrix.org:
one of the default GUI modes right now is to run a full node but only spin it up when the wallet is opened, meaning their node has to catch up potentially months of transactions..... this is something I would be open to changing, but as is we encourage a lot of users to use XMR this way
15:52:56
ofrnxmr:
@ofrnxmr: 1.5 and flufy block,dynamic sync size and a few other fixes changed thatr
15:53:21
gingeropolous:
@ofrnxmr: ok, then we need to find the new limit
15:53:31
articmine:
@gingeropolous: What blocksize?
15:53:41
ofrnxmr:
We still have txrelay ,serialization, packet size
15:53:49
ofrnxmr:
@articmine: 10+
15:54:33
articmine:
10+ MB
15:54:39
ofrnxmr:
Ya
15:54:43
monero.arbo:matrix.org:
yes
15:54:52
ofrnxmr:
Less than15
15:55:17
gingeropolous:
and that size is currently limited to how much you can spam the network due to.....
15:55:24
ofrnxmr:
We can push to 30or 40 if i can get some help
15:55:41
gingeropolous:
you just not have enough outputs?
15:55:47
ofrnxmr:
@gingeropolous: Coinbase lock times absotlrbing fees
15:56:18
ofrnxmr:
And it uses a lot of resources (>100gb ram)
15:56:28
ofrnxmr:
(wallets)
15:56:42
monero.arbo:matrix.org:
post the script or whatever in #monero-stressnet:monero.social I can help for sure > <@ofrnxmr> We can push to 30or 40 if i can get some help
15:56:52
gingeropolous:
well luckily u have a 1TB
15:57:00
ofrnxmr:
Ruckniums script is public
15:57:20
monero.arbo:matrix.org:
yeah I jsut mean share th elink
15:57:26
gingeropolous:
we'd need to proper experiment this tho. run the daemons on the scrap heap with open RPC ports, have someone scrap status data or something
15:57:34
ofrnxmr:
@monero.arbo:matrix.org: I dont have it 😅
15:57:44
datahoarder:
if you make low fee txs I could burn monero in blocks with a custom txpool selector > <@ofrnxmr> Coinbase lock times absotlrbing fees
15:57:53
rucknium:
@monero.arbo:matrix.org: https://github.com/Rucknium/xmrspammer
15:57:55
articmine:
What are the current limits for
15:57:55
articmine:
Tx relay
15:57:55
articmine:
Serialization [... more lines follow, see https://mrelay.p2pool.observer/e/geXUzs0KQ1BDLWNz ]
15:58:06
datahoarder:
As mentioned, but maybe for next stressnet, not current
15:58:15
gingeropolous:
yeah
15:58:23
gingeropolous:
is the plan to roll it back and start fresh?
15:58:33
ofrnxmr:
@articmine: 1. Brb
15:58:33
ofrnxmr:
2. 30mb
15:58:33
ofrnxmr:
3. 100mb
15:58:47
ofrnxmr:
@gingeropolous: Likely
15:58:51
datahoarder:
@gingeropolous: testnet has continued working, so it'd be another hardfork there so yep a rollback
15:59:15
ofrnxmr:
Current is gettingbig
15:59:46
gingeropolous:
i should get the real shit to try and sync too. I got some intel atom in a acer sometihng or other that just makes me sad that some company thought to sell it
16:00:24
articmine:
Brb?
16:00:57
gingeropolous:
prolly be right back, getting the data
16:00:59
articmine:
Clarify?
16:01:06
sgp_:
Does anyone else oppose these tweaks or have feedback on them?
16:01:06
sgp_:
1. Decrease the max long term growth median rate from 2 to 1.2. That would still allow a max growth rate of roughly 70%, which is still high. But since this is the maximum, it's probably not catastrophic. 1.1 would be safer.
16:01:06
sgp_:
2. Decrease the surge demand multiple from 16x to 2x. Or whatever other number there is consensus on. I'd advocate removing it completely but it's not my call.
16:01:06
sgp_:
3. Allow denominated power of two (or even more frequent) fees to allow for a fee market in competitive demand conditions. Keep the in default fee I guess (even though I hate it).[... more lines follow, see https://mrelay.p2pool.observer/e/1KDgzs0KYS1mSXRr ]
16:02:18
articmine:
Opposed
16:03:08
ofrnxmr:
@gingeropolous: Im 1 handed atm, ya be right bk
16:03:18
gingeropolous:
off the cuff they feel too restrictive.
16:03:32
sgp_:
Yeah but what part is specifically and why
16:03:43
articmine:
@gingeropolous: Way to restrictive
16:03:44
sgp_:
Do we need more than 70% growth per year
16:04:05
articmine:
@sgp_: Yes because of BS suppression
16:04:06
gingeropolous:
well thats why its off the cuff. i can't put my finder on it. and off the cuff the existing 50x seems like too much
16:04:27
rucknium:
Does the growth function have to be exponential? Get creative.
16:04:39
gingeropolous:
if i could just figure out to host this wasm thinger on github pages
16:05:25
articmine:
@rucknium: It can be capped to Nielsen's Law
16:05:45
sgp_:
70% > 50%
16:06:31
articmine:
@sgp_: After accepting for BS suppression surge
16:06:44
sgp_:
You should be advocating for an initial increase to account for the "suppression" not a massive growth rate from there
16:06:48
articmine:
It comes down to t initial conditions
16:07:06
sgp_:
I don't agree with your logic but that would be a better way of trying to do your logic
16:07:24
gingeropolous:
if this suppression exists, I don't think it would take long for the existing algorithm to adapt to whatever the non-suppressed volume is
16:07:43
articmine:
@sgp_: We don't know how long the suppression will last
16:08:20
sgp_:
You're asking for a blank check to grow massively without restriction then, which is infeasible
16:08:39
articmine:
@gingeropolous: It has been going on at least since 2019
16:08:58
articmine:
@sgp_: No I am not
16:09:01
datahoarder:
Once this suppression is gone, then any hypothetical limits or pressure to hardfork or make changes would be gone, which means we can then include a different scaling?
16:09:07
sgp_:
Why can't we say if this suppression exists, it'll only be temporary since we already set the growth rate to max 70% per year so it'll catch up in time
16:09:29
datahoarder:
If it's an unknown time, unknown scale, unknown scope, it's asking to add something in consensus for who knows what/when/which scale
16:10:02
articmine:
@sgp_: Over a long time decades it should be 50% based upon Neilsen's Law
16:10:29
sgp_:
Jesus I want to scream at my computer. Your proposal allows way way more than 50% and 70%
16:11:21
articmine:
@datahoarder: We used a sanity median or cap at 50 %
16:11:29
articmine:
For the long term
16:11:45
gingeropolous:
c'mon 5 million blocks simulation. finish already...
16:12:26
boog900:
@sgp_: but just look at it in this one specific way!
16:13:22
rucknium:
@gingeropolous:monero.social: Needs to be converted into a differential equation so you can compute the end state instantly :)
16:14:34
articmine:
Are we in agreement on a long term 50% cap?
16:14:45
boog900:
no lol
16:14:46
ofrnxmr:
@articmine:monero.social the limit to txrelay isnt a hard number. The problem is that current protocol amplifies the relay, leading to much larger ram and bandwidth usage for each peer that you have
16:15:05
ofrnxmr:
For well connected nodes, a large txpool can cause them to go offline due to running out of memory
16:15:06
sgp_:
No but I prefer it to 700% lmao
16:16:13
boog900:
@articmine:monero.social: that 50% cap will move without any increase in txs right?
16:16:30
gingeropolous:
so if you want to self host or whatevs this newer version has the wasm magic that makes it really fast: https://github.com/Fountain5405/adaptiveblocksizesim
16:16:34
sgp_:
I would feel we are at least making progress if you lowered the max long term growth rate from 2 to 1.2
16:16:35
boog900:
at least that is what you proposed yesterday
16:16:38
articmine:
Correct
16:17:04
articmine:
But it is also subject to my current proposal.
16:17:08
ofrnxmr:
@sgp_: is this 1.2 for every 100k median?
16:17:17
articmine:
So the lower of the two
16:17:28
sgp_:
Oh this is yet another proposed cap not adjusting the long term median?
16:17:41
sgp_:
Why not just adjust the long term median
16:18:14
boog900:
@sgp_: because this way in 7 years we get gigabyte blocks again within a year with no spam before
16:18:19
articmine:
@sgp_: It does not address BS suppression
16:18:28
sgp_:
Ugh
16:18:42
boog900:
trying to sneak in dangerous scaling
16:18:52
articmine:
@boog900: No
16:19:00
sgp_:
I can't argue with something for which there's no quantifiable evidence. It just leads to irrational decisions detached from reality
16:19:13
sgp_:
Even if you think it exists, the scale is incalculable
16:19:48
gingeropolous:
i think we could reasonably use any existing mature network as some sort of reference. bitcoin, ethereum, etc
16:19:58
boog900:
@articmine: its exactly what you are trying to do by arguing yours is more restrictive when you know its not
16:20:10
articmine:
@sgp_: Are you going to deny CEX delisting s and the role of BC S companies in this
16:20:20
sgp_:
Lol. Monero would totally have as many transactions today as Ethereum plus all it's L2s if it wasn't suppressed. Totally.
16:20:22
articmine:
Back to conflict of interest
16:20:46
sgp_:
@sgp_: My point is that this is just witchcraft dressed up as "math"
16:20:55
gingeropolous:
well perhaps not the same, but its some sort of real world number
16:21:04
articmine:
This is why conflict of interest makes it impossible to reach consensus
16:21:21
gingeropolous:
what is the tx rate of ethereum these dayus
16:21:49
gingeropolous:
yes i agree its not apples to apples but at least its a fruit
16:21:58
gingeropolous:
as opposed to these ghosts we're chasing
16:22:03
sgp_:
Personally I see no need for any additional allowance if adjusting the long term median would still allow growth of 50% per year. That still seems more than generous, and any "suppression" would be swiftly taken care of if demand actually grew that fast
16:22:17
articmine:
It has also been flat. POS validators are obligated entities under AL
16:22:30
articmine:
AML
16:22:51
sgp_:
Yes the specific law "AML"
16:23:40
sgp_:
This is why all eth validators in the world have been arrested or are banks
16:24:22
articmine:
@gingeropolous: https://bitinfocharts.com/comparison/ethereum-transactions.html#log&alltime
16:25:14
articmine:
@sgp_: They are pressured behind the scenes
16:25:50
sgp_:
Blockchain surveillance companies won't stop until all blockchains are completely killed through suppression. Then they will have won
16:26:20
articmine:
We both know. that BS does not scale. Can we stop this pointless argument
16:26:49
elongated:matrix.org:
@sgp_: Thanks for confirming
16:28:33
boog900:
@articmine: honestly I don't even know if I agree here, yes more txs are better but VISA isn't exactly private.
16:28:59
articmine:
@boog900: It actually is
16:29:16
articmine:
Because of it's size
16:29:23
sgp_:
Artic why don't you work for visa ha
16:29:31
boog900:
@articmine: fair at least you are consistent
16:29:43
boog900:
although I obviously disagree that VISA is private
16:29:56
datahoarder:
seems like more people than just sgp have reached similar consensus, but you discount this consensus due to sgp agreeing the same > <@articmine> This is why conflict of interest makes it impossible to reach consensus
16:30:28
sgp_:
I can take one for the team and start supporting artic's original proposal if that'll help :)
16:30:39
boog900:
lol
16:30:55
ofrnxmr:
Is the "1.2x" or "2x" etc, in reference to the max growth withing the LTM?
16:31:16
sgp_:
When I was using those numbers, yes
16:31:26
boog900:
@ofrnxmr: its a multiplier on the short term growth
16:32:27
boog900:
so if you allow maximum of 16 mb blocks in the short term then the next period is 1.2 or 2x that
16:32:55
boog900:
with the current formula anyway
16:33:43
articmine:
It is currently 1.7 x
16:33:55
gingeropolous:
50k blocks takes 5667ms. 100k blocks takes 9030ms. 200k blocks takes 28429ms. and 300k blocks takes 63806ms. But 500k blocks has been running FOREVER
16:34:04
sgp_:
Which I argued when you picked 1.7 before was too high
16:34:05
ofrnxmr:
makes sense. My vote is 16 or 32mb max block size within STM, and neilsons law for LTM
16:35:20
articmine:
@sgp_: You picked 1.7 I had proposed going t 2
16:35:46
articmine:
At least let us get the facts right
16:35:56
gingeropolous:
oh shit, 500k finished. 464290ms
16:36:48
articmine:
@gingeropolous: What exactly took this time?
16:36:56
ofrnxmr:
He has a simulator
16:37:08
articmine:
On what hardware
16:37:26
ofrnxmr:
Not monerod sim, just scaling sim
16:37:29
gingeropolous:
ok with max flood, growth factor of 2x, M_N cap factor of 50, long term median index 50k (so 100k long term window), short term 50 (100 long term window), we get 243 MB blocks and it costs 60958.436749 XMR to get there
16:37:30
sgp_:
I guess I did say at the time that 1.7 was an "okay" compromise
16:37:30
sgp_:
https://github.com/monero-project/research-lab/issues/70#issuecomment-785193630
16:37:32
ofrnxmr:
A website
16:37:56
gingeropolous:
lol and the mempool got to 43878.94 GB
16:38:23
sgp_:
My comment did caveat that if that growth target was actually hit, we'd need a hard fork to lower it
16:38:55
gingeropolous:
and it took 500k blocks
16:39:35
articmine:
@gingeropolous: Hardware?
16:40:06
gingeropolous:
its just a simulator. this isn't actual monero
16:40:08
gingeropolous:
https://github.com/Fountain5405/adaptiveblocksizesim
16:40:50
gingeropolous:
im having trouble hosting it on github pages, but if you just run it locally you can fiddle with it. caveat that its llm conversion of @spackle:monero.social 's work, from python then to javascript then to wasm
16:41:02
gingeropolous:
because OPTIMIZATION
16:41:55
gingeropolous:
but im out. peace y'all. till next time
16:42:08
ofrnxmr:
Whats the website for the old one
16:43:31
articmine:
@sgp_: You don't
16:43:57
articmine:
That was the whole point of issue 70
16:44:07
boog900:
@ofrnxmr: https://gingeropolous.github.io/blocksizejavasim/lastpurejavascript.html
16:44:36
sgp_:
> If we set this threshold this high [to 1.7], my understanding is that we would need to adjust it downward again with consensus if Monero grows to be a large network.
16:44:43
articmine:
It goes down at the same rate as it goes up for the long term median
16:45:03
boog900:
@articmine:monero.social: current scaling allows 425mb blocks at max right?
16:45:48
boog900:
in a year*
16:45:49
articmine:
After how many blocks
16:46:01
boog900:
@articmine: years worth
16:47:40
articmine:
Correct.
16:49:25
boog900:
even worse than the 244 mb number I got before
16:49:46
articmine:
I believe the simulation estimates the cost to get there
16:50:10
articmine:
It ain't cheap
16:50:47
boog900:
why do we need 1400x lol
16:50:53
boog900:
at all
16:53:54
articmine:
What is needed is a 16x short surge. We went over this,, and the ability to do a 100x surge in a year based upon past Monero and Litecoin data.
16:54:16
articmine:
We don't need to max this out for ever
16:54:45
sgp_:
We would need a hard fork to remove it later then should a surge happen
16:55:07
boog900:
Yeah but like that was more a question of what was going on when the decision for that much growth was made
16:55:20
articmine:
This is why a 1.5 x per year cap on top is appropriate
16:55:48
articmine:
The only real argument I see is the initial conditions
16:56:58
articmine:
Then we don't need a HF
16:57:04
sgp_:
I do see "catching up" to Bitcoin's current use to be within reason. Idk if that's the same as 100x tho
16:57:21
ofrnxmr:
100x from current is 30mb
16:57:32
ofrnxmr:
(for fcmp)
16:57:45
articmine:
@sgp_: Bitcoin gas been suppressed. We all know that
16:57:58
sgp_:
Yeah but despite that it works
16:58:05
articmine:
So that is not the standard
16:58:13
sgp_:
And if permitted to continue to grow at 50%, it would still work better
16:58:13
articmine:
@sgp_: It does not
16:58:25
articmine:
As peer to peer cash
16:58:45
articmine:
Again back to conflict of interest
17:01:38
articmine:
If Bitcoin had allowed 50% growth from the start starting at 1 MB blocks it will exceed 1 GB blocks next year
17:02:02
articmine:
So yes then it would have worked
17:02:45
sgp_:
So allow Monero to catch up and then 50% max. At least I see that as roughly within reason versus 100x+
17:03:27
articmine:
@sgp_: To catch up to where Bitcoin should have been yes
17:04:48
sgp_:
Eh then you lose me since the actual sizes would be impractical
17:06:18
articmine:
Then we make a lower soft fork to allow for the shock. They are impractical because of the shock effect. I understand that
17:07:23
articmine:
... but I do see the merit of the larger hard cap very much
17:13:30
articmine:
I GB blocks is 100 Mbps bandwidth. This is appropriate for a hard cap
17:13:42
articmine:
With a 1.5 growth per year
17:14:30
articmine:
As for the soft cap much lower 10 to 20x less
17:16:04
articmine:
So around 50 MB. It is here where the stressnet data has to come
17:17:14
articmine:
All of this is on top of my current proposal
17:17:38
articmine:
So the lower of the two always applies
18:01:50
ofrnxmr:
This is for a single peer. > <@articmine> I GB blocks is 100 Mbps bandwidth. This is appropriate for a hard cap
18:02:01
ofrnxmr:
And upload
18:06:05
ofrnxmr:
tx-relay v2 significantly reduces bandwidth usage, fluffy blocks reduce block relay requirments (you broadcast empty blocks, and peers request missing txs if there are any. Not sure if relayed blocks are also initially empty cc @boog900:monero.social who suggested that we split relayed fluffyblocks into multiple messages )
18:20:04
boog900:
@ofrnxmr: Yeah they are empty. However, when you request missing txs the peer will just send the block again but they will include the missing txs. Its that step where we need to support sending the block in multiple messages
18:22:41
boog900:
As otherwise only peers with the txs already in the pool will be able to receive the block and we will have a chain split
18:23:02
ofrnxmr:
1gb takes 80 seconds to download at 100mbps (12.5MB/s) > <@articmine> I GB blocks is 100 Mbps bandwidth. This is appropriate for a hard cap
18:23:52
DataHoarder:
consider 100mbps being shared with 8 peers
18:24:03
DataHoarder:
each sending/receiving these
18:24:28
ofrnxmr:
@boog900: Wont any peer sending the block have to have the missing txs?
18:25:05
ofrnxmr:
DataHoarder: Thats download too.. at 100mbps down, you probably have barely 10mbps up
18:25:30
DataHoarder:
let's give the benefit of the doubt and consider it's symmetric :)
18:25:34
ofrnxmr:
And its 12 out peers by default
18:25:56
boog900:
@ofrnxmr: Yes
18:26:54
boog900:
The issue is that sending the full block with all txs is over the limit so only peers with the txs in the pool can receive the block
18:27:11
boog900:
As they don't need to request the txs
18:28:39
ofrnxmr:
i see. So marathon/qubic mines a 50mb block with 100% private txs, and when peer asks for the missing txs, the block is too big to relay in one piece. Is this correct?
18:28:54
DataHoarder:
with large txpools they might end up segmented ^ (aka, different sets of txpool on different peers) increasing sync times
18:29:08
boog900:
@ofrnxmr: Yep
18:29:17
elongated:matrix.org:
https://www.speedtest.net/global-index#mobile average upload speed ~14Mbps
18:29:32
ofrnxmr:
Tx-relay v2 should keep pools in sync, unless some ppl keep small txpools
18:29:37
articmine:
100 Mbps up typically is 1Gbps down
18:29:58
boog900:
@ofrnxmr: Yeah sure but we can't rely on this for consensus
18:30:05
articmine:
This is a cable as opposed to fibre connection
18:30:17
DataHoarder:
or 1000/10 which I have seen and sometimes has issues sending ACKs for TCP
18:30:21
ofrnxmr:
@boog900: problem is ppl who keep small txpools
18:30:22
boog900:
Someone could strategically double spend to get different txs in different pools for example
18:30:32
ofrnxmr:
@ofrnxmr: I dont think monero deals with this very well at all
18:30:33
DataHoarder:
19:29:38 <br-m> <ofrnxmr> Tx-relay v2 should keep pools in sync, unless some ppl keep small txpools
18:30:33
DataHoarder:
^ not if it exceeds max txpool size
18:30:54
ofrnxmr:
DataHoarder: Exactly
18:31:16
articmine:
DataHoarder: I have seen this over cable
18:31:53
ofrnxmr:
If you exceed txpool size, monero gets drunk and thinks everything is a double spend. Monero hitting max txpool size is a problem on its own
18:32:02
boog900:
@boog900: Or you could front load the txs to specific peers just before sending the block and hope the txs don't get propagated to other nodes
18:32:03
DataHoarder:
elongated:matrix.org: unless someone runs a full node on mobile, wallets will usually just grab pruned txs which are vastly smaller, or even not the full pruned tx and just some specific info
18:32:27
ofrnxmr:
(which is why id also advocate to increase the default to like.. N GBs. Something much larger)
18:33:01
ofrnxmr:
600mb is easy to hit, especially on fcmp
18:33:28
elongated:matrix.org:
DataHoarder: would need to sync from remote node though ?
18:34:00
DataHoarder:
that's why I said "unless you are running a full node on mobile"
18:36:41
boog900:
Also when syncing we send all txs in a block
18:36:54
boog900:
Nodes that don't get the fluffy block won't be able to sync
22:39:35
lordx3nu:matrix.org:
getting caught up on the mrl logs -- would carrot delay a fcmp hard fork? It seems like the audits jeffro is proposing would lengthen things.
22:45:54
DataHoarder:
Qubic update, they may be trying to change their reward model again, targeting hashrate increase. They are currently at ATL levels so maybe they are trying to make more news https://irc.gammaspectra.live/bd8afe4df64c864a/image.png
22:46:39
sgp_:
Yay we get to bicker about PoW vs PoS again :p
22:47:02
elongated:matrix.org:
DataHoarder: When dns patch
22:47:12
DataHoarder:
> Converted Qus from Layer 1 are allocated to maintain miner profitability above direct competitors. Target uplift is roughly 25 percent over XMR or XMR+Tari baselines. Allocation is dynamic.
22:47:14
DataHoarder:
> If raw Qubic mining yield drifts below target, additional Qus from Layer 1 are injected. If yield is already above target, no additional allocation is done.
22:47:16
DataHoarder:
(given their price maintains, otherwise they are effectively inflating their own to give the sense of "higher" rewards)
22:47:29
DataHoarder:
not up to me, elongated, needs to be fixed within core consensus area and it has not easy repro case to debug
22:47:55
ofrnxmr:xmr.mx:
Need someone familiar with the reorg logic to sort it out
22:47:59
DataHoarder:
^
22:48:48
DataHoarder:
so Qubic, effectively they want to do marketing again by showing as profitable (they aren't atm) by basically burning away whoever has "invested" with them long term
22:49:18
DataHoarder:
> The new strategy can be considered as successful when the XMR mining hashrate increases by 30% within three weeks. Is this not the case, the above strategy needs to be changed or rolled back.
22:49:18
DataHoarder:
^ and ofc it's not even certain, "hope and pray"
22:49:26
elongated:matrix.org:
DataHoarder: Whoever invested or funding to attack xmr
22:50:43
DataHoarder:
0.8-1GH/s atm, but they don't run it 24/7, so real "effective" hashrate is different
23:01:00
datahoarder:
@sgp_: conflict of interest.
23:02:14
datahoarder:
Will keep monitoring them, all existing tracking methods still work and tips.txt on https://qubic-snooper.p2pool.observer/tips.txt is also alive