given hash_to_ec was renamed to biased_hash_to_ec in fcmp monero fork, should hash_to_p3 also get renamed? the function is equivalent except input arguments

<spackle> If the Monero network cannot handle the volume the scaling design allows, the formulas are only a fantasy. Small blocks and high fees make a network unusable; so does a malfunctioning daemon.

<spackle> All I would ask if that some consideration be made for demonstrated daemon performance. I might suggest another scaling metric, let's call it 'runway.' This is how long the network can operate under maximum scaling conditions before it reaches a known limitation which requires intervention. Right now on mainnet the runway is s [... too long, see mrelay.p2pool.observer/e/nZf46cMKbEF3T0U2 ]

<ofrnxmr> what makes you say half a day?

<ofrnxmr> If prepared, i think a 600mb txpool is bad enough

<ofrnxmr> So more like, however long it takes to spam that many txs

<ofrnxmr> But thats not necessarily a scaling problem, just poorly designed.

<ofrnxmr> are you referring to block growth over 12hrs?

<spackle> I gave that estimate in the interest of making my point while also being generous.

<ofrnxmr> but what is the estimate referring to, block growth?

<spackle> I agree there is more than one issue which arises on that timeframe. So long as everyone understands that, it frames the design discussion correctly.

<ofrnxmr> The good thing is that a lot of these issues are being fixed in the immediate term (before fcmp hard fork or scaling changes)

<spackle> I stated half a day as that is a conservative rough estimate for how long it might take to hit the long term median limit of 30 MB.

<spackle> If the daemon is unable to handle volume up to this limit, the network fails within hours. If the daemon can handle volume up to this limit, the network is hardened against all possible circumstances for over two months.

<ofrnxmr> I think we'll be able to push stressnet to 30+mb blocks, but id like to wait for some of the efficiency fixed to be in first. 1000x fees is 0.03xmr for a 1:2 tx on mainnet today. Id probably argue that scaling could be slowed by an order of magnitude

<ofrnxmr> If txpool is fixed (if we can handle large txpools), then we could retain txs for longer than 3 days and increase the max txpool size

<ofrnxmr> Which would allow scaling to be slowed down a bit w/o dropping txs

<articmine> Technically to max out the proposed cap on the short term median one needs 32 MB, assuming a 1 MB penalty free zone

<articmine> This provides over 2 months

<articmine> 50000 blocks to be exact

<321bob321> signal.org/blog/spqr

<321bob321> Signal Protocol and Post-Quantum Ratchets

<spackle> @articmine: If this is the network stability target it should be an acknowledged performance requirement by developers (jberman and jeffro specifically).

<spackle> In my opinion the goal should be to agree upon a robust design with the 50000 block runway, and move forward as soon as possible.

<spackle> A 50000 block runway would be a fortress; something to be stood upon while saying with confidence that other proposals are unnecessary distractions. If we cannot stand on that foundation, then other proposals become far more enticing.

<articmine> The FCMP++ hard fork effectively quadruples the size of transactions before even considering verification time.

<articmine> My take is that if we cannot stand on this fortress we need to delay the hard fork until we can.

<articmine> It is the prudent course of action.

<boog900> the scaling code is in now though, we are vulnerable now.

<boog900> AFAIK no changes were made to it on the stressnet fork

<articmine> The stressnet is currently working on the current scaling with a 50x long-term median and a maximum block size of 100x the penalty free zone. This gives a 30 MB target for 300000 minimum penalty free zone

At least qubic can only put max 20 transactions per block of theirs due to their choices :)

They will push median down!

<articmine> @boog900: Which is why the existing vulnerability needs to be addressed before we increase the transaction size by a factor of 4 for starters

<boog900> we can reduce the max block growth for the next HF

<articmine> We already are from 50x to 16x on the short term median

<boog900> yeah I know, so no need to delay the HF right?

<articmine> It is the prudent way to go

<boog900> if we make the block growth slower for the next HF that could actually help our situation

<boog900> so delaying it would be leaving us with the faster block growth for longer

<articmine> Not really, because the HF itself could spur a major growth in adoption. This could easily be further compounded by a legal defeat of blockchain surveillance in the US courts

Delaying it just makes an attack take longer

Unless there's a plan on how to act or a limit it'll just take more time

<boog900> and tomorrow qubic could decide they want to fill all their blocks to the max

^

<boog900> they have already demonstrated they can get more than 50% of blocks

<spackle> Having the 50000 block runway is plenty prudent. No need for a delay so long as the network can meet that minimum robustness requirement.

They already pad their blocks with garbage txs

That cost them nothing as it's their own

<articmine> No it provides time to fix the underlying code issues that have been identified in stressnet

I mean if next hardfork the growth is slowed

<articmine> @spackle: I am suggesting a delay until we get the 50000 block runway

Instead of capped or logarithmic

<boog900> the real solution would be to put out a soft fork limiting block growth tomorrow

<boog900> but that would be controversial

Instead of exponential

<boog900> although I do think it is justified

<articmine> No the real solution is to fix the underlying code issues

<spackle> Dramatic improvements are already in place. The 50000 block runway is absolutely possible without any delay. Worst case is that it requires some compromise on the scaling parameters.

more controversial dns checkpoints limiting it lol

<boog900> if it was that easy it would have been done already, delaying the HF wont make it happen faster IMO

<boog900> and could make our situation worse if we can limit block growth in the next HF

This goes back to last MRL, got someone with time to refactor and cleanup technical debt, implement, then have also someone else to review?

<boog900> take this PR as an example of the amount of work and timeframe: monero-project/monero #9135

Besides a plan or growth method

<articmine> @boog900: I am not convinced . This only came to light because of the threat of an increase in blocksize

