<boog900> A soft fork is a change that is backwards compatible with old nodes

<boog900> not a temporary change

bring back "token" hardforks every 6 months :P

<articmine> It is backwards compatible with the existing scaling and my proposal

<boog900> but why have the extra softfork just include it in the hardfork?

<articmine> To prevent attack on the existing scaling

<boog900> wat

<kayabanerve:matrix.org> But the further 'soft forks' also have to be sequentially compatible

<articmine> Regarding the identified vulnerabilites

<articmine> @kayabanerve:matrix.org: Yes

<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

<boog900> still this is so much protocol complexity

<articmine> Miner majori not consensus

<boog900> For what? why not just change the short and long term multipliers?

<boog900> @articmine: miner majority is pretty much consensus otherwise we can get chainsplits

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.

<articmine> @boog900: This does not address the smart blocker concerns

<articmine> selsta: Spam is not the issue

<ofrnxmr:xmr.mx> Neilsons law says you get a 50% bump every year

<ofrnxmr:xmr.mx> So why not do

<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

<boog900> @articmine: who are you to say?

<boog900> I literally made it and it addresses my concerns (mostly)

<articmine> It is genuine growth that is too fast t the network

<articmine> @boog900: You are not the only one

<boog900> we are not going to get 1000x growth in a year

monero is nowhere near the quality where l scaling becomes purely theoretical, as shown on stressnet

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: and we can hf to increase that if we have some breakthroughs

<boog900> we aren't going to get 100x

<321bob321> Where going visa level soon

<articmine> I will put something together

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

so before our software is optimized i prefer slower scaling

<boog900> Ok, I will also discuss my proposal with people

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: @boog900:monero.social @articmine:monero.social ^ thoughts?

<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)

<boog900> @ofrnxmr:xmr.mx: that would be quite slow scaling, I am not against it but I think a few would be

<articmine> We just put a cap that meets the above numbers and grows by 50% a year

<boog900> also I do like how my proposal keeps a lot of stuff the same, there is a big benefit in keeping changes simple

<articmine> It can meet boog900 numbers

<articmine> It is t very simple change

<ofrnxmr:xmr.mx> 16mb is 100x current volume (ringct)

<ofrnxmr:xmr.mx> And is 11gb per day

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

<boog900> @ofrnxmr:xmr.mx: I would just lower the long term growth rate even more if you wanted slower scaling

<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.

<boog900> still high, but better than gigabyte blocks in a year

can the current software support 90mb blocks?

<boog900> no

<ofrnxmr:xmr.mx> i think 90mb blocks in a year is overkill w/o a hard fork

<ofrnxmr:xmr.mx> selsta: No

yea then we have to limit it realistically before the software supports it :D

unless the discussion currently is purely theoretical limits

<ofrnxmr:xmr.mx> currently i think current scaling allows much larger than 90mb

<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

<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

<boog900> @ofrnxmr:xmr.mx: its like 240mb in a year

<boog900> using a long term growth rate of 1.2 instead of 1.4 would be ~35 mb

<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

<ofrnxmr:xmr.mx> 50% YoY is neilsons law

<ofrnxmr:xmr.mx> 32mb might be do-able, and once the weight changes are on stressnet can be tested accurately

<kayabanerve:matrix.org> I thought that was called a fallacy

<articmine> @boog900: So 100 Mb per block until the end of 2026

<boog900> no 100 MB per block as long as current median is at minimum value

<boog900> but as you can see selsta and ofrn both want lower

<boog900> like 30 MB

<boog900> which I wouldn't mind, which would put the long term max growth at 1.17

<articmine> It is 16 MB for 69 days from 1 MB ZM

<articmine> Just on my proposal

<boog900> yeah but that increases 2x every 2 months after

<articmine> To meet the 100 MB cap we have to set cap on the soft fork at 50MB

<ofrnxmr> where does the 100k blocks number come from? (why 100k? Why not 262800? Etc)

<boog900> @articmine: I feel like you have managed to ignore everything I have said today

<articmine> Not at all

<boog900> @ofrnxmr: tbf seen as it is already chosen, unless there is a good reason, I would just keep it as is

<articmine> The 100 MB is a bug that cannot be easily fit

<articmine> Fixed

<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

<boog900> when just looking at max block size*

<articmine> On just sets a global cap to meet the 100 MB limit and then scarlet it at 50% per year

<articmine> Scales

<boog900> yeah but now in the second year that is a 150 MB limit

<boog900> etc etc for following years growing exponentially

<articmine> At the end of the second year

<boog900> I really feel just changing the current short/long multipliers is the simplest solution

<articmine> It is way less than your proposal

<articmine> And it follows Neilsen's law

<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

<articmine> What my approach will do is provide the necessary flexibility within the limits

<boog900> not really, it is still higher than selsta and ofrn want and it will only meet my proposal for the first year

<articmine> @boog900: Your proposal is over 5x vs 1.5 x per year

<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

<boog900> framing it as the same is disingenuous

<articmine> @boog900: They do because they also have to deal with my current proposal

<boog900> which allows gigabyte blocks in a year

<articmine> That stays . It is the lower of the two

<articmine> Min ( P1,P2)

<boog900> and the 100mb limit increases no matter the spam, after some years its above the gigabyte

<boog900> you know its not safer

<articmine> Come on

<articmine> I am not going to argue this. It is way safer since it is the lower of the two

<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?

<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?

<boog900> for year 1 a spammer spamming for a year can reach ~100 mb with both

<boog900> for year 2 a spammer spamming for a year can reach ~100 mb with mine and 150mb with yours

<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

<kayabanerve:matrix.org> *and also, it'd have to be a bit under 100 MB so with overhead, it doesn't exceed 100 MB

<kayabanerve:matrix.org> I'd vote 1 MB, which is under 100 MB and should even be currently supported /s

<kayabanerve:matrix.org> *I'd probably look at 50, 64, or 96 MB

<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?

<boog900> on mainnet it is lower than that again

<kayabanerve:matrix.org> Eh, I don't mind having the hard limit reasonably past current perf

<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

<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?

<kayabanerve:matrix.org> And yes, that doesn't infinitely scale, it literally is finite, but monerod doesn't infinitely scale

<articmine> What t current performance in a 2, 4, 6, 8, 10, 12 months time frame

<articmine> Provide this and I can design the cap

<boog900> let me get my magic ball rq

<articmine> Arguing endlessly is pointless

<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.

<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

<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

<boog900> those limits should not change year on year

<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

<articmine> No

<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

<sgp_> I'm not even for 2x, I think that's too much still. But 2x is way better than the proposed max

<sgp_> @ofrnxmr:xmr.mx: Or 50% max. Again, closer to reason

<ofrnxmr> @sgp_: 1.5x is Neilson's law tho

<sgp_> Yeah so even 2x max per year is too high by that metric

<ofrnxmr> If were using neilsons law to justify #s, then we should be consistent. I think 32mb within a year is a safe number

<ofrnxmr> Safe, as in, we shouldnt need more than that, and its "survivable"

<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

<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.

<boog900> I would support targeting 32 MB or 2x the max short term growth instead

<ofrnxmr> Im not saying 1.5x the penalty free zone, thats much too small. But 1.5x the max (ideally 32mb) short term limit

<ofrnxmr> 32mb is 100x the current penalty zone, and like 200x the actual volume

<ofrnxmr> im also in favor of hard forking to increase these limits as soon as the software and hardware can handle them

<boog900> I think a short term limit of 32 is pretty high ngl

<boog900> I would rather be in the 16 MB range for short term

<articmine> @boog900: You will be

<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

<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?

<boog900> For a short term limit^

<boog900> Then max block size is 24mb at the end of the year if we ho with 2x

<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

<articmine> Conflict of interest

<sgp_> What's the current justification from growing M(L) from 1.7 to 2

<articmine> Is a serious issue here

<boog900> @articmine: Let's us talk

<sgp_> 1.7 to the third is roughly 4.9x-ish per year, above 1.5x (Moore's law ish) and 2x per year

<boog900> @sgp_: seraphis-migration/monero #44#issuecomment-3561821958

<sgp_> Ok so it's just due to perceived capacity shortages

<boog900> Pretty much

<boog900> Need that 1000x gigabyte blocks in a year

<sgp_> Lowering to 1.2 would be more sensible in my view. That's still more growth than the rate of Moore's law

<sgp_> Does anyone else want to allow more than 50% or 100% growth a year?

<sgp_> (ignoring the first base adjustment to compensate for FCMP)

<boog900> @sgp_: Do you have opinions on the penalty free zone or short term?

<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.

<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

<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

<sgp_> The design goal needs to be that the chosen values can't cause network harm. After that I don't really care

<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

<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

<ofrnxmr> weve never had a sustained full blocks aside from some half baked spam

<ofrnxmr> There have been minutes where the txpool grew to a mb or 2, but never sustained (aside from >1yr old spam)

<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

<articmine> naxo.com

<articmine> Please review the above carefully. Then we can talk > <@boog900> Let's us talk

<articmine> Pay close attention to the staff , partners and the FAQ particularly with regard to Monero and privacy

<articmine> By the way this is already all over reddit.com/r/btc/comments/1p6gs6y/m…ddit_purges_all_mentions_that_their

ofc that thread has fireice_uk

<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

<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

<articmine> It is not a rumour just go to the site above and do you own research

<articmine> That is what I did

<articmine> Yes I know that the people who brought this to my attention are not friends of Monero.

<articmine> I just have to go with what I read from the source with my own eyes

<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

<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

<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

<articmine> @testtank:matrix.org: I do not believe Bitcoin can be traced

<articmine> That has not prevented this BS industry from making all sorts of claims

<articmine> Claims that have been very detrimental to Monero

<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

<articmine> Especially over the long term median growth factor

<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

<articmine> Here is the standard that I use canada.ca/en/treasury-board-secreta…ent/apparent-conflict-interest.html

<articmine> I believe that we should meet if not exceed the standard that the state uses

<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

<articmine> As I mentioned before I am working on a solution that will have a realistic chance of getting consensus.

<basses:matrix.org> johndcook.com/blog/2025/11/24/monero-stealth-addresses , news.ycombinator.com/item?id=46038868

<monero.arbo:matrix.org> sgp isn't a dev? who are we talking about > <@articmine> By the way this is already all over reddit.com/r/btc/comments/1p6gs6y/m…ddit_purges_all_mentions_that_their

<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.

<monero.arbo:matrix.org> > <@sgp_> Does anyone else want to allow more than 50% or 100% growth a year?

<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

<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.

<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?

<elongated:matrix.org> Assume price doesn’t increase and someone keeps spamming for cents, it will make xmr unusable for most ppl.

<elongated:matrix.org> Noobs struggle syncing wallet with current block size.

<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

<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

<monero.arbo:matrix.org> low fees ---> high fees while blocks grow slowly to meet demand ---> low fees again

<monero.arbo:matrix.org> but the high fee period is actually important

<articmine> We are talking about sgp > <@monero.arbo:matrix.org> sgp isn't a dev? who are we talking about

<articmine> @monero.arbo:matrix.org: High fees can kill the peer to peer decentralized economy

<articmine> This is what happened in Bitcoin

<articmine> People leave and don't come back

<monero.arbo:matrix.org> the bitcoin economy is dead?

<articmine> As peer to peer cash yes

<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

<articmine> @monero.arbo:matrix.org: because XMR has been suppressed, by the BS lobbying

<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

<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

<articmine> I bought dinner in a restaurant in downtown Vancouver with Bitcoin 13 years ago. Not possible today

<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?

<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

<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

<boog900> @monero.arbo:matrix.org: oh yeah I wasn't trying to say bitcoin was good

<articmine> @monero.arbo:matrix.org: Had? No has.

<monero.arbo:matrix.org> oh I know dw

<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?

<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.

<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

<monero.arbo:matrix.org> @boog900: interesting point

<gingeropolous> yeah. I dunno how things are gonna shake out while we're still in this transition period with everything being a reference currency

<boog900> fees should be based on when you want the tx in a block, within 1 block, 10, 100 etc

<boog900> then we also need RBF

<articmine> @boog900: Try paying with USD in Canada. Same tax accounting issue

<gingeropolous> well a stupid high fee will will get your tx in the next block

<boog900> @gingeropolous: the wallet software maxes out at an algorithm that does not take into account the txpool

<gingeropolous> i thought it does take into account the txpool

<monero.arbo:matrix.org> I think the point is the max fee might not be maximum enough

<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?"

<articmine> We have fee tiers in Monero because of privacy

<boog900> its all on block medians AFAIK

<boog900> you can't overcut everyone in the pool

<gingeropolous> uhhhh i don't think so, because the median hasn't moved

<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.

<gingeropolous> and ive seen that message

<articmine> You got to choose fee levels

<articmine> This is a privacy issue

<boog900> @rucknium: yeah exactly you should be able to outbid even if everyone pays the max fee

<gingeropolous> then we need supermax

<articmine> I am actually proposing an extra fee level

<gingeropolous> max ultra fee

<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.

<boog900> @articmine: if everyone uses the same algo for levels it shouldn't be

<monero.arbo:matrix.org> @rucknium: not "everyone", just more people than can fit in a block

<ofrnxmr> It does > <@gingeropolous> i thought it does take into account the txpool

<boog900> @rucknium: yes but you should be able to outbid people so miners want to include your tx more

<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.

<boog900> @rucknium: what if growth of the short term is maxed out or you can't wait for that to happen?

<gingeropolous> so worse case scenario, we're talking 50 blocks * 2 minutes = 1 hour if everyones at max fee for first inclusion

<boog900> @gingeropolous: no, you still need to wait for txs before yours to confirm

<ofrnxmr> 50 blocks * 2 min = 1 hour? You mean 30 blocks?

<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.

<articmine> @rucknium: This is true as long as we do not hit the maximum limit of the short term median

<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

<articmine> If we do the Bitcoin like fee market will last until the long term median. Moves

<ofrnxmr> @rucknium: Technically you can have 49 empty blocks w/o losing the median

<monero.arbo:matrix.org> @rucknium: so there should be some limit to the block de-growth rate?

<gingeropolous> yeah the long tail has been something i tried to figure out once

<gingeropolous> the decay

<ofrnxmr> @gingeropolous: 1000x is the max fee priority /lvl 4

<boog900> The algorithms to decide fee rate don't, you can just look at the scaling doc > <@ofrnxmr> It does

<gingeropolous> ok, so 10,000x!

<boog900> the wallet may tell you when it expects to be included though

<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.

<gingeropolous> scaling doc? since when does our code match the docs....

<ofrnxmr> @boog900: Yeah, they only bump to lvl 2 if recent blocks are 80% full, or txpool has a backlog

<ofrnxmr> Theres a pr to set auto to lvl 3 (16x) is there a backlog over 12hrs at lvl 2

<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

<sgp_> This is why I suggested the power of two fee denomination idea lol

<articmine> @sgp_: Conflict of interest

<sgp_> Lmao how does setting a power of two fee kill Monero. Ffs

<boog900> @rucknium: There was talk yesterday of significantly reducing scaling, so it does become more relevant then.

seems for articmine anything you say in this room now is conflict of interest sgp_

<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

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

<sgp_> There should be no "max fee" imo

<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.

yes. max monero generated coins :P

<sgp_> Yup that should be the only max :)

<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

<sgp_> @gingeropolous: A competitive mining market prevents cartels keeping blocks small. Else mining is not competitive and pow is broken

<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

<sgp_> So we get that solved "for free" with the pow security assumptions

if 51% yes, gingeropolous

as they can eliminate other blocks

otherwise other miners will snatch them

<sgp_> Basically if that's a concern, then pow is already broken

up to the point that growing the block gives them less reward

<rucknium> @gingeropolous: This paper has that math for Bitcoin. Theorem 1: 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.

<articmine> One needs an insane fee if one restricts growth until one drives the user's away

<gingeropolous> noice

<sgp_> There's no way to prevent high fees

<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

<articmine> Restricting growth is necessary to attempt to keep BS alive

<gingeropolous> prevent high fees temporarily. eventually the protocol reaches a new steady state and fees go down.

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

with FCMP++ as well, ArticMine?

<sgp_> You need unlimited block capacity to fully prevent high fees. Unlimited

<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

<sgp_> Not high. Unlimited

<gingeropolous> in a spam attack

<gingeropolous> if the network reaches a steady state of 500kb blocks, then that is the new penalty free zone. So, no high fees

<gingeropolous> and the algorithm automagically actually lowers the fee as the block size grows

<gingeropolous> the base fee

<gingeropolous> to account for "big blocks equal number go up"

<gingeropolous> according to the blockchain reality

<gingeropolous> and i know this idea has been bandied about and i've heard good arguments against it... but coupling PoW and base fee.......

<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

<articmine> Bitcoin is very unusual. No increase in price will increase supply

<monero.arbo:matrix.org> @articmine: I hear you I just think the maximum allowable scaling is too aggressive

<monero.arbo:matrix.org> at some point more demand shouldn't actually equal more supply, if the network does not have the capacity

<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

<articmine> @monero.arbo:matrix.org: I hear you. This being said to reach consensus on has to eliminate conflicts of interest

<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

<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

<monero.arbo:matrix.org> it's important that conflicts are acknowledged, but we all know

<articmine> If you influence or attempt to influence the decision makers that triggers a conflict of interest

<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

<monero.arbo:matrix.org> technically it's attempting to influence, sure, but people can read arguments and draw their own conclusions

<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?

<monero.arbo:matrix.org> /genuine

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

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

<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

<monero.arbo:matrix.org> okay I hear you but I wouldn't really say sgp seems aggressive about his ideas

<rottenwheel:unredacted.org> @articmine: > aggressively

<rottenwheel:unredacted.org> what?

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

<monero.arbo:matrix.org> he's like not even really defending himself as you talk shit

<articmine> This is the harm that conflict of interest creats

<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

<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...

<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.

<quadriocellata:matrix.org> DataHoarder: agreed

<gingeropolous> i mean i guess that is 250k USD, which isn't nothing

<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

<monero.arbo:matrix.org> Also I jsut realized your name is Artic and not Arctic

<articmine> @datahoarder: He needs to recuse himself from attempting to influence the Monero code

<rottenwheel:unredacted.org> @articmine: Unbelievable.

<articmine> That is the proper way to deal with a conflict of interest

<gingeropolous> so make the argument why he shouldn't

<monero.arbo:matrix.org> god forbid a man have an idea

<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?

<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

<gingeropolous> there's no emoji for "here here" or is it "hear here"

<rottenwheel:unredacted.org> @gingeropolous: I did it for you. Tap on it.

<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)"

<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

<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

<monero.arbo:matrix.org> unless I missed what the counter to AMs proposal was, other than sgp's

<monero.arbo:matrix.org> AM mentioned they were working on something so hopefully they take the feedback from the room seriously

<articmine> I am

<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

<monero.arbo:matrix.org> @articmine: well then go work on it and stop fighting us <3 <3

<articmine> @sgp_: You proposed to cap the growth at 2x per year

<sgp_> I pay everyone else in the channel to oppose you as well, you got me!

<articmine> After Monero is supposed for an undefined amount of time

<boog900> @sgp_: I also suggested 1.4 yesterday with willingness to drop it even lower if there was consensus

<articmine> Suppressed

<sgp_> @boog900: Thanks, make sure to send me your address for payment

<boog900> selsta thought even 1.4 was too high

<sgp_> 1.4 is too high lol

<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

<boog900> it kept us under 90 mb in a year :p

<boog900> not under, around

<boog900> which is extremely high but I felt was a good compromise

<sgp_> Fwiw it is way better than 2 which isn't saying much

<boog900> as artics allows gigabyte blocks in year

<articmine> I can work with less. > <@boog900> it kept us under 90 mb in a year :p

<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.

<gingeropolous> and we can't get stressnet to get my 18 yr old CPU from falling behind

<sgp_> Ironically 3 is the most knowable of the three. 1 and 2 are just demand predictions

<articmine> I cannot agree to throttle scaling at the back end which Monero is being suppressed by the BS companies and their lobbying

<ofrnxmr> @gingeropolous: reword this plz

<gingeropolous> ideally we'd find the blocksize in stressnet that would make my scrap heap unable to stay synchronized

<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?

<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 p2pool.observer/sweeps

<ofrnxmr> @gingeropolous: a few weeks ago, it couldnt

<gingeropolous> because currently this "Intel(R) Pentium(R) CPU G6950 @ 2.80GHz, 4GB ram, 300GB SATA HDD" syncd and is staying sycnhronized

<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

<ofrnxmr> @ofrnxmr: 1.5 and flufy block,dynamic sync size and a few other fixes changed thatr

<gingeropolous> @ofrnxmr: ok, then we need to find the new limit

<articmine> @gingeropolous: What blocksize?

<ofrnxmr> We still have txrelay ,serialization, packet size

<ofrnxmr> @articmine: 10+

<articmine> 10+ MB

<ofrnxmr> Ya

<monero.arbo:matrix.org> yes

<ofrnxmr> Less than15

<gingeropolous> and that size is currently limited to how much you can spam the network due to.....

<ofrnxmr> We can push to 30or 40 if i can get some help

<gingeropolous> you just not have enough outputs?

<ofrnxmr> @gingeropolous: Coinbase lock times absotlrbing fees

<ofrnxmr> And it uses a lot of resources (>100gb ram)

<ofrnxmr> (wallets)

<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

<gingeropolous> well luckily u have a 1TB

<ofrnxmr> Ruckniums script is public

<monero.arbo:matrix.org> yeah I jsut mean share th elink

<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

<ofrnxmr> @monero.arbo:matrix.org: I dont have it 😅

<datahoarder> if you make low fee txs I could burn monero in blocks with a custom txpool selector > <@ofrnxmr> Coinbase lock times absotlrbing fees

<rucknium> @monero.arbo:matrix.org: github.com/Rucknium/xmrspammer

<articmine> What are the current limits for

<articmine> Tx relay

<articmine> Serialization [... more lines follow, see mrelay.p2pool.observer/e/geXUzs0KQ1BDLWNz ]

<datahoarder> As mentioned, but maybe for next stressnet, not current

<gingeropolous> yeah

<gingeropolous> is the plan to roll it back and start fresh?

<ofrnxmr> @articmine: 1. Brb

<ofrnxmr> 2. 30mb

<ofrnxmr> 3. 100mb

<ofrnxmr> @gingeropolous: Likely

<datahoarder> @gingeropolous: testnet has continued working, so it'd be another hardfork there so yep a rollback

<ofrnxmr> Current is gettingbig

<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

<articmine> Brb?

<gingeropolous> prolly be right back, getting the data

<articmine> Clarify?

<sgp_> Does anyone else oppose these tweaks or have feedback on them?

<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.

<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.

<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 mrelay.p2pool.observer/e/1KDgzs0KYS1mSXRr ]

<articmine> Opposed

<ofrnxmr> @gingeropolous: Im 1 handed atm, ya be right bk

<gingeropolous> off the cuff they feel too restrictive.

<sgp_> Yeah but what part is specifically and why

<articmine> @gingeropolous: Way to restrictive

<sgp_> Do we need more than 70% growth per year

<articmine> @sgp_: Yes because of BS suppression

<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

<rucknium> Does the growth function have to be exponential? Get creative.

<gingeropolous> if i could just figure out to host this wasm thinger on github pages

<articmine> @rucknium: It can be capped to Nielsen's Law

<sgp_> 70% > 50%

<articmine> @sgp_: After accepting for BS suppression surge

<sgp_> You should be advocating for an initial increase to account for the "suppression" not a massive growth rate from there

<articmine> It comes down to t initial conditions

<sgp_> I don't agree with your logic but that would be a better way of trying to do your logic

<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

<articmine> @sgp_: We don't know how long the suppression will last

<sgp_> You're asking for a blank check to grow massively without restriction then, which is infeasible

<articmine> @gingeropolous: It has been going on at least since 2019

<articmine> @sgp_: No I am not

<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?

<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

<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

<articmine> @sgp_: Over a long time decades it should be 50% based upon Neilsen's Law

<sgp_> Jesus I want to scream at my computer. Your proposal allows way way more than 50% and 70%

<articmine> @datahoarder: We used a sanity median or cap at 50 %

<articmine> For the long term

<gingeropolous> c'mon 5 million blocks simulation. finish already...

<boog900> @sgp_: but just look at it in this one specific way!

<rucknium> @gingeropolous:monero.social: Needs to be converted into a differential equation so you can compute the end state instantly :)

<articmine> Are we in agreement on a long term 50% cap?

<boog900> no lol

<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

<ofrnxmr> For well connected nodes, a large txpool can cause them to go offline due to running out of memory

<sgp_> No but I prefer it to 700% lmao

<boog900> @articmine:monero.social: that 50% cap will move without any increase in txs right?

<gingeropolous> so if you want to self host or whatevs this newer version has the wasm magic that makes it really fast: github.com/Fountain5405/adaptiveblocksizesim

<sgp_> I would feel we are at least making progress if you lowered the max long term growth rate from 2 to 1.2

<boog900> at least that is what you proposed yesterday

<articmine> Correct

<articmine> But it is also subject to my current proposal.

<ofrnxmr> @sgp_: is this 1.2 for every 100k median?

<articmine> So the lower of the two

<sgp_> Oh this is yet another proposed cap not adjusting the long term median?

<sgp_> Why not just adjust the long term median

<boog900> @sgp_: because this way in 7 years we get gigabyte blocks again within a year with no spam before

<articmine> @sgp_: It does not address BS suppression

<sgp_> Ugh

<boog900> trying to sneak in dangerous scaling

<articmine> @boog900: No

<sgp_> I can't argue with something for which there's no quantifiable evidence. It just leads to irrational decisions detached from reality

<sgp_> Even if you think it exists, the scale is incalculable

<gingeropolous> i think we could reasonably use any existing mature network as some sort of reference. bitcoin, ethereum, etc

<boog900> @articmine: its exactly what you are trying to do by arguing yours is more restrictive when you know its not

<articmine> @sgp_: Are you going to deny CEX delisting s and the role of BC S companies in this

<sgp_> Lol. Monero would totally have as many transactions today as Ethereum plus all it's L2s if it wasn't suppressed. Totally.

<articmine> Back to conflict of interest

<sgp_> @sgp_: My point is that this is just witchcraft dressed up as "math"

<gingeropolous> well perhaps not the same, but its some sort of real world number

<articmine> This is why conflict of interest makes it impossible to reach consensus

<gingeropolous> what is the tx rate of ethereum these dayus

<gingeropolous> yes i agree its not apples to apples but at least its a fruit

<gingeropolous> as opposed to these ghosts we're chasing

<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

<articmine> It has also been flat. POS validators are obligated entities under AL

<articmine> AML

<sgp_> Yes the specific law "AML"

<sgp_> This is why all eth validators in the world have been arrested or are banks

<articmine> @gingeropolous: bitinfocharts.com/comparison/ethereum-transactions.html#log&alltime

<articmine> @sgp_: They are pressured behind the scenes

<sgp_> Blockchain surveillance companies won't stop until all blockchains are completely killed through suppression. Then they will have won

<articmine> We both know. that BS does not scale. Can we stop this pointless argument

<elongated:matrix.org> @sgp_: Thanks for confirming

<boog900> @articmine: honestly I don't even know if I agree here, yes more txs are better but VISA isn't exactly private.

<articmine> @boog900: It actually is

<articmine> Because of it's size

<sgp_> Artic why don't you work for visa ha

<boog900> @articmine: fair at least you are consistent

<boog900> although I obviously disagree that VISA is private

<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

<sgp_> I can take one for the team and start supporting artic's original proposal if that'll help :)

<boog900> lol

<ofrnxmr> Is the "1.2x" or "2x" etc, in reference to the max growth withing the LTM?

<sgp_> When I was using those numbers, yes

<boog900> @ofrnxmr: its a multiplier on the short term growth

<boog900> so if you allow maximum of 16 mb blocks in the short term then the next period is 1.2 or 2x that

<boog900> with the current formula anyway

<articmine> It is currently 1.7 x

<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

<sgp_> Which I argued when you picked 1.7 before was too high

<ofrnxmr> makes sense. My vote is 16 or 32mb max block size within STM, and neilsons law for LTM

<articmine> @sgp_: You picked 1.7 I had proposed going t 2

<articmine> At least let us get the facts right

<gingeropolous> oh shit, 500k finished. 464290ms

<articmine> @gingeropolous: What exactly took this time?

<ofrnxmr> He has a simulator

<articmine> On what hardware

<ofrnxmr> Not monerod sim, just scaling sim

<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

<sgp_> I guess I did say at the time that 1.7 was an "okay" compromise

<sgp_> monero-project/research-lab #70#issuecomment-785193630

<ofrnxmr> A website

<gingeropolous> lol and the mempool got to 43878.94 GB

<sgp_> My comment did caveat that if that growth target was actually hit, we'd need a hard fork to lower it

<gingeropolous> and it took 500k blocks

<articmine> @gingeropolous: Hardware?

<gingeropolous> its just a simulator. this isn't actual monero

<gingeropolous> github.com/Fountain5405/adaptiveblocksizesim

<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

<gingeropolous> because OPTIMIZATION

<gingeropolous> but im out. peace y'all. till next time

<ofrnxmr> Whats the website for the old one

<articmine> @sgp_: You don't

<articmine> That was the whole point of issue 70

<boog900> @ofrnxmr: gingeropolous.github.io/blocksizejavasim/lastpurejavascript.html

<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.

<articmine> It goes down at the same rate as it goes up for the long term median

<boog900> @articmine:monero.social: current scaling allows 425mb blocks at max right?

<boog900> in a year*

<articmine> After how many blocks

<boog900> @articmine: years worth

<articmine> Correct.

<boog900> even worse than the 244 mb number I got before

<articmine> I believe the simulation estimates the cost to get there

<articmine> It ain't cheap

<boog900> why do we need 1400x lol

<boog900> at all

<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.

<articmine> We don't need to max this out for ever

<sgp_> We would need a hard fork to remove it later then should a surge happen

<boog900> Yeah but like that was more a question of what was going on when the decision for that much growth was made

<articmine> This is why a 1.5 x per year cap on top is appropriate

<articmine> The only real argument I see is the initial conditions

<articmine> Then we don't need a HF

<sgp_> I do see "catching up" to Bitcoin's current use to be within reason. Idk if that's the same as 100x tho

<ofrnxmr> 100x from current is 30mb

<ofrnxmr> (for fcmp)

<articmine> @sgp_: Bitcoin gas been suppressed. We all know that

<sgp_> Yeah but despite that it works

<articmine> So that is not the standard

<sgp_> And if permitted to continue to grow at 50%, it would still work better

<articmine> @sgp_: It does not

<articmine> As peer to peer cash

<articmine> Again back to conflict of interest

<articmine> If Bitcoin had allowed 50% growth from the start starting at 1 MB blocks it will exceed 1 GB blocks next year

<articmine> So yes then it would have worked

<sgp_> So allow Monero to catch up and then 50% max. At least I see that as roughly within reason versus 100x+

<articmine> @sgp_: To catch up to where Bitcoin should have been yes

<sgp_> Eh then you lose me since the actual sizes would be impractical

<articmine> Then we make a lower soft fork to allow for the shock. They are impractical because of the shock effect. I understand that

<articmine> ... but I do see the merit of the larger hard cap very much

<articmine> I GB blocks is 100 Mbps bandwidth. This is appropriate for a hard cap

<articmine> With a 1.5 growth per year

<articmine> As for the soft cap much lower 10 to 20x less

<articmine> So around 50 MB. It is here where the stressnet data has to come

<articmine> All of this is on top of my current proposal

<articmine> So the lower of the two always applies

<ofrnxmr> This is for a single peer. > <@articmine> I GB blocks is 100 Mbps bandwidth. This is appropriate for a hard cap

<ofrnxmr> And upload

<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 )

<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

<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

<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

consider 100mbps being shared with 8 peers

each sending/receiving these

<ofrnxmr> @boog900: Wont any peer sending the block have to have the missing txs?

<ofrnxmr> DataHoarder: Thats download too.. at 100mbps down, you probably have barely 10mbps up

let's give the benefit of the doubt and consider it's symmetric :)

<ofrnxmr> And its 12 out peers by default

<boog900> @ofrnxmr: Yes

<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

<boog900> As they don't need to request the txs

<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?

with large txpools they might end up segmented ^ (aka, different sets of txpool on different peers) increasing sync times

<boog900> @ofrnxmr: Yep

<elongated:matrix.org> speedtest.net/global-index#mobile average upload speed ~14Mbps

<ofrnxmr> Tx-relay v2 should keep pools in sync, unless some ppl keep small txpools

<articmine> 100 Mbps up typically is 1Gbps down

<boog900> @ofrnxmr: Yeah sure but we can't rely on this for consensus

<articmine> This is a cable as opposed to fibre connection

or 1000/10 which I have seen and sometimes has issues sending ACKs for TCP

<ofrnxmr> @boog900: problem is ppl who keep small txpools

<boog900> Someone could strategically double spend to get different txs in different pools for example

<ofrnxmr> @ofrnxmr: I dont think monero deals with this very well at all

19:29:38 <br-m> <ofrnxmr> Tx-relay v2 should keep pools in sync, unless some ppl keep small txpools

^ not if it exceeds max txpool size

<ofrnxmr> DataHoarder: Exactly

<articmine> DataHoarder: I have seen this over cable

<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

<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

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

<ofrnxmr> (which is why id also advocate to increase the default to like.. N GBs. Something much larger)

<ofrnxmr> 600mb is easy to hit, especially on fcmp

<elongated:matrix.org> DataHoarder: would need to sync from remote node though ?

that's why I said "unless you are running a full node on mobile"

<boog900> Also when syncing we send all txs in a block

<boog900> Nodes that don't get the fluffy block won't be able to sync

<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.

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 irc.gammaspectra.live/bd8afe4df64c864a/image.png

<sgp_> Yay we get to bicker about PoW vs PoS again :p

<elongated:matrix.org> DataHoarder: When dns patch

> 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.

> 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.

(given their price maintains, otherwise they are effectively inflating their own to give the sense of "higher" rewards)

not up to me, elongated, needs to be fixed within core consensus area and it has not easy repro case to debug

<ofrnxmr:xmr.mx> Need someone familiar with the reorg logic to sort it out

^

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

> 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.

^ and ofc it's not even certain, "hope and pray"

<elongated:matrix.org> DataHoarder: Whoever invested or funding to attack xmr

0.8-1GH/s atm, but they don't run it 24/7, so real "effective" hashrate is different

<datahoarder> @sgp_: conflict of interest.

<datahoarder> Will keep monitoring them, all existing tracking methods still work and tips.txt on qubic-snooper.p2pool.observer/tips.txt is also alive