<articmine> @boog900: It is not that simple. For example if the amounts going through the turnstile are exposed, are people comfortable sending large amounts across the turnstile or will they spit up the amounts beforehand, and consolidate at the other side?

<articmine> What is the greatest amount a person is prepared to expose?

<articmine> How does this relate to cash or AML limits

<boog900> I think you misunderstood my comment, I meant why care about any of this now when adding a turnstile is a change to consensus so we can just adjust the scaling code at the same time we add the turnstile

<boog900> we have no idea what a turnstile will look like, the size of txs going through the turnstile, the size of txs on the other side etc. This is not something we can plan for now

<articmine> @boog900: For starters would we be legally allowed to may the change then?

<articmine> Will the nodes be ready ahead of time?

<boog900> if we can't legally change the code we can't legally add a turnstile as both are a change to consensus

<articmine> Not necessarily.

<boog900> > Will the nodes be ready ahead of time?

<boog900> They have to be there is zero code for a PQ turnstile currently

<boog900> when we add that code we can change the scaling code

<articmine> A turnstile would be considered a necessary security measure.

<articmine> This is very different from splitting transactions to defeat blockchain surveillance.

<articmine> So we may not be able to add the additional scaling code in the future

<boog900> ok that situation is so stupid

<articmine> Take a look at the legislation being proposed. There is a lot of grandparenting allowed.

<articmine> Governments can be very stupid

<gingeropolous> were the ElGamal commitments baked into carrot?

<boog900> you can't just make random hypotheticals like that. I can do the same, what if a turnstile tx is 100x smaller than a FCMP tx, this would provide the increase in capacity because each tx would be smaller.

<ofrnxmr:xmr.mx> @articmine: In a situation where a government isnt "allowing" development of monero, then im also not relying on grandfather laws

<boog900> what if governments decide themselves to reduce the size of monero blocks by law

<articmine> @boog900: Much harder to get through the courts

<ofrnxmr:xmr.mx> and what if it does get through the courts

new law: blocks may not exceed the penalty free zone

<articmine> My point is that the onus will most likely be on those who are proposing the changes

<ofrnxmr:xmr.mx> Must be throttled to 50 transactions per minute, and must be transparent

<ofrnxmr:xmr.mx> otherwise your aiding money laundering

<ofrnxmr:xmr.mx> Monero-project labelled a terrorist financing org and sanctioned

<articmine> @ofrnxmr:xmr.mx: ... . but existing code is grandfathered

<ofrnxmr:xmr.mx> According to?

<articmine> The state

<ofrnxmr:xmr.mx> which state?

<articmine> This kind of thing is already in legislation

<articmine> The EU

<ofrnxmr:xmr.mx> nobody (me) cares what the eu says

<boog900> except for turnstiles, which are ok to add? > <@articmine> ... . but existing code is grandfathered

<ofrnxmr:xmr.mx> Not my circus, not my monkeys

<articmine> Have you attended MoneroKon?

<ofrnxmr:xmr.mx> No

<articmine> I have and have spoken ther

<articmine> There

<articmine> So hat many other people here

<articmine> Have

<boog900> we aren't basing our scaling code on hypotheticals this crazy

<ofrnxmr:xmr.mx> and eu atill hates monero.. i dont see what monerkon has to do with this discussion

<boog900> so many assumptions about the future

<ofrnxmr:xmr.mx> anyway, the logical thing here ia that, obv, a hypothetical turnstile doesnt yet exist_ and is therefore not a part of whatever is being grandfathered

<articmine> Please read the legislation

<articmine> What is being proposed

<ofrnxmr:xmr.mx> eu legislation? Why would i do that

<ofrnxmr:xmr.mx> Not my circus, not my monkeys

<ofrnxmr:xmr.mx> And even if i lived in a country in europe, is rather ask my country to be sane and stop following the laws of some entity that we dont vote for

<boog900> @articmine: show me where it says we can add a turnstile but can't change scaling

<boog900> also show me the size of a turnstile tx, how many txs we expect to go through, the time frame we allow this for, the size of PQ txs on the other side ...

<ofrnxmr:xmr.mx> I don't see why japan can ban privacy coins, but the eu cant

<ofrnxmr:xmr.mx> Is there legistlation that says that privacy coins created before N date are exempt from future regulations?