<boog900> @boog900: that PR was also a direct vuln fix btw not just an improvement

The solution is easy. Fork monero into AINero and only allow vibe code

<articmine> Which makes point

And reviewed by ai

<articmine> I was there for the 2017 HF where the penalty free zone went from 40000 bytes to 60000 bytes while the transaction size was increased 30x.

<articmine> To put it mildly the result was a fiasco

<articmine> It was what led me to get heavily involved with Monero scaling

<articmine> A scaling HF has to be rushed through which actually provided cover for the HF fix of a totally very serious vulnerability that affected not only Monero but all the other Cryptonote coins

<articmine> This vulnerability had nothing to do with scaling

<boog900> If we can limit block growth to ~16 MB for 2 months at the next HF I see no reason to delay it

<boog900> it might buy us a bit more time to fix issues but I don't think enough to justify putting it off when it itself makes the situation better by reducing block growth

<articmine> It is very heavily priced above 16 MB in my proposal but not a hard cap

<articmine> The hard cap is at 32 MB

<articmine> For 50000 blocks

<boog900> :(

<articmine> Think a stiff spring as opposed to a brick wall at 16MB

<articmine> If a train hits a stiff spring is actually safer

<boog900> miners don't have cost

<spackle> If 16 MB would be safe to deploy without delay, why is reducing the hard cap to 16 MB unreasonable?

<articmine> Sure they do if they loose up to the entire block reward

<articmine> @spackle: It destroy surge for holiday shopping for example

<boog900> @articmine: sure but that is not enough IMO

<spackle> No delay, the deployment is safe, and the scaling is enabled in time for the holidays.

<boog900> @articmine: when has that ever been shown in monero

<spackle> I was about to say the same thing, it doesn't seem to have an empirical backing as a standard.

<articmine> Actually it has

<boog900> again building our systems to the numbers from VISA is not the way to do things IMO

<spackle> At a growth of multiple the existing transaction rate?

<articmine> This is based upon the surge factor for VISA

<spackle> Indeed, but not Monero. Monero has not shown that behavior.

<articmine> They actually tested at 20x

<ofrnxmr:xmr.mx> I think holiday shopping surges can be accomodated by larger txpools > <@articmine> It destroy surge for holiday shopping for example

<articmine> @spackle: Because many transactions are investment / speculation

<ofrnxmr:xmr.mx> imo, atm, i think the txpool is one of the shittiest pieces of monero atm

<articmine> Setting the standard at 32 MB

<spackle> I do not understand the insistence on designing a system around behavior it does not exhibit, but I'll excuse myself from the conversation as I see it being beside the point.

<spackle> I return to my earlier thought, if 16 MB is safe at deployment then set it to 16 at deployment and have it increase to 32 after a delay to allow for additional development.

<articmine> is way more robust

<sgp_> @ofrnxmr:xmr.mx I think everyone is for improving the txpool handling to allow for a much bigger queue

<spackle> No delay, safe deployment, and future holiday shoppers can delight in their surge capacity.

<boog900> @spackle: just set at 16 forever

<sgp_> Am I wrong, is anyone for a purposely sucky txpool? Lol

<boog900> it still allows for growth beyond 16 after 2 months

<spackle> @boog900: I would be fine with that, but I am hoping that today's theme is compromise.

<articmine> @sgp_: If course not .

<ofrnxmr:xmr.mx> @sgp_: i dont know, but its been bad forever and it gets ignored or bandaided

what is the historical holiday tx surge for monero?

<articmine> This is not a replacement for throtelling adoption

<boog900> we don't need to follow VISAs numbers, we are a completely different system, there are no guarantees we are used the same way

<articmine> I have seen 2-3x

<boog900> VISA has no 10 block lock

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: Jberman & 0x working on it, but there are probably h1 quality issues with it

<ofrnxmr:xmr.mx> @boog900: Visa had a 48hr block lock :P

<sgp_> A large txpool is probably a failure case in your mind ArticMine, is that true? It means queued transactions waiting for a confirmation, potentially for a while. Would you argue a large txpool is an indicator that the block size isn't big enough?

<boog900> @ofrnxmr:xmr.mx: exactly ... different :D

<ofrnxmr:xmr.mx> @boog900: So they have a 48hr backlog to get 1 conf

<articmine> Visa has 2-4 day settlement. time vs a 20 min 10 block in Monero

<ofrnxmr:xmr.mx> @sgp_: I argue that a txpool that grows tk the point of dropping txs is an issue

<boog900> @ofrnxmr:xmr.mx: but that doesn't lock the "change output"

<articmine> We beat VISA hands down there

<ofrnxmr:xmr.mx> @boog900: Its all IOU's

<boog900> why don't we have a 2000 surge factor then?

<boog900> we are not the same system

<articmine> @boog900: There is no point

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: btc has a 300mb(?) Tx pool by default, that expires (? Weeks? Never?). Monero has a 72hr expiry, and a txpool that is 2x the size while txs are 5x the size. (soon to be 20x)

<articmine> @ofrnxmr:xmr.mx: The tx pool size needs to increase

<sgp_> Ofrn can we simply assume unlimited time in unlimited txpool for a bit pls? At least for this scaling discussion

<ofrnxmr:xmr.mx> Monero cant, atm, expand the txpool size because it breaks things

<articmine> @sgp_: This creates a vulnerability

<articmine> Which is exploited in Bitcoin

<ofrnxmr:xmr.mx> I would hope that after fixes that the pool size can be expanded to sizes large enough to prevent dropping of txs while blocks are catching up

<boog900> @articmine:monero.social: why do you think we should conform to VISAs numbers if they have never been shown in Monero?

<sgp_> There's no way to 100% guarantee no dropping of txs that I can see

<articmine> @boog900: It is the ratio of the average tx rate to the peak

<sgp_> You could set the txpool limit to 100 TB but it could still fill up and need to drop txs

<boog900> @articmine: exactly for, their txs

<articmine> If Monero is used as peer to peer cash that ratio should remain the same

<articmine> It is the same use case

<sgp_> Bitcoin allows each node to configure a max txpool size fwiw. Nodes can increase it from the default to drop txs less often

<spackle> Things can be used differently in fulfillment of the same use, all evidence points to this being the case for Monero vs VISA.

<boog900> its really not and it has been demonstrated in the past this does not hold

<boog900> monero only does 2 to 3x

<articmine> Because there is investment and speculation in Monero on chain

<boog900> so what 10x is still more than enough?

<articmine> People do not use VISA to buy ViSA stock

<boog900> exactly we are different.

<articmine> But they do use the Monero network to invest inMonero

<boog900> why kill ourselves to conform?

<spackle> Indeed, it is precisely why a different approach is justified.

<boog900> when we haven't got close to these numbers

<boog900> and do we track VISA forever

<ofrnxmr:xmr.mx> @sgp_: Math

<boog900> what if VISA reports 40x due to change in consumer habits?

<articmine> Can't we just fix the problem rather than argu over how to hide it

<articmine> argue

<boog900> there is always a limit

<boog900> we can't have 1 TB blocks

<boog900> I think 32 MB is too much for the short term

<articmine> @boog900: Not yet

<boog900> 16 is much safer

<articmine> What is safer is to fix the underlying problem

<spackle> If 16 is sufficient for deployment, then set it to 16 at deployment. Delaying the FCMP hard fork for the sake of excessive surge design seems like a very bad idea to me.

<spackle> One might describe the underlying problem as a cap that is set too generously, and indeed that can be fixed if needed.

<articmine> @spackle: You are actually building reseliance

<articmine> Arguing against fixing bugs I will not support

<spackle> Resilience is being built regardless. The issue at hand, as I see it, is that the resilience needs to be at an acceptable level at deployment.

<spackle> Nobody is arguing against fixing bugs.

<sgp_> I'm not arguing against fixing bugs, I'm arguing against a feature that exposes the network to a likely very significant security risk. Even you agree it's a risk because if it wasn't, we'd allow unlimited txs today (if there's no risk, why not!?)

<articmine> Please

<boog900> @articmine:monero.social: where can I find data on VISAs transaction numbers?

<articmine> Look at their financial reports. This. gives their average tx rate. Then they put out press releases where they brag about their max capacity.

<articmine> They do hide their max capacity

<articmine> Most of the time

<boog900> so we are basing the security of our network off of VISAs marketing team?

<boog900> and not our own numbers?

<boog900> I just don't know why we need VISAs reported surge factor

<ofrnxmr:xmr.mx> I think a surge to capped 16mb blocks during short term median is enough

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

<articmine> @ofrnxmr:xmr.mx: Which is what I am proposing when pricing is factor in

<boog900> You can go above 16 with what you are proposing so it is not a cap

<articmine> People just want to crash into a brick wall rather than soften the blow with a spring

<boog900> Soften at 8 or 10 or 12

<articmine> I am not agreeing to further restrictions on Monero adoption

<articmine> People are just not satisfied

<spackle> I would be unsatisfied with a scaling delay on the FCMP hard fork.

<articmine> ... there is just too much fud on this coming from Bitcoin

<ofrnxmr:xmr.mx> The hard cap is at 32mb? Im just saying halve that for the first fcmp hard fork

<spackle> If a surge factor of 8 in the short term is what is needed for safe deployment, then I would readily support that as well.

<articmine> @ofrnxmr:xmr.mx: I don't see why

<ofrnxmr:xmr.mx> 32mb in under 100k blocks isnt sustainable imo

<articmine> It will not satisfy the radicals anyway . Just take a look at the history of Bitcoin

<spackle> The scaling growth is exponential, whether 8 or 16. They are not ALL that different in the grand scheme of things.

<spackle> This is not some dramatic change of course, it is bringing the scaling design into agreement with the state of daemon performance.

<articmine> @spackle: There is a lot of politics and entrenched financial interests here

<articmine> That are feeding fud

<articmine> I have to look no further than this 10% proposal to see what is ready behind this

<sgp_> you calling it the 10% proposal shows you haven't even looked at it lol. I already provided a 50% growth example

<sgp_> Anything with perpetual 6x scaling per year is not rational. Period. I'm really sorry to say this so bluntly but it just makes no logical sense at all, and the community needs to know how dangerous it is. Call it "FUD" all you want

<articmine> I have seen it. That is the ZCash spam attack in Monero example

<boog900> Monero would be unusable in under a day if someone maxed out block size on mainnet

<boog900> @articmine:monero.social: why do we need to follow VISAs numbers

<boog900> That they self report

<articmine> A fixed rate of growth regardless of demand is totally not rational

<sgp_> ....it's a maximum allowed growth, akin to your proposal in that regard....

<sgp_> (sorry I think I misread, ignore that ^)

<articmine> @sgp_: You are not pricing growth

<articmine> There are no medians in your proposal

<sgp_> transactions do not equal organic demand, they could be spam. Allowing spam to create more spam more quickly is a potential vulnerability in the design

<articmine> @sgp_: How do you propose to tell them apart in Monero

<articmine> Come on

<articmine> Without pricing growth there is no spam control

<sgp_> I don't tell them apart. The proposal says in simple terms "assuming we can't tell them apart, we restrict like so to protect ourself in case it's spam"

<sgp_> the spam control is the growing max block size

<articmine> This is the problem with all the Bitcoin like coins

<articmine> @sgp_: No it is not

<sgp_> the caps limit the potential network harms of spam

<articmine> This fails with in the clear coins

<boog900> Its irrational to believe we need to base our system off of a completely different one when it has never been shown in our system and it pushes our system right to its limits

<articmine> Which have the spam to prove it

<sgp_> I don't follow, but if you're saying spam exists on Bitcoin, I agree. It exists everywhere and must be accounted for

<articmine> It is way worse than vin Monero

<articmine> BCH ZCash Doge etc

<sgp_> I don't know how we can say Monero spam isn't bad if we don't know which transactions are spam

<ofrnxmr:xmr.mx> I think it would make sense to even add a fifth 10000x multiplier to break through the 16mb

<ofrnxmr:xmr.mx> Make the spring cost so much that it cant be sustained as an attack. To compare to visa, visa charges 1.5-4% to use it

<sgp_> 10000x is probably safe to use as a deterrent in practice if 1x is costly enough today, but we don't now if 1x (or even 10000x) will be costly in practice in the future

<ofrnxmr:xmr.mx> Imo each tier should max out how far it can scale within the short term median

<articmine> Just take a look at the average blocksize on Bitinfocharts for say XMR BCH BSV DOGE Zcsah even early BTC

<sgp_> Can you organize your thoughts into your own proposal ofrn? I think it would help me keep track of the interweaving ideas and understand it better

<articmine> ...and even early BTC

<articmine> We have a system that works and some people are hell bent on destroy it

<boog900> @ofrnxmr:xmr.mx: Miners still don't pay the cost, unless we add fee burning and what's the point just to reach VISAs reported numbers

<sgp_> this is because the minimum fee is essentially 0 right? If there's free block space, spam will use it, that phenomenon?

<ofrnxmr:xmr.mx> @articmine: i delete before i post, then post a few words. Lol. I'm not able to think of a best practoce, but i think what i just said makes sense

<ofrnxmr:xmr.mx> @boog900: Yeah, miners dont even have to run nodes

<articmine> @boog900: We have fee burning . It is called the pension

<sgp_> in my proposal I make miners' use of the spring have the real cost in the form of a decreasing inflation reward

<articmine> Penalty

<sgp_> the penalty is definitely useful for that purpose

<spackle> I feel a dangerous level of scope creep lurking here. All I can say is that a scaling delay to FCMP would be a significant loss for Monero and I believe that idea should be resisted fiercely. It seems to me that only minimal changes may be needed to ensure we have a safe, scalable, functioning system that is deployed without hindrance.

<boog900> Why do you answer that bit and not why we need to follow VISAs reported numbers

<articmine> @spackle: The scope creep is the fear of peer to peer cash

<boog900> @articmine: Its not enough IMO

<articmine> Nothing is enough

<boog900> We have already seen a malicious actor mine at a significant loss

<articmine> For the radical small blockers

<sgp_> as a reminder, to get to Visa's transaction throughput 10 years from now, Monero would need to start with a block size of 193 MB today and grow 50% per year for 10 years to get there (300 billion transactions per year)

<articmine> Anyway this is not going anywhere

<boog900> I am literally saying 16 is enough

<spackle> I would say that whatever developers (jberman and jeffro) find to be a safe compromise position for deployment is enough.

<ofrnxmr:xmr.mx> rip boog900, you don't make the cut

<boog900> I'll take myself back to cuprate, needing to follow monerod's every (miss-)step

<spackle> Perhaps poorly phrased, but I only mean that daemon performance should inform the short term scaling.

<articmine> @sgp_: Why don't you start with 1MB in October 2008 and see what you get today at 50% per year

<articmine> When the Bitcoin whitepaper was released

<sgp_> give me a sec

<ofrnxmr:xmr.mx> Doubling every 2yrs, right?

<sgp_> 985 MB BTC blocks at a 50% growth rate per year. 5.1 MB at 10% per year. 44.4 MB at 25% per year

<articmine> Correct

<sgp_> 50%/year is more than doubling every 2

<spackle> 2.25x but good enough for napkin math

<articmine> Yes 1 GB at the end of this year I

<articmine> ... while the Bitcoin blocksize debate trust rages on

<sgp_> I'm not defending Bitcoin, but I think 44 MB would probably be enough for them as well :)

<ofrnxmr:xmr.mx> Divide by 5

<articmine> By the way in 1979 I also got an error message when I tried to run a program that required 2 MB of RAM on the University of BC mainframe computer

<articmine> It was over the computer's maximum memory

<articmine> Technology changes but human nature does not

<spackle> I do not understand what is so incredibly magical about the surge factor of 16.

<spackle> Surely some of that magic rubs off on 15? And a little makes its way to 12?

<articmine> @spackle: This is not about a number. It is about.fear

<articmine> @spackle: The fight will still happen at 12

<spackle> Perhaps, so what? It is still exponential growth, with no change to the time base.

<articmine> Going from 50 to 16 did not help

<spackle> The issue at hand is the gap between daemon performance and scaling design.

<spackle> That change did not help, because it was not informed by that gap.

<spackle> or rather, it did help but it did not address the issue.

<articmine> @spackle: This is a short term issue that can be fixed

<boog900> @articmine: its not.

<articmine> The real issue is very different

<boog900> it will take a significant amount of time to get monerod efficient

<boog900> and we are very vulnerable num

<sgp_> I personally don't like surge factors since I see surge = spam attack in my mind. I'm not specifically against 16+

<articmine> @boog900: Well the sooner we start the process the better

<boog900> why do we need 16?

<articmine> Instead of arguing and trying to avoid it

<boog900> you still haven't answered

<boog900> why not 50? 200? 8?

<articmine> Here is my answer: To for CE a fix of a serious vulnerability

<articmine> Force a fix

<boog900> what

<articmine> If this is such an issue then the problem needs to be fixed

<boog900> no that is not an answer

<boog900> thats you being stubborn

<articmine> Sure it is. The only reason we are aware of this vulnerability is because of the stresstest

<articmine> Which in part was provoked by the scaling algorithm

<boog900> we can make scaling more aggressive during tests

<boog900> they key being tests why risk monero for 16?

<boog900> what makes it so important?

<articmine> No the real issue is why avoid fixed a serious problem

<boog900> listen. We can do both.

<boog900> why do we need 16?

<articmine> Why is 16 an issue

<boog900> because I think 32 MB blocks is too high for the short term

<boog900> monero currently breaks at 4MB FWIW

<spackle> mainnet would break at 1.5 MB without dynamic sync IIRC

<articmine> I know which one is why we have to deal with this

<ofrnxmr:xmr.mx> @spackle: IBD, yeah

<boog900> @articmine: I know

<ofrnxmr:xmr.mx> Monero also FULLY breaks at 25mb atm

<boog900> but taking it down to 16 MB max would make it much more likely we can get monerod to match scaling in the short term

<ofrnxmr:xmr.mx> Due to serialization

<boog900> and I see no reason why this is an issue

<boog900> we have never has a surge this high

<boog900> and VISA self reports this number anyway

<jack_ma_blabla:matrix.org> @boog900: except spam attacks

<articmine> @boog900: What happens if tomorrow there is a stat attack on VISA that takes VISA down

<boog900> @jack_ma_blabla:matrix.org: even then we have never had a surge this high IIRC

<ofrnxmr:xmr.mx> vtnerd has a pr that has been opened for well over a year (8867 iirc) that addresses some or all of the serialization issues

<articmine> Do you really think Monero will I be impacted

<ofrnxmr:xmr.mx> We've never had a competent spam attack, yet the sorry excuses have exposed issues (like causes nodes to crash (txrelay)

<articmine> @ofrnxmr:xmr.mx: So why is this open for a year?

<boog900> @articmine: why is this relevant?

<ofrnxmr:xmr.mx> @articmine: lack of review

<ofrnxmr:xmr.mx> monero-project/monero #8867

<boog900> does a state taking down VISA make us surge 16x?

<jack_ma_blabla:matrix.org> imho if there is a surge, users can pay higher fee & that will compensate miner penalty

<articmine> ... because if even a miniscule portion y the refugees end up on the Monero network we have a very serious vulnerability

<articmine> @boog900: Easily

<boog900> @articmine: exactly. why 16x?

<boog900> why not 32?

<boog900> 64?

<articmine> The higher the better

<boog900> monerod cannot handle infinite txs

<ofrnxmr:xmr.mx> > Unfortunately this diff is huge, and probably has no chance of ever being merged as-is. So I will try to break things into smaller chunks, with the caveat that if nobody wants the serialization to be replaced, its best to vote within this discussion thread here. > <@articmine> So why is this open for a year?

<jack_ma_blabla:matrix.org> @articmine: are we living in a parrallel world ? xmr adoption is sloww [checks daily tx count for last couple of years] and no way we can see a overnight surge in demand, especially when there are no easy onramps

<spackle> Of course we can see an overnight surge in demand, I don't think that is a good argument.

<articmine> One legal reveal ad the on ramps are open

<articmine> Reversal

<articmine> Expect a flood

<jack_ma_blabla:matrix.org> @spackle: a overnight demand shouldnt mean we allow spam attacks

<spackle> @jack_ma_blabla:matrix.org: agreed

<articmine> We are not allowing spam attacks

<jack_ma_blabla:matrix.org> @articmine: see recent mined btc blocks

<spackle> If there is a gap between daemon performance and scaling design in the short term, then yes we are allowing attacks.

<jack_ma_blabla:matrix.org> @spackle: network constrains too

<articmine> What is clear is that we are simply not ready for FCMP++

<spackle> That is not clear to me at all.

<boog900> we are not ready for the next 4 hours

<boog900> FCMP is makes no difference and actually makes things better if we drop the amount we can grow blocks

<jack_ma_blabla:matrix.org> @articmine: thats why we work with what we have now and adapt later when daemon is capable of handling 'surge'

seems that we are not ready for scaling beyond a certain point, certainly we can handle txs that are 4x larger

today

<ofrnxmr:xmr.mx> We can handle 4x larger txs, but not 100x larger blocks

<articmine> We are way below 109

<articmine> 100 x

<ofrnxmr:xmr.mx> 100x is 30mb

<articmine> I have heard like problems at 4 x

<articmine> Keep in mind that ZCash survived a 300x spam attack

<articmine> We should be able to at least match them

<ofrnxmr:xmr.mx> Some of the issues fixed on stressnet but not mainnet:

<ofrnxmr:xmr.mx> * 1.5mb blocks breaking IBD

<ofrnxmr:xmr.mx> * txpool dying / pruning all txs

<ofrnxmr:xmr.mx> * fluffyblocks not able to relay >4mb blocks[... more lines follow, see mrelay.p2pool.observer/e/wIyS_8MKV1phSWF2 ]

<ofrnxmr:xmr.mx> @articmine: I think they benefit from not having a broken mempool

<jack_ma_blabla:matrix.org> @articmine: so you want fcmp++ delayed till daemon code is optimized ? do we have resources? what would be eta?

<articmine> We have some very serious issues

<articmine> @jack_ma_blabla:matrix.org: We raise the resources

<boog900> why do we need to reach VISAs surge?

<jack_ma_blabla:matrix.org> @articmine: where are these coders ? we have tried recruiting in past

<boog900> like yeah we should process as many txs as possible

<boog900> but why this amount specifically

<jack_ma_blabla:matrix.org> someday mooon sun and regulations will align & a blackswan event will need xmr

<articmine> Yes we have no choice but to delay until we at least can match ZCash 300x without breaking

<boog900> why delay we are vulnerable now

<boog900> more vulnerable now

<boog900> this is block size not tx

<boog900> why with these arbitrary numbers from other systems too

<ofrnxmr:xmr.mx> Come from behind ia going to read this and fill mainnet txpool wirh 600mb of txs with fees at low tier :D

<ofrnxmr:xmr.mx> The majoriry of the txs will expire, cfb will get his money back, and xmr will be unusable

<boog900> I have though about making a count down till disaster website

<articmine> @ofrnxmr:xmr.mx: He doesn't have the money

<ofrnxmr:xmr.mx> @articmine: He has enough mined xmr for 600mb of dust txa

<jack_ma_blabla:matrix.org> @articmine: delay? eta? without a eta we cant delay it forever

<jack_ma_blabla:matrix.org> @ofrnxmr:xmr.mx: or any zolder

<jack_ma_blabla:matrix.org> @articmine: he has enough mined xmr to pay tx fees

<ofrnxmr:xmr.mx> So while we all fuss about block sizes, we wont even make it that far

<spackle> I'd prefer is we avoid abject pessimism, and stay solution oriented. There are steps that can would would be taken to handle any unexpected events.

<ofrnxmr:xmr.mx> i dont think about these as unexpecred events

<spackle> The unfortunate thing is that steps would need to be taken.

<ofrnxmr:xmr.mx> I wonder why nobody has done it

<spackle> Fine, I phrased that poorly. Still, I hope you see my point.

<ofrnxmr:xmr.mx> I see your point, but i think we need tk fix the immediate issues immediately

<jack_ma_blabla:matrix.org> @ofrnxmr:xmr.mx: now that this room is logged, it will be

<ofrnxmr:xmr.mx> maybe that will incentivize us to fix things instead of leaving prs open for 4 yrs

<ofrnxmr:xmr.mx> Its alwys better to be proactive than reactive

<ofrnxmr:xmr.mx> cfb's selfish mining exposed a few issues with our review process

<ofrnxmr:xmr.mx> I think one thing i do that isnt often done, is actually test stuff

<ofrnxmr:xmr.mx> There is a lot of code in monero that seems functionally correct, but doesnt actually work

<ofrnxmr:xmr.mx> So i wonder how tf it got merged

<0xfffc> Just do a master to release PR, to see how many useful PRs we have not merged to release

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: Thats not throwing shade at anyone, just amazes me sometimes how brittle monero is

<0xfffc> @ofrnxmr:xmr.mx: Process is broken. Not fault of single person

<ofrnxmr:xmr.mx> Like, blocks scale to infinity atm, but someone added hard limits on serialization and packet skzes

<ofrnxmr:xmr.mx> So monero dies at 32 and 100mb

<ofrnxmr:xmr.mx> Its not technically possible to relay blocks larger atm

<0xfffc> @ofrnxmr:xmr.mx: check the DMs

<ofrnxmr:xmr.mx> Someone added a 4mb limit to fluffy blocks

posted 10 min ago repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/621

<spackle> The good news is that we have come a long way recently. Still, I know we would all sleep much better knowing that at least the next 50k blocks are covered. I don't see another clean target in the existing design, so I'll continue to hold that up as a standard.

<spackle> Suppose I need to leave it here. Sorry to @boog900:monero.social for my poor comment earlier, I did not realize how badly it read until after I sent it and I did not mean to imply what it did.

<boog900> no need to say sorry I knew what you meant, it's not like I am doing the heavy lifting fixing monerod :D

<boog900> I get the more fun job of rewriting it :)

<rucknium> @0xfffc: @0xfffc:monero.social: If the process is broken, then leadership needs to fix the process.

<ofrnxmr> A lot of it is old fwiw

<ofrnxmr> Like, untested prs with unaddressed comments -> merged

<ofrnxmr> Currently the issue is manpower and duties. We have things that have been pending forever

<articmine> @ofrnxmr:xmr.mx: Why!

<ofrnxmr:xmr.mx> Idk

<ofrnxmr:xmr.mx> I think it has probably been there since fluffyblocks was first introduced

<ofrnxmr:xmr.mx> Jberman bumped it to 128mb on stressnet

<boog900> tbf fluffy blocks should be 2 messages IMO

<boog900> one for the block header notification one for the response to a request for missing txs

<jberman> someone presumably thought that the daemon wouldn't ever need to relay the fluffy block txs, and just header

<boog900> yep

<boog900> thats what the comment says

<boog900> the limits were added after the node DoS vulns around 2020

<articmine> Was the vulnerability fixed?

<ofrnxmr> is this the dom dos?

<boog900> there were multiple DoS vulns IIRC

<boog900> I don't know if this was a direct fix or just trying to make the system more resistant

<ofrnxmr> iiuc, 8867 (vtnerd) and 7999 (perfect daemon) both fixed the dom dos, but neither merged. There are hard limits in place instead (which essentially cap blocks to ~25mb)

<articmine> ... and all the hard caps do is mitigate but not stop the DoS

<articmine> Hence the "need" to cap the surge at 16 baking even more failure into the protocol

<articmine> Please understand why I have no choice but to take a very hard line on this

<boog900> @articmine: We can't do 16 MB blocks at the moment

<boog900> we need to make improvements to get there

<articmine> Can we do 8?

<boog900> I think a 16 MB surge is more than enough and a good target to reach

<boog900> @articmine: no as we said earlier, I think someone mentioned 1.5 MB?

<boog900> after that its 4 MB

<boog900> where the issues show^

<articmine> I really have no choice here. I can't yield on scaling at all.

<boog900> I mean thats fair it'll go to the vote

<articmine> PR not being merged for years are solved with scaling parameters

<boog900> and there isn't a good reason shown for 16x other than just trying to push devs to work harder

<articmine> There are many reasons but the arguments are pointless

<boog900> @articmine: The PRs to get us beyond 16 MB aren't even thought out yet

<boog900> the current PRs wont get us to 32 MB comfortably

<articmine> If devs develop PR that is then not merged for years.

<articmine> This mess needs to be cleaned up first

<articmine> We should not even consider FCMP++

<boog900> look we have already went over this

<articmine> Trying to hide the problem by preventing people from using Monero is not the answer

<boog900> 16 MB are more than enough!!!!

<articmine> @boog900: That is no longer the point

<boog900> trying to force devs to work by making monero vulnerable is also not the answer

<boog900> @articmine: it is the point

<boog900> you are dying on the 32 MB hill just to be awkward

<articmine> It is a question of priorities. Basic security or the glamourous stuff

<boog900> No

<boog900> we are vulnerable NOW

<boog900> not with FCMP

<articmine> I know

<boog900> it is Basic security and glamourous stuff OR VISA tx numbers

<boog900> visa tx surge*

<boog900> FCMP is unrelated this is block size

<articmine> 16 MB is like 15TPS Visa is like 9000 TPS

<boog900> I corrected myself

<articmine> With ring CT at least we can do 60 TOS

<articmine> TPS

<boog900> anyway this is going no where, it'll go to the vote

<articmine> Fine

<articmine> I am not going to be a party to what amounts to a coverup

<articmine> I don't get it . People are saying we can't even do 1.5 MB and you are arguing between 16 MB and 32MB

<boog900> I am trying to give us an easier target to hit, if you had a good reason for 32MB I would be more for looking at it

<boog900> but right now 32 MB is just targeting what VISA has reported as their surge

<boog900> it is not our surge, which you said is 2 to 3 x

<articmine> I actually have a solution right now for 8 MB right now with Ring CT

<articmine> But even that won't solve the problem

<boog900> go on ...

<boog900> no it wont but still

<articmine> Very simple implement my proposal with a 250000 bytes minimum penalty free zone

<articmine> Would work fine with our current RingCT

<articmine> Yes it is a HF

<boog900> oh I thought you were talking about getting the node to work with 8 MB blocks

<boog900> if we are changing scaling pre-FCMP I would rather it be a soft fork

<articmine> The 50000 block cap is 8 MB

<articmine> Do it as a soft fork

<articmine> I mean we are vulnerable now

<boog900> you can't change the penalty free zone in a soft fork

<articmine> True. Keep the penalty free zone and go to a 9600000

<articmine> Block cap for 50000 blocks

<articmine> 9.6 MB

<boog900> less than 32 MB?

<articmine> With ring CT and the current penalty free zone it is 9.6 instead of 32

<boog900> to reach VISA's surge?

<articmine> Down from the current 30 MB

<articmine> Yes we drop the surge from 50 to 16

<articmine> or the max from 100 to 32

<boog900> why VISA's surge?

<articmine> You are fixated on this

<boog900> 100% I want to know why we are basing our numbers on a different system

<boog900> I want to know what is so important about that you are unwilling to move

<articmine> We are basing on the patterns of commerce during the holidays

<articmine> It had to do with last minute shopping before a deadline

<boog900> which we have not seen

<boog900> who is to say that number has not changed and will not change overtime

<articmine> So we keep this at 50 instead

<articmine> and stay vulnerable

<boog900> I can't find the 20x claim anywhere > <@articmine> We are basing on the patterns of commerce during the holidays

<boog900> we have this one: web.archive.org/web/20141108055312/…tions-hit-peak-on-dec-23/index.html

<boog900> which is 5.5x as far as I know

<boog900> with 11x as max capacity accordingly

<boog900> that is the busiest minute as well

<boog900> not sustained

<articmine> In 2010 Visa did around 1400 TPS average

<articmine> So about 17.4x

<articmine> For the surge

<articmine> We must also keep in mind that a proprietary network has way more flexibility than a peer to peer decentralized currency

<articmine> So 16 with stiff pricing above makes optimal sense

<boog900> @articmine: no thats to get to their capacity

<boog900> the holiday surge is ~7.8x

<boog900> why are we trying reach their max capacity?

<boog900> @boog900: (if we use 1400, I have seen 2000)

<articmine> They need a peak capacity over 17.4x over their average TPS

<boog900> yeah nice but we are talking about Monero

<boog900> We can have VISA's reported surge and stay at 16 MB!!!

<articmine> 24000/1400 = 17.14

<boog900> thats their capacity

<articmine> It is the ratio that matters

<boog900> during a test

<articmine> Between average and capacity

<boog900> why do we care how many txs VISA can process

<boog900> we are talking about peoples habits

<articmine> It is the ratio

<boog900> and how likely they are to spend more during the holiday

<articmine> The same for 1 TPS vs 10000 TPS

<boog900> VISA said the chrsitamas peak was 11,000

<boog900> during the busiest minute

<boog900> You are being completely unreasonable

<boog900> I am done, it will go to vote

what is the likelihood that amazon or alibaba will start accepting monero? and then that people will use it instead of getting 3-5% back using visa at amazon

<articmine> People use Monero to buy gift cards

<ofrnxmr> Our avg tps is 0.33 tho

<321bob321> nioc: Black Friday sales ?

<articmine> Also Visa can increase capacity way faster than we can agree on a hard fork.

<articmine> This thread proves that. So we actually should have a bigger percentage margin that Visa

<boog900> 8 > 7.8

<boog900> also this is the busiest minute

<boog900> nothing is going to convince you to change from 32

<sgp_> We wouldn't want someone to wait 2 blocks to get a confirmation in the busiest time of year, that's a complete failure of Monero. All peer to peer transactions will immediately migrate away from Monero and to ChainTRMtic Coin

<sgp_> (I'm being dramatic but it does seem to be the type of foil applied, with only a slight exaggeration)

<articmine> Card payments take 2-4 days to settle ve 20 min for XMR

<ofrnxmr> 2 days to settle for xmr on a busy holiday isnt going to be end of the world imo

<sgp_> So why do we need a burst allowance if it's ok to take 2 days to process the burst without a burst increase?

<articmine> Who said 2. days to settle XMR

<articmine> I said 2-4 days for Visa

<ofrnxmr> Im just saying that at 16mb, its not like we lose the txs. They just take a it longer to confirm

<sgp_> I'm saying if because of a burst in demand, the backlog grows to 2 days. Without increasing the block size. But within 2 days later, the backlog/mempool is confirmed

<articmine> You mean Bitcoin

<ofrnxmr> And i also suggested that we could add a 5th fee tier that is 10000x if we really want to grow beyond 16mb, because its not feasible to maintain those blocks for long

<ofrnxmr> If we wamt to grow beyond 16mb in the short term*

<articmine> 5 fee tiers are a good idea

<articmine> 1 4 16; 64 256

<sgp_> No. I mean suppose that blocks aren't full before black friday. But then bang, black friday happens. A huge mempool forms with 100x the normal capacity. It takes us 250 blocks to clear new transactions and the backlog fully.

<sgp_> That's 8.3 hours, still way faster than a Visa "2-3 day" confirmation. So even with a 100x increase, do we need blocs to grow for a temporary burst? Even without the growth, Monero can win on speed

<articmine> With your proposal it can easily take longer than Visa

<articmine> Bitcoin

<articmine> Is an example

<sgp_> I'm not saying for my proposal, I'm saying even for your example with blocks that aren't full, why do we need the burst if we have 2 days of flexibility to confirm

<articmine> People are complaining about 20 min

<sgp_> yeah but it's you comparing the Visa processing capacity match. If you're cool with 2 days, then that suggests we don't need the burst?

<sgp_> 2 days is 1,440 blocks, that's a lot

<articmine> I am not cool with 2 days. I am a cash guy

<sgp_> new Monero L2 just dropped: cash! Withdraw XMR to cash once a month, use cash for p2p transactions. Scalability solved /s

<sgp_> People can of course pay more to get in the next block if they can't wait the 2 days

<sgp_> those who don't want to pay more go back into the "visa speed" lane temporarily, in a way. At least continuing your analogy

<articmine> @sgp_: Bitcoin miners should accept XMR to accelerate BTC confirmations

<sgp_> some already accept credit card for that, see mempool accelerator

<articmine> I had a situation in 2018 where the miner only accepted BCH. No card and no XMR

<articmine> It finally cleared the Bitcoin network a few hours later

<ofrnxmr> I mean, 2days is an exaggeration. 16mb blocks is 1.15m txs per day > <@articmine> I am not cool with 2 days. I am a cash guy

<sgp_> btc rbf has come a long way. They've committed to rbf

<ofrnxmr> Rbf would be nice as well, but imo only if the tx parameters are the same. Essentially just a fee bump

<sgp_> mrelay.p2pool.observer/m/monero.social/vmJGdKMrfbMNCynXjywtYOqY.png (image.png)

<sgp_> 0.18 sats fit in the most recent block, wow. Very cheap txs currently

<articmine> A double spend so that the miner takes the higher fee tx instead

<ofrnxmr> 16mb blocks is 11gb per day

<ofrnxmr> The txpool is 600mb

<articmine> Kills 0 confirmation transactions

<ofrnxmr> @ofrnxmr: ^ artic

<ofrnxmr> Meaning the tx would be the same tx just with a higher fee

<sgp_> It does kill 0-conf by making the existing risks more pronounced. Whether that's a good or bad thing will depend on who you ask

<articmine> @sgp_: Yes I know . Most of the economy has move to the banks so there is some room on chain

<sgp_> @ofrnxmr: that's not enforceable though right?

<sgp_> miners don't need to care about the unconfirmed transaction and what it says

<ofrnxmr> No idea

<sgp_> you can ask miners "please don't do this" but they can ignore you

<ofrnxmr> If a miner ran an alt implementation that accepted double spends, i guess? But normally it would treat it as a double spend if the tx was identical sans the fee

<sgp_> miners have an incentive to take whatever tx has the higher fee and claim ignorance of the mempool one

<articmine> Bitcoin is a broken system

<sgp_> @sgp_: this applies to Monero as well, today, fwiw

<articmine> Yes it does apply to Monero, but the incentives are very different

<sgp_> I'd argue the anonymity offers a potentially greater incentive to try and fleece people, ha

<articmine> @sgp_: I know that we disagree on this, but Blockchain Surveillance does not work on Bitcoin

<articmine> There is more prii on Biti than people give it credit for

<articmine> Privacy

<sgp_> My main point it just that @ofrnxmr:monero.social your idea of preventing rbf except to the same recipient isn't enforceable unfortunately, for Bitcoin or for Monero

<sgp_> rbf will be a potential risk even if normal nodes reject rbf

<sgp_> which is one of the main arguments in favor of embracing rbf

<ofrnxmr> Well, my initial purpose for rbf was to rbf invalid transactions

<articmine> Online the merchant can wait. In person shoplifting or dine and dash are a much greater risk that an Rbf double spend with Monero

<sgp_> I tend to agree