<ravfx:xmr.mx> Only thing I did read about the EU scam is that they are going to ban the custodials to have them (that would include payment processor, other than self hosted one, afaik).

<ravfx:xmr.mx> 2027

Here is a good example "A safe harbour is provided for digital assets issued prior to the CLARITY Act’s enactment, enabling continued operation if issuers meet specified disclosure and conduct requirements."

So yea this may be the last time we can make changes without having to go through regulatory hoops.

We must be very careful with any consensus change that could possibly favor blockchain surveillance, including but not limited to throttling scaling

<articmine> The US is one country that has not banned Monero

<articmine> From exchay

<articmine> Exchanges

<articmine> As for a turnstile that would easily be seen as a necessary change due to changing security circumstances

<articmine> This is not hypothetical. It is legislation before the US Congress > <@boog900> we aren't basing our scaling code on hypotheticals this crazy

<ofrnxmr:xmr.mx> ArticMine: since when has the codebase ever catered to regulations?

<ofrnxmr:xmr.mx> eu based devs may be discouraged from making changes, but that doesnt apply to the rotw

<articmine> @ofrnxmr:xmr.mx: I am not supporting change to the codebase that favor government sponsored surveillance

<boog900> I fail to see how it makes any sense that in the real world we can upgrade our whole protocol except for the scaling code.

<articmine> We could have a similar problem if we waited for FCMP++

<articmine> It is not just scaling

<boog900> and you don't think we will have the same problem when we go PQ?

<articmine> We can argue security

<articmine> That is the critical difference

<ofrnxmr:xmr.mx> this problem seems fully dependent on consensus that we should neuter monero in order to comply with some alphabet gang

<ofrnxmr:xmr.mx> In which case monero may as well be dead

<articmine> @ofrnxmr:xmr.mx: No the problem is that we must not neuter Monero in order to avoid having to deal with this gang in the future

<ofrnxmr:xmr.mx> Whether its some change to cripple scaling or to ossify the codebasebas a result of grandfather-only laws, is ridiculous

<boog900> trying to plan for every future will lead to the only possible conclusion being infinite block sizes with 0 scaling.

<articmine> @ofrnxmr:xmr.mx: I have said before I am fine with the current scaling . I am very opposed to adding future scaling restrictions

<ofrnxmr:xmr.mx> whatever regulations of past, present, or future say, monero as a codebase will keep honest with its stated goals. If it doesnt, its not monero anymore

<boog900> @articmine: why? what if a PQ turnstile requires txs at 15 kbs?

<articmine> @ofrnxmr:xmr.mx: Do you agree that we must make government surveillance as hard as possible yes or no?

<articmine> @boog900: Vs 9 today?

<boog900> 150 then the number was pulled out of thin air

<ofrnxmr:xmr.mx> Sure. I also believe that the changes can be made at any time, regardless of what some legislator wants, or what is considered grandfathered

<boog900> I am choosing numbers that fit my argument

<articmine> We would have a much stronger case if we do not increase the minimum penalty free zone by the same ratio as the tx size

<boog900> I believe relying on future users to magically show up is stupid, we need to make the best system possible now, and that includes making the system resilient to attacks.

<articmine> Regardless of 15 kB or 150 kb

<articmine> My point is to not give a regulator ammunition

<articmine> What I am saying is that the regulatory landscape is changing fast

<boog900> Ok, so we need to account of turnstiles

<articmine> So we must lock in now the strongest privacy

<boog900> how big are the txs?

<ofrnxmr:xmr.mx> @articmine: why?

<boog900> @articmine: exactly infinite block size

<ofrnxmr:xmr.mx> Why "lock in"

<ofrnxmr:xmr.mx> sounds like calls to ossify btc codebase

<articmine> It is the exact opposite

<articmine> Please

<ofrnxmr:xmr.mx> Its not. If the idea is that regulators will force us to not make changes, then thay is ossification via regulation

<articmine> @boog900: An adaptive blocksize is by definition infinite

<ofrnxmr:xmr.mx> we have a 100mb packet size limit

<articmine> That has been the social covenant of Monero since it's inception

<boog900> @articmine: I mean no scaling

<boog900> otherwise we can argue a block size of 1 byte growing 1 byte every 100 years fits your requirements

<boog900> you want scaling to take into account a turnstile, of which we have 0 details of

<boog900> how does one even start to do that

<articmine> We know what the number of inputs into the turnstile will like be, and also the likely size of those inputs

<boog900> no we don't

<boog900> we don't know the number of outputs on the chain at the start of the turnstile

<boog900> and that's only 1 part

<boog900> size of the tx is the main one

<jeffro256> @gingeropolous: @gingeropolous:monero.social: el gamal commitments aren't baked into carrot, but an almost-as-strong quantum-resistant opening scheme is baked into Carrot amount commitments . it does require revealing the amount in a turnstile tho

<articmine> @boog900: The unknown is the output tx size etc.

<jeffro256> Well its equally as strong as a switch commitment , but weaker than a pure el gamal commitment

<boog900> @articmine: ok lets say that is the unknown and you know the rest of the turnstile protocol now, that is still an unknown

<articmine> But even there we already have indications of proof sizes

<boog900> you want us to guess?

<articmine> Better than burying ones head in the sand

<boog900> so you would rather our heads be in the clouds, got it

<articmine> The issue we can work on ahead of time is transaction rates, and current transaction size

<articmine> This is not guessing

<boog900> NO

<boog900> we are talking about a turnstile

<boog900> you wanted to guess the size of turnstile txs > <@articmine> But even there we already have indications of proof sizes

<articmine> This is an excellent start > <@kayabanerve:matrix.org> The sooner we prepare today, the less of a rush we'll be in tomorrow

<boog900> even then we cannot predict tx rates in the future

<boog900> we can estimate based off of the past but we have no clue what good/bad thing will happen that could cause a huge increase/decrease in tx rates

<boog900> @articmine: so you want us to wait for a PQ protocol before FCMP?

<articmine> What I do not support is stepping backwards in this

<boog900> before changing scaling*

<articmine> @boog900: No

<jeffro256> Maybe we move to something like a shielded CSV type protocol in the future so transaction sizes matter much less to L1 validators, regardless of crypto proofs used

<jeffro256> That would take longer than FCMP++ tho IMO , so that regulation would maybe already be in effect

<boog900> @jeffro256: nah but what if there was a law that made that proof illegal!

<articmine> My position is go ahead with FCMP++ and maximize rather than throttle scaling

<jeffro256> One pro for the big block argument that I haven't seen yet in this chat is that the block size can always be limited with a future soft fork, whereas increasing requires a hard fork

<articmine> We need to stop this negativity that the growth of the peer to peer on chain Monero network is some kind of a bad thing

<articmine> @jeffro256: Now here is a sensible approach

<boog900> @jeffro256: absolutely, my main argument is not for restricting growth in the long term but mainly short term. Like this is cool but currently blocks can grow way faster than we can put a softfork out to prevent damage

<boog900> and once a softfork is done, undoing it is a HF

<articmine> @boog900: Which is why I made my proposal

<articmine> Shift the growth to the long term.

<jeffro256> A soft fork still might take weeks/months to get IRL consensus on , and more weeks/months to activate. In the meantime , node usability could be suffering dramatically

<boog900> @articmine: yeah and thats cool, but you don't have to make out any modification is going to kill scaling.

<articmine> @jeffro256: So we need to be looking at a 2 to 4 month period

<jeffro256> Probably longer realistically

<articmine> How much longer

<jeffro256> Qubic spam lasted for months

<jeffro256> I wouldn't go lower than current 100K blocktime median

<articmine> I am not proposing making the long term median shorter

<articmine> What I proposed is lowering the growth of the blocks from 100x to 16x during the 100000 block long term median., and increasing the rate of growth of t long term median from 1.7x to 2x

<articmine> The fastest the long term median can move is 69 days

<articmine> Over 138 days we go down from 170x to 32x.

<articmine> The small blockers won't even accept that

<articmine> So we had an impass

<articmine> Have

<boog900> lets be clear, today started as you stated you wanted to account for a future turnstile in the scaling

<boog900> I want our scaling numbers to be real not pulled out of thin air

<articmine> I have provided real historical data for both Monero and Litecoin

<articmine> On numerous occasions

<boog900> so you now agree that accounting for a future turnstile is not a good idea?

<articmine> We cannot predict a future turnstile in all its details, but we know that it will place significant demands on scaling.

<articmine> This means that the there is not a cast to reduce scaling

<articmine> Case

<gingeropolous> bummer. would an el gamal have required revealing the amount? i'm trying to find the conversation about this. Why was it decided to not go this route? > <@jeffro256> Well its equally as strong as a switch commitment , but weaker than a pure el gamal commitment

<boog900> we don't know that tbf, turnstile txs could be significantly smaller and we almost certainly are going to be able to adjust the scaling at the time if it it is required

<articmine> @boog900: Then that would be a case to reduce the minimum penalty free zone

<articmine> ... but this has nothing to do with t rate of growth of the long term and short term median s

<boog900> Ok so we do both, make scaling more aggressive and make scaling more aggressive to account for this?

<jeffro256> @gingeropolous: It wasn't chosen since el gamal commitments reveal would've revealed all historical amounts to quantum computers, regardless of a turnstile or any interaction

<jeffro256> And their proofs are more expensive

<boog900> @articmine: the point is we don't know if the txs will be bigger or smaller

<articmine> I am proposing less aggressive over the short to medium term

<articmine> @boog900: Which really should only affect the minimum penalty free zone

<gingeropolous> so like, if a quantum computer broke el gamal it would reveal everything?

<boog900> @articmine: but a more aggressive penalty free zone and a more aggressive long term, which is +2 months?

<jeffro256> @gingeropolous: yeah basically

<boog900> @articmine: why if the txs are bigger we need to account for them in the limits?

<boog900> how do you even know how much we are accounting for?

<jeffro256> It would be information theoretically safe against counterfeiting, but the amounts would be revealed w/o interaction

<articmine> The more aggressive penalty free zone is based upon the 4x larger tx size

<gingeropolous> gotcha. and whatever thing we turnstile to will be more better than el gamal at doing this i guess

<articmine> This is a separate issue from the median growth rat

<gingeropolous> but it would have revealed amounts, but kept the supply secure.

<articmine> Now if people want to lower the penalty free zone it really only means higher short term fees

<gingeropolous> and instead we're opting for a turnstile where we have to reveal amounts.... ?

<boog900> @articmine: It does factor into the maximum size you can spam from 0.

<jeffro256> A turnstile with switch commitments would only reveal the amounts migrated across the turnstile, and not all historical amounts for all transactions. And since enotes aren't necessarily tied to any individual, a whale who knew the turnstile was coming could split their amounts into 100 coins and slowly pull them across the tur [... too long, see mrelay.p2pool.observer/e/pd-WvcwKTDFWOTI2 ]

<gingeropolous> ah. danke

<gingeropolous> sorry i missed this convo 1 year ago :/

<gingeropolous> or forgot it

<ofrnxmr> Right now, on stressnet, it takes like 24hrs on lvl 3 fees to hit 14mb blocks

<ofrnxmr> stressgguj7ugyxtqe7czeoelobeb3cnyhl…ae2t3avd5ynepid.onion/block/2883200 = empty blocks

<ofrnxmr> stressgguj7ugyxtqe7czeoelobeb3cnyhl…ae2t3avd5ynepid.onion/block/2883900 = 14mb

<gingeropolous> but it still has the race thing. like, everybody has to go through the turnstile. that wallet seed that I may or may not have buried in behind the old oak down the fence needs to be processed within n years ....?

<jeffro256> lol np. it's easy to get lost in the weeds about potential future designs of systems we don't exactly know how to make yet

<ofrnxmr> @ofrnxmr: Lvl 4 fees would be even faster, ofc

<ofrnxmr> This is with current scaling and penalty zone, ofc

<articmine> @jeffro256: Which is why transaction capacity is so important

<articmine> Especially if there is a significantly int in price

<articmine> Increase

<jeffro256> @gingeropolous:monero.social: One design would be to allow spending for an indefinite time, but stopped when the total amount gone over the turnstile is the expected total coinbase emission up to that point. So you wouldn't be racing N years, you'd be racing quantum computers.

<boog900> yeah that would allow a QC user to get quite a bit of monero probably though

<gingeropolous> which still puts an expiration on my buried money

<jeffro256> Yes, that's the opposing argument. Do we allow "theft" of funds by quantum computers?

<boog900> how much is still in V1 outputs, like 1,000,000XMR ?

<jeffro256> Last time I checked, 9% of the supply

<jeffro256> If we only allow spending of switch commitments over the turnstile, the pre-RingCT funds are locked regardless

<articmine> @boog900: I must be clear here. What I am really concerned about is the growth rate of the long term median. If people want to lower the penalty free zone to 500000 bytes I am not standing in the way. It I mean a 4 x increase in fees

<boog900> @jeffro256: are we doing something similar with key images?

<boog900> as they are randomized too now right?

<gingeropolous> guh. i refuse to accept this turnstile thing. somewhere in math there is a solution

<articmine> @jeffro256: Some people would have to migrate fii to FCMP++

<articmine> First

<articmine> So

<jeffro256> @boog900: Yeah that's where it gets a bit trickier

<jeffro256> If we don't need sender anonymity for turnstile transactions, we could simply reference inputs like BTC does: with (TXID, tx local output index) pairs and then assert that those are unique

<boog900> ewww

<jeffro256> yeah

<boog900> I guess it works and should be pretty private if we only do it for those txs

<boog900> probably be best to enforce it to be single input txs

<boog900> fun job for whoever has to make the protocol :p

<gingeropolous> hrm. we could have an initial turnstile window, and then after that, keep the turnstile open and allow n every year.

<gingeropolous> you forfeit some to a quantum attacker, but a limited amount, meanwhile keep existing money sound. well, i guess soundness is getting dinged by minting of new money

<gingeropolous> but we mint new money all the time anyway

<gingeropolous> 0.6 xmr a block

<gingeropolous> i really don't wanna go dig up that box

<articmine> We will continue the emission on the other side. It should be a fixed amount equal to the emission until the quantum fork

<gingeropolous> cause i never thought my monero would expire.

<articmine> In theory it is a race against the quantum computer

<gingeropolous> @articmine: yeah i know, im blue skying a possibility where we also add n xmr per block allowable through the turnstile.

<gingeropolous> past the original emission

<boog900> I think that would just by eaten by a QC and you risk giving a huge chunk of the supply to 1 entity

<gingeropolous> though i guess that would just get exploited by the innevitable quantum attacker

<gingeropolous> bah

<boog900> once we think there is a QC capable of breaking Monero, no more non-QC-secure coins should be able to be spent IMO (sadly)

<articmine> @boog900: We just have to mat sure the Monero can get past t turnstile in time

<boog900> yes yes hopefully the smart guys at the time can change the scaling code

<gingeropolous> poor folks with timelocked funds

<gingeropolous> or i guess we just change that rule? thats consensus right/

<boog900> hmm

<articmine> @boog900: Or maybe they won't need to

<boog900> yeah that would be a good idea tbf, before the turnstile disable timelocks

<jeffro256> yeah, if an emergency turnstile is setup at some point, I think it'd be reasonable to allow timelocked funds to unlock

<boog900> or if we really wanted to keep the timelock we allow them to be turnstiled but lock the funds on the other side.

<gingeropolous> though, one could argue that the el gamal thing, with the possibility of revealing amounts with the benefit of securing against counterfeiting without a turnstile would just put monero back to where it started. BS still couldn't determine where the money is going or where it came from.

<jeffro256> That's assuming people quantized their amounts like they did back in the day. We would proactively have to be able to only send XMR amounts with a single significant digit

<jeffro256> If I received 7.572004151832 XMR, then spent 7.572004151832 XMR in a turnstile, I don't have very much sender privacy

<gingeropolous> indeed

<gingeropolous> aight, so thats counterfeiting. anything baked in for QC theft?

<gingeropolous> wheres the hash

<gingeropolous> but yeah i agree that the scaling issue should err on the side of allowing growth. as mentioned, artificial limits can be rolled out with soft forks or just modding relay / block formation policies. And I feel we should always treat the next hardfork as potentially our last.

That's how I treat my deaths.

<monero.arbo:matrix.org> > <@articmine> What I proposed is lowering the growth of the blocks from 100x to 16x during the 100000 block long term median., and increasing the rate of growth of t long term median from 1.7x to 2x

<monero.arbo:matrix.org> I just don't think 4-5 months (100k blocks) is enough to really be called "long term".... 2x implies the block size can grow over 6x in a year, and again the next year.... looking at up to 38x block growth in just 2 years sooo, if fcmp has a 1 MB penalty free zone, that's 38 MB blocks in just two years?

<monero.arbo:matrix.org> the issue isn't even the size, it's block verification times, keeping nodes synced and syncing new nodes

<monero.arbo:matrix.org> I just don't think having a temporary fee market is a big enough deal to leave this kind of risk out there. I see it as a natural consequence of rapid growth, supply and demand type shit. as long as we aren't artificially restricting supply, but rather implementing reasonable safety limits

<ofrnxmr:xmr.mx> @monero.arbo:matrix.org: It can grow to 38mb in 2 days

<ofrnxmr:xmr.mx> W/o using max fees

<ofrnxmr:xmr.mx> Probably 1 day with max fees (i havent tried)

<monero.arbo:matrix.org> jesus fuck

<ofrnxmr:xmr.mx> I only got up to 40mb before exhausting my inputs / blocks consuming my inputs faster than coinbases unlock

<monero.arbo:matrix.org> that's so dumb I can't even believe this is a conversation.... what is the "2x" long term then?

<ofrnxmr:xmr.mx> I dont know where (or if) the short term caps. I thought it was supposed to cap at 30mb but i guess not

<monero.arbo:matrix.org> oh I misread, the long term is 16x... the short term is 2x?

<ofrnxmr:xmr.mx> you can double every 100 blocks or so

<ofrnxmr:xmr.mx> Short term median is 100 blocks

<monero.arbo:matrix.org> that's madness

<ofrnxmr:xmr.mx> Or about 3hrs

<monero.arbo:matrix.org> currently that doubling (well, currently 1.7) caps at 100x but you're suggested 16x, is that right?

<ofrnxmr:xmr.mx> matrix.to/#/!zxoYuvZdPYtIuWSQnn:mon….org&via=monero.social&via=envs.net > <@ofrnxmr> Right now, on stressnet, it takes like 24hrs on lvl 3 fees to hit 14mb blocks

<ofrnxmr:xmr.mx> you can see herr that i started spamming at block 201 (block 200, 199 empty) , and by 900 (slightly before) was at 14mb

<ofrnxmr:xmr.mx> From 14 -> 30 would have taken jist anothrer hundred blocks, but i had a wallet problem and blocks shrunk

<monero.arbo:matrix.org> I mean yeah I get you, it seems like I had the long and short term multiplier reversed..... but that's even worse

<ofrnxmr:xmr.mx> @monero.arbo:matrix.org: Im suggesting that i dont know how the math is supposed to work, but in practice it lets me raise block size extremely fast with relative low costs

<ofrnxmr:xmr.mx> Lvl 3 fees arent all that high (which is what i use). Lvl 4 raises the blocksize much faster

<monero.arbo:matrix.org> gotcha sorry ty for the info

<ofrnxmr:xmr.mx> I guess the good thing is, on the later releases on stressnet (1.4 and 1.5test), we did;t have any issues reported during those large blocks

<ofrnxmr:xmr.mx> (this was within the past 48hrs)

<monero.arbo:matrix.org> well heck let me spinup my node

<gingeropolous> my core2duo is catching up!

<gingeropolous> sorry, core2quad

<boog900> someone should make a miner that just mines block at the max size no matter the fee/penalty

<boog900> see how long we last

<boog900> on stressnet* obv don't do so on mainnet

<gingeropolous> i know someone said there are graphs somewhere, but i wasn't able to hunt them down

<rucknium> @gingeropolous:monero.social: github.com/spackle-xmr/Dynamic_Block_Demo/tree/main/Media

<gingeropolous> thank you!

<ofrnxmr:xmr.mx> @boog900: We need multiple ppl spamming for that

<ofrnxmr:xmr.mx> I can only get us to 14mb before i run out of inputs

<ofrnxmr:xmr.mx> also its (wallet) resource intensive - i have to slow down block production (on private testnet) to produce txs faster than they are mined

<articmine> With the current code. Not with my proposal. This y nothi but FUD > <@ofrnxmr:xmr.mx> Probably 1 day with max fees (i havent tried)

<boog900> You could make txs with huge extra fields

<boog900> or is that now consensus with FCMP 🤔

<articmine> Nothing but DUD

<articmine> Where is the spam attack that has done this!

<gingeropolous> the tx extra cap is a relay rule for mainnet, right?

<ofrnxmr:xmr.mx> @articmine: mainnet span attacks have been totally incompetent

<boog900> yeah but stressnet is where this test would happen

<articmine> I had not happened since the launch of Monero

<ofrnxmr:xmr.mx> Because nobody thought to do it

<boog900> damn must be impossible then

<boog900> any vuln that hasn't been exploited is not a real vuln

<gingeropolous> time for lab meeting :)

<articmine> @ofrnxmr:xmr.mx: Haven't you even considered that the current system works?

<boog900> key image inflation vuln was not real

<boog900> @articmine: it doesn't

<boog900> the last spam broke wallets

<boog900> both stressnets have broke nodes

<ofrnxmr:xmr.mx> like how invalidating txs must be impossible. We did it on testnet and it worked. so because nobody did it on mainent, it was impossible. Until qubic invalidates 100+ txs the next day

<articmine> Prove it

<boog900> @articmine: STRESSNET

<boog900> AAAHHHHH

<articmine> You have not

<boog900> I am not doing this

<boog900> again

<ofrnxmr:xmr.mx> Stressnet literally fixed a bunch of issues that would have broken mainnet

<articmine> Yea

<ofrnxmr:xmr.mx> Just because nobody performed these attacks on mainnet, doesnt mean that they are even difficult

<articmine> But what prevented the exploitation of these itssuest

<articmine> On mainnet

<ofrnxmr:xmr.mx> nothing

<articmine> I strongly disagree

<boog900> You can disagree the sky is blue

<boog900> Doesn't mean shit

<ofrnxmr:xmr.mx> Theres absolutely nothing preventing someone with a coupke thiusand dollars from owning the chain for 48hrs and bringing blocks to 30+mb while causing chainsplits

<boog900> Or just with compute power like qubic

<articmine> Has the problem not being fixed

<ofrnxmr:xmr.mx> The person who spammed 1/16 txs years ago can likely do this at any point in time, and ive wondered for years why they havent

<ofrnxmr:xmr.mx> Not all of the fixes have been upstreamed, and the issues arent entirely resolved either

<ofrnxmr:xmr.mx> I think the 4mb fluffy block relay is one that hasnt been upstreamed yet

<articmine> I Then we need to address these issues first

<articmine> Destroying the peer to peer use of Monero is not the answer

<boog900> Reducing the growth rate at all is not doing that

<articmine> This is not a scaling issue. It is a code quality issue

<boog900> Get coding then

<gingeropolous> cuprate will save us

<sgp_> I'll make a new coin that can do 1 billion tps on my centralized server so we can kill visa once and for all. You're welcome. Now that visa is killed we can pick different priorities/goals with monero

<sgp_> I'll introduce the radical idea of picking a less efficient L1 that can't efficiently handle the world's transactions entirely within this L1, but the transactions incorporate this novel privacy technology called FCMP. I know you probably haven't heard of it but it's cool

<sgp_> Bonus points for making it even less efficient but appropriately quantum resistant

17:53:12 <br-m> <boog900> someone should make a miner that just mines block at the max size no matter the fee/penalty

^ I could add that for next stressnet

just cram as many txs into the block as possible until base reward becomes just around 0 :)

max block size by consensus rules = 2x the median size

<preland> sech1: This could be changed or removed on a stressnet for fun/not profit

I mean, 2x the median size is also when block reward becomes 0 :)

18:39:54 <DataHoarder> ^ I could add that for next stressnet

^ even better pad block size up to miner tx defined maximum, then start adding txs

if you want quick growth we can set it up ahead of time in a defined way to ensure the testnet xmr lasts

ah, and each block found could pay out many outputs if we run out of them too quick :)

<datahoarder> @jeffro256:monero.social: For seraphis-migration/monero #245 / jeffro256/carrot-rs 72de440 I see you updated the result hash/keys but the input was left the same. This is fine except this input was not arbitrary, but derived from existing keys an [... too long, see mrelay.p2pool.observer/e/mZmn2cwKMXQtSDBH ]

<datahoarder> On my code git.gammaspectra.live/P2Pool/consen…602e30f1dbda7b8e608c1d19c17a7032ea2 I have gone to the effort to correct all the test inputs to match the derivations from the master secret given.

<datahoarder> Do you want to change your convergence tests to align test inputs with master secret derived values (with new Blake2b personalization), or keep these as is? I can send a PR if you want just hashes/keys updated, or if you want to derive them all like it was done on mine, probably easier to have you do that.