<articmine> seraphis-migration/monero #44

<articmine> I do believe we have consensus here.

<articmine> Correction m

<articmine> I do not believe we have consensus on the scaling parameters.

<articmine> We also may have a significant conflict of interest here, given the very radical counter proposal that was presented.

<articmine> monero-project/research-lab #152

<articmine> In my view the real purpose of this simple proposal is to destroy the use of Monero as peer to peer cash in order to protect the interests of the Blockchain Surveillance (BS) industry

<articmine> Having lived through the destruction of Bitcoin as peer to peer cash I can see why Roger Very had to write Hijacking Bitcoin and expose the very significant conflict of interest in that project.

<articmine> Given the current lack of consensus on the scaling parameters it is best to leave them as is. As for the penalty free zone it should be increased to reflect the ratio of the before and after weight for a 2in 2 out transaction. So 1200000 bytes.

<articmine> This is the most common type of Monero transaction.

<articmine> Do we really peer to peer cash and privacy or or centralized ledgers and surveillance?

<articmine> Bitcoin has become the latter, Monero is still the former.

<sashimi.:matrix.org> while i dont really have the knowledge to fully understand those github threads

<sashimi.:matrix.org> the 1 piconero fee, i would think is "in favor of" p2p digital cash, at it would keep it low in fee to transact even with a price increase (still able to buy the daily coffee or whatever for less then $0.01)

<sashimi.:matrix.org> is the whole "flex space" thing is what literally happened to bitcoin tho?

<sashimi.:matrix.org> setting a fix blocksize limit (which in that case then yea, totally against p2p digital cash) and then some increase of it over the years type thing? if so then yea, dont like that lol

<articmine> The flex space is very similar to one of the proposals in Bitcoin

<monero.arbo:matrix.org> I'm reading your posts now Arctic and with respect, can you explain the reason why it must be 2x and can't be 1.7x?

<monero.arbo:matrix.org> (on 44)

<articmine> @monero.arbo:matrix.org: Because we have to allow scaling over a 3 to 6 month period that is at least comparable to what has occurred in Monero and other similar coins in the past

<monero.arbo:matrix.org> do we?

<articmine> There is of course also the issue of a death by a thousand cuts. We used to have no restrictions on scaling the short term median. The sky did not fall. Quite the opposite.

<monero.arbo:matrix.org> I don't think the network can handle 20x or 100x transactions in a 12-18 month period, even if scaling parameters allow it

<articmine> @monero.arbo:matrix.org: Why? Because of rot in the code?

<monero.arbo:matrix.org> which means, imo, scaling parameters shouldn't allow it. A short term fee market is more than acceptable, it's preferable

<monero.arbo:matrix.org> because FCMP transactions are really heavy in terms of compute requirements, and 100x would imply 2,000,000 transactions per day

<monero.arbo:matrix.org> 2 million

<monero.arbo:matrix.org> like be for real, he network would fall apart under that load. or more likely, miners would have to produce smaller blocks even though the consensus would let them go bigger

<monero.arbo:matrix.org> but tons of peers would fall behind, unable to sync

<articmine> Then we should stay with RingCT until we are ready

<monero.arbo:matrix.org> maybe, I've been worried about the heaviness of fcmp transactions for awhile, but trying to allow 100x or even 20x scaling from current transaction volume over the course of just a few months is putting our own head in the noose

<monero.arbo:matrix.org> even Ethereum only does like 1.5 million per day

<articmine> @monero.arbo:matrix.org: ... and breaks blockchain surveillance with little if any privacy

<articmine> We can be prudent about this HF if we need to.

<articmine> We do not have to rush into FCMP++ before we are ready.

<monero.arbo:matrix.org> my understanding of Monero scaling has been thus: Long term, blocks should grow with demand. Short term, demand can outpace scaling parameters and create a temporary (e.g. until scaling catches up) fee market. I think growing the blockspace slowly is important to the stability of the network. It doesn't seem to me that it dema [... too long, see mrelay.p2pool.observer/e/uqbmgcsKamVDTXdk ]

<boog900> the scaling today on RingCT is too aggressive

<monero.arbo:matrix.org> I agree

<boog900> sticking with it is not a solution

<articmine> When demand has been suppressed for a decade, what happens if the suppression is removed?

<articmine> Do we suppress ourselves?

<boog900> yes

<boog900> staying alive ? dying

<monero.arbo:matrix.org> @articmine: enough to keep the network running smoothly, yes

<articmine> No caving in to the BS industry

<articmine> Bitcoin is dying

<monero.arbo:matrix.org> what use is 100x growth if it becomes unusable

<monero.arbo:matrix.org> I understand the concern but we're just talking about practical limits of what's possible

<articmine> What use is Bitcoin?

<monero.arbo:matrix.org> well I find a lot of use for Bitcoin but that's neither here nor there

<articmine> What is the use

<articmine> Case?

<monero.arbo:matrix.org> on and off ramping, mostly. I can onboard people through apps like cashapp, that they already have. that's huge. but it's also kinda beside th epoint

<boog900> My opinion is that the limits should be decided by the limits of the system (at least on the months scale), then we can have spam prevention to stop short term extreme growth upto that limit.

<boog900> not by trying to find how much growth is needed as that can be changed by so many factors

<monero.arbo:matrix.org> that's my take as well

<articmine> @boog900: This is what I proposed and was shot down because of the long term threat to the BS industry

<monero.arbo:matrix.org> you are trying to propose being able to scale up to 100x in 18 months

<monero.arbo:matrix.org> that's so far past the limit of the system

<articmine> I MB in 2008 when the Bitcoin whitepaper was released is like 1GB today

<articmine> Are you saying peer to peer cash is not viable?

<boog900> with current tech in monero onboarding the world is not possible, no

<articmine> Then we cannot be increasing the burden

<boog900> exactly so lets lower the growth rate lol

<articmine> No let's stop the bloat

<monero.arbo:matrix.org> it's not really a bandwidth issue or storage issue imo, at least not primarily. it's a compute issue. have you tried syncing fcmp stressnet yet? > <@articmine> I MB in 2008 when the Bitcoin whitepaper was released is like 1GB today

<boog900> I think the increase in privacy is well worth the decrease is txs per MB

<sashimi.:matrix.org> might not be able to compete to mastercards level (50k/s) but i think visa levels (3k/s) should be able to

<sashimi.:matrix.org> i dont remember numbers from the stresstests a long while ago for monero, was it 1700/s or something like that? or i completely misremembering there

<articmine> Then FCMP has to wait

<boog900> who is for BS again?

<articmine> What is the point if people cannot use it?

<boog900> people can

<boog900> just like with RingCT the whole world can't

<testtank:matrix.org> Artic , if monero isn’t used by half the population and doesn’t have 10 millions daily transaction, it doesn’t mean that it failed, monero is already sucessfull it has just to stay alive for the people who need to use it

<articmine> @boog900: ... But you agree it is lightrt

<monero.arbo:matrix.org> yeah if we get too successful I don't see how we avoid needing a level 2. the blockchain trilemma still exists

<articmine> Lighter

<monero.arbo:matrix.org> @articmine: for sure, it's a question of tradeoffs, we all get that

<articmine> BS cannot scale at all

<boog900> @articmine: absolutely, but FCMP doesn't take us to our limit with current tx rates, we still have a lot of growth that we can do

<articmine> So we are better off staying with RingCT

<monero.arbo:matrix.org> @boog900: yup, and FCMP scaling will get better with time. even with zero optimizations, hardware continues to get more powerful and more widely available. but we still need to be cognizant of near term limitations

<boog900> @articmine: why? we have capacity to grow with FCMP still

<monero.arbo:matrix.org> @articmine: if you want to prioritize maximum room for growth, then yes, and we should also decrease the ring count for that matter

<monero.arbo:matrix.org> again, it's a question of tradeoffs

<boog900> fuck it ring size 1

<redsh4de:matrix.org> @boog900: Isn't it possible to reduce TX sizes in the future for FCMP++ with Curve Forests as well? 60% reduction in proof size + verification speed ups by 2-3x or something

<redsh4de:matrix.org> And Bulletproofs++ (instead of +) can reduce current BP proof sizes by 38%

<boog900> back to ring sigs instead of ringCT ...

<articmine> The prudent course of action is to stay where we are and focus bon code optimization instead

<monero.arbo:matrix.org> @boog900: fuck it let's just go fully transparent like BTC for maximum scaling

<monero.arbo:matrix.org> cashfusion is good enough

<boog900> @monero.arbo:matrix.org: why decentralization? centralization allows more growth

<articmine> We have decent privacy where we are now

<articmine> We are better off privacy wise scaling what we have

<sashimi.:matrix.org> (just for the record, the p2p market i have in mind to onboard, which would still take a long long while to do so, would probably be at best 0.5tx/s if fully onboarding it, which pretty much monero already can do that and would be able to do that with fcmps too as of right now, but that market itself could also grow overtime, it's still years away regardless anyways)

<boog900> @articmine:monero.social: I would agree with you if FCMP took us right to the limit or close to it with current tx rates, but it doesn't.

<articmine> ... but current tx rates are the result of external suppression

<monero.arbo:matrix.org> I wonder if you could do like HCMP (half chain) or even less and be more efficient, hmmm

<hardhatter> > <@boog900> just like with RingCT the whole world can't

<hardhatter> Currently there’s no immediate need for that level of capacity for monero, but splitting the networks into separate instances of the currency for separate consensus would also work if there’s there enough demand to resort to that and if there’s no clear approach to improve efficiency or hardware capacity on a monolithic consensus model at the time

<boog900> @articmine: yeah and what says that without suppression RingCT is too heavy and we need to go the ring sigs?

<articmine> Yes an option FCMP with limited scaling is an option

<articmine> As an opt in

<articmine> @boog900: This has not been proven

<boog900> @articmine: EXACTLY

<boog900> neither has FCMP being too heavy with no suppression

<boog900> we are talking about made up scenarios that fits exactly into your argument

<articmine> @boog900: So why bake in the suppression into the consensus

<monero.arbo:matrix.org> Right now is about the "lightest" Monero has ever been relative to "current" hardware. We definitely have room, if that's the metric.

<hardhatter> @Lyza what are you disagreeing with? Not having an immediate need? Cause clearly a centralized consensus is a technical bottleneck. I’m not saying splitting consensus is ideal. It’s just obviously going to increase throughput

<monero.arbo:matrix.org> @articmine: because scaling is limited by reality and some of us want the scaling model to stay within the bounds of reality

<boog900> @articmine: we are allowing growth ....

<monero.arbo:matrix.org> otherwise fuck it, unlimited block size

<sashimi.:matrix.org> @monero.arbo:matrix.org: what are the current numbers right now for ringCT and FCMPs that are "within the bounds of reality"?

<monero.arbo:matrix.org> @hardhatter: splitting the network is one of the things we'd most like to avoid. it's not good for anyone

<articmine> @monero.arbo:matrix.org: At least this allows the market to deal with it

<hardhatter> @monero.arbo:matrix.org: I agree with that. That’s why said if “we had to resort to it”

<monero.arbo:matrix.org> @sashimi.:matrix.org: well, judging by my experience with FCMP stressnet, whatever transactions per day they've been doing (idk off the top of my head) is butting up against the limit. People are syncing 2 or 3 blocks per minute on typical hardware

<articmine> We do not have consensus for change so we stay as we are

<articmine> When we get consensus then we change

<monero.arbo:matrix.org> @articmine: I mean, we've never let one person block consensus and I don't think we would now. what are are doing right now is trying to come to consensus, so fi you could participate in that instead of basically saying "my way or nothing" that would be great

<boog900> I think we can move if everyone agrees but 1 person

<quadriocellata:matrix.org> wouldn't it be wise to bake in suppression to what is feasible with current hardware? to allow growth but not uncapped growth ? > <@articmine> So why bake in the suppression into the consensus

<articmine> @quadriocellata:matrix.org: You mean like Bitcoin

<boog900> FCMP will be the biggest upgrade to monero in a while, preventing it because it doesn't allow growth you think is acceptable is silly. What makes your numbers so special?

<redsh4de:matrix.org> As an outside observer, i see both sides of the argument. Scaling is very important, but i also think there is no need to delay privacy tech FCMP++ and Carrot further right when we are at the finish line.

<redsh4de:matrix.org> Yes, at the moment we cannot scale to global scale. And that should absolutely be worked towards, but Monero currently does not have that demand or usage - and likely wont for the next few years until we at least have easier onramp methods and accessibility.

<redsh4de:matrix.org> We’ll still have room to scale and reduce TX sizes afterward by upgrading proof systems to more efficient ones (Curve Forests, BP++, or whatever comes next) and by adjusting protocol parameters. None of that requires delaying FCMP++ today.[... more lines follow, see mrelay.p2pool.observer/e/9tHpgssKVjRyXzdz ]

<quadriocellata:matrix.org> @articmine: it doesn't have to be that capped, but we have to work within the limitations until things catch up ? wouldn't we have a big problem if the growth became too high ?

<articmine> @boog900: There has been no growth in like 6 years

<monero.arbo:matrix.org> @articmine: yes, we are making the same tradeoffs ass bitcoin. We made different tradeoffs, yes, but it's the same dilemme. or trilemme if you will. Monero is heavier than Bitcoin, that's just how it is, but we still have to work within reality

<boog900> @articmine: yeah and what if we get 1000000x growth tomorrow?

<articmine> @boog900: We don't have that

<quadriocellata:matrix.org> you should imagine there would be consensus in the future to allow further growth when the hardware etc catches up

<sashimi.:matrix.org> @boog900: consensus as of right now is the few devs over the ccs that have a voice for consensus

<sashimi.:matrix.org> while not every voice should matter, miners and whales imo should be able to have a voice (whatever the weight of that voice) regarding drastic changes to the protocol

<testtank:matrix.org> @articmine: How do you know?

<boog900> predicting the future is impossible so its not like you know what will happen if monero gets listed on exchanges again or whatever

<articmine> @quadriocellata:matrix.org: No. Vested interests get in the way

<monero.arbo:matrix.org> @sashimi.:matrix.org: more people will chime in as changes inch towards release. people who are choosing not to participate now will still have time to push back

<articmine> We have users

<articmine> We have the silent majority

<boog900> I am happy to listen to good arguments, but creating hypothetical futures where the growth is perfect for ringCT, not too much, but too much for FCMP is not a good argument.

<boog900> when that future is just a hypothetical

<articmine> While we argue the goalposts are changing in our favor

<articmine> So prudence here makes a lot y sense

<articmine> We don't have to rush into this

<boog900> exactly why we are here talking

<boog900> but you haven't managed to convince me we are going to grow into that perfect zone

<testtank:matrix.org> I find it funny, that you would prefer delaying FCMP++, which would basically make monero 100% safe from blockchain survilance companies, rather then not using your scaling params, because the BS companies would “win”

<monero.arbo:matrix.org> @testtank:matrix.org: there is some merit to the concern that if most transactions happen on centralized ledgers (e.g. exchanges and other companies) than the on chain privacy is much less effective

<monero.arbo:matrix.org> but I agree

<testtank:matrix.org> @monero.arbo:matrix.org: Unfortunately/fortunately (depends on who you ask) i don’t think we have to worry about xmr being listed on CEX’s

<sashimi.:matrix.org> @sgp_:monero.social: thanks for joining the conversation, your github thread: monero-project/research-lab #152 is what's being discussed rn i guess

<redsh4de:matrix.org> @testtank:matrix.org: Im assuming the argument is that if in the future the demand increases to high levels for Monero but it doesnt scale well to demand, that would be good for blockchain surveillance companies - layer 2s and other centralized things can come into play

<redsh4de:matrix.org> I guess it boils down to this: In what time horizon do we believe Monero usage and demand would increase to such levels where scaling becomes important

<redsh4de:matrix.org> I personally think that we have a lot of other things to figure out before increased demand and thus scaling becomes a problem - onramp, accessibility, surpression etc. Since that gives time to scale after, privacy improvements should be prioritized.[... more lines follow, see mrelay.p2pool.observer/e/1ZiXg8sKUFBYVTBK ]

<sgp_> ArticMine if blockchain surveillance is as terrible as you say, why shouldn't Monero drop all the privacy tech, make transactions bitcoin-like and efficient, while keeping a generous growing block size to promote capacity? What's your argument against that if capacity is king?

<sgp_> Why let privacy slow us down at all, accepting that view?

<articmine> @sgp_: There is actually a case for privacy by growth

<sgp_> So privacy is important because it induces demand?

<articmine> One gets privacy as a result of growth

<sgp_> @articmine: Right so accepting that, why not go 100% on efficiency and growth? Drop FCMP and ringct

<articmine> There are tradeoffs

<monero.arbo:matrix.org> ArcticMine can we agree that short-medium term growth should be bounded by some kind of reasoned analysis of what the network can handle and what the effect on users might be at more/less aggressive growth rates?

<articmine> @monero.arbo:matrix.org: One can let the market deal with this.

<articmine> Better than a hard coded limit

<monero.arbo:matrix.org> How can the market deal with node hardware requirements?

<articmine> Node limit relay

<boog900> you can't allow the market to deal with consensus rules

<boog900> thats how you get chain splits

<hardhatter> > <@monero.arbo:matrix.org> there is some merit to the concern that if most transactions happen on centralized ledgers (e.g. exchanges and other companies) than the on chain privacy is much less effective

<hardhatter> What’s the deanonymizing attack vector if a large enough minority of on chain transactions are not from colluding entities for FCMP++? I was under the impression the possible signers that could be inferred in that case would reduce to transactions signed by non-colluding entities presently on the chain so far

<testtank:matrix.org> mrelay.p2pool.observer/m/matrix.org/uRjSpbBkzaVNyAIaARWHEXlL.jpeg (90a429d4-af24-4beb-bb05-a38c06cad027.jpeg)

<articmine> @hardhatter: Shared secrets

<boog900> @boog900: which allow double spends FWIW

<monero.arbo:matrix.org> @hardhatter: they'll just literally have their own records, makes things like amount correlations and timing attacks infinitely easier. it's nothing really to do with chain security at that point

<hardhatter> @monero.arbo:matrix.org: Oh good

<sgp_> Fwiw I definitely don't support dropping FCMP, I just see it as a way preferable solution to privacy than trying to outrun the bounds of what can be analyzed by volume

<hardhatter> There’s more manageable approaches to deal with timing and correlation attacks in that case

<sashimi.:matrix.org> @sgp_: fwiw delaying dont mean dropping

<sgp_> I don't think anyone besides ArticMine would be sad if we cut their max growth rate by 90% tbh

<monero.arbo:matrix.org> Is there anyone present with enough knowledge to know if FCMP is all or nothing? e.g. can we have "half" chain membership proofs and gain anything from it?

<boog900> @monero.arbo:matrix.org: even if this allowed us to reach @articmine:monero.social's numbers why does it matter?

<boog900> they arn't special

<kayabanerve:matrix.org> I am strongly against forgoing required technological progress for the idea of scaling. As a comparison, Monero may NEED to upgrade to post-quantum cryptography in the next few years, which will likely have much larger proofs. We will not have the ability to forgo that out of preference and will have to accept the limitations of our technology and the impact on scaling.

<kayabanerve:matrix.org> It's with that in mind we must turn to technology for more efficient solutions, whether on the protocol level with our proofs, or on the implementation level with all the great work the stressnet has done.

<sgp_> Personally I always value security and privacy above scaling. Scaling comes a distant third to me

<kayabanerve:matrix.org> As for if complete membership privacy is 'necessary'... obviously? There's more than enough issues with rings.

<articmine> @sgp_: N!/((N-K)!K!)). Is not order of K

<kayabanerve:matrix.org> Also, @jberman:monero.social: with a few weeks of review and myself with a couple days of work off of that reduced the memory use by 5x, and we already have a known ECC solution for effectively constant membership proof size (w.r.t. amount of inputs).

<sgp_> It's more important to get privacy right than to try to compete with Visa's scale

<articmine> @sgp_: Actually no

<monero.arbo:matrix.org> @boog900: I just like to know what the options / tradeoffs are, and I do have a concern with how heavy fcmp is on testnet

<articmine> The binomial coefficient does not scale lineraly

<articmine> @kayabanerve:matrix.org: My point is give this a chance frst

<sashimi.:matrix.org> @sgp_: visa scales would increase the pool of users which is shared with fcmps so more users also means more privacy there

<sashimi.:matrix.org> but i agree with kaya, those are changes that needs to be made eventually

<sashimi.:matrix.org> it just sucks that the tech itself is not there yet, but it is how it is i guess

<articmine> We do not have to rush

<kayabanerve:matrix.org> Give what a chance? We already put in the work on reducing memory and already have a stable candidate in combination with the necessary fixes to monerod itself

<monero.arbo:matrix.org> I wouldn't say we are rushing

<monero.arbo:matrix.org> nobody even set a date

<kayabanerve:matrix.org> The entire stressnet is taking our time and ensuring stability, without rushing it.

<hardhatter> Isn’t there a reasonable point at which the timeframe/block length is large enough to where it’s likely there’s atleast enough transactions from non-colluding entities within it to be reasonably secure? > <@kayabanerve:matrix.org> As for if complete membership privacy is 'necessary'... obviously? There's more than enough issues with rings.

<kayabanerve:matrix.org> yeah, I'd say the entire blockchain @hardhatter:monero.social would be fine

<kayabanerve:matrix.org> :p

<hardhatter> I mean genuinely do you think that?

<articmine> @kayabanerve:matrix.org: Even if there is a miniscule number of outputs

<sgp_> Another question is if you think ringct is good enough rn

<sgp_> Because that's what it is

<kayabanerve:matrix.org> Eh, if we had OSPEAD and Seraphis-style rings, we could continue playing the cat and mouse game where we can say it may be 'decent' but we'll still have targeted attacks and can never know for sure.

<kayabanerve:matrix.org> But that's the issue. It's never actually private to my standards. It's just 'fine' if you aren't targeted. That shouldn't be the promise nor the goal of Monero.

<hardhatter> @sgp_: I mean ringct has a dramatically smaller number of possible signers though for each transaction?

<articmine> @kayabanerve:matrix.org: Surveillance scales with order of a^k vs k for the chain itself

<sashimi.:matrix.org> @sgp_: ringct overstayed its welcome at this point, considering triptych was a thing being considered at one point, fcmp just has to come out eventually

<sgp_> @hardhatter: For targeted, it doesn't matter much even if you 10x or 100x

<kayabanerve:matrix.org> I think the best argument for scaling is layer twos and am disappointed the current discussion is on trying to place everyone's transactions onto each individual's device (n -> 1) instead of distributed solutions FWIW.

<monero.arbo:matrix.org> I concur the eventual need for L2s seems to come with success

<hardhatter> @sgp_: I mean I’m just asking if there’s a limit where it’s enough. If 100x isn’t enough then sure it’s not enough. Is there a point where it is?

<kayabanerve:matrix.org> @articmine:monero.social: There's been research into churning and it continues the cat and mouse game I described above. Why should we bicker about exactly how bad the privacy is (fine or not), when there's known fundamental attacks regardless?

<articmine> Banking is a layer 2

<sgp_> @hardhatter: Not really unfortunately, unless you lower your standards to not protect targeted

<kayabanerve:matrix.org> A centralized, trusted L2 when using succinct proofs, we could have a L2 with the same security and decentralization as the L1.

<articmine> So a trusted bank?

<hardhatter> @sgp_: I see, that’s unfortunate for scaling then

<sashimi.:matrix.org> @kayabanerve:matrix.org: MoNet:

<sashimi.:matrix.org> eprint.iacr.org/2022/744

<sashimi.:matrix.org> Grease:

<sashimi.:matrix.org> github.com/grease-xmr/grease

<sashimi.:matrix.org> (just for context, dont mind me lol)

<kayabanerve:matrix.org> It's unfortunate for this notion and discussion on scaling @hardhatter:monero.social:

<sgp_> Scaling has many more options than just txs on the chain itself

<articmine> @sgp_: You have to find targeted first

<hardhatter> @kayabanerve:matrix.org: I’m not one of the scaling bulls in this discussion haha But it still matters

<articmine> By the way finding targeted is the fundamental reason blockchain surveillance doi not scale

<sashimi.:matrix.org> @articmine: i mean, centralized exchanges can be considered "L2" at this point... it's all offchain...

<sashimi.:matrix.org> am sure those people at blockchain surveillance companies would love to shill that type of L2 😹

<articmine> @sashimi.:matrix.org: Of course which is why restrictions t scaling layer 1 are paramount for blockchain surveillance

<hardhatter> @sgp_: Okay I see your point but then we’ll need guidelines for off chain privacy for people, so that leveraging more guaranteed privacy on chain remains effective between the two

<kayabanerve:matrix.org> Or creating L2s with equivalent properties to the L1?

<sashimi.:matrix.org> ^ that would be the proper way to have L2 imo

<articmine> @kayabanerve:matrix.org: How is this even theoretically possible?

<sashimi.:matrix.org> @articmine: eprint.iacr.org/2022/744

<sashimi.:matrix.org> github.com/grease-xmr/grease

<kayabanerve:matrix.org> ... that's the entire point of L2 theory?

<kayabanerve:matrix.org> You can create a succinct proof of the state of a network allowing verification, and enforcement, of it without processing it itself

<hardhatter> @kayabanerve:matrix.org: L2s with equivalent properties wouldn’t have the same scaling problems? Since my reply was to sgp’s suggestion that off chain is the solution to scaling

<kayabanerve:matrix.org> It removes the computational burden from the L1

<kayabanerve:matrix.org> Then there's solely the data burden, which is not only easier to handle when you just have to build a solution specifically for archiving data, but potentially also outsourceable

<kayabanerve:matrix.org> See payment channels where the L1 doesn't receive the state, solely the participants

<articmine> The same transaction throughout as the Bitcoin Lighting network? Seriously

<articmine> Define what this transaction rate is, and the required settlement rate on layer 1

<sashimi.:matrix.org> @articmine: bitcoin failed on that imo by having limitation in the code for its L1, literally preventing scaling on L1

<sashimi.:matrix.org> monero could have properly designed L2 without doing the same mistake bitcoin did

<sashimi.:matrix.org> and instead of limitation from the code, it would be just a tech limitation from hardware in case of monero

<redsh4de:matrix.org> Can something like this be done for the L1? So that instead of having to compute every block data, a proof is verified that a block is valid > <@kayabanerve:matrix.org> You can create a succinct proof of the state of a network allowing verification, and enforcement, of it without processing it itself

<redsh4de:matrix.org> Would that have any positive properties beyond loweing the node hardware requirements

<articmine> @sashimi.:matrix.org: A code limitation based upon the tech at a given point in time

<hardhatter> @kayabanerve:matrix.org: Makes sense, but then isn’t this a little too similar to many people’s issue with decentralizing consensus? The L2 is basically a bunch of separate consensus networks. But I get the benefit of still having the L1 there to link them back

<articmine> I am old enough to have programmed using punch cards

<boog900> monero punch card rewrite?

<kayabanerve:matrix.org> @sashimi.:matrix.org: I have an open issue for explicit support of a competent design

<kayabanerve:matrix.org> @redsh4de:matrix.org: This is just scaling the L1 using the same techniques

<sashimi.:matrix.org> @kayabanerve:matrix.org: link?

<kayabanerve:matrix.org> @hardhatter: Not really, as they resolve to the L1 consensus

<kayabanerve:matrix.org> monero-project/research-lab #129

<articmine> Yes now the POS debate

<kayabanerve:matrix.org> @articmine:monero.social: That's a separate discussion

<kayabanerve:matrix.org> Bitcoin obviously has Lightning with PoW

<monero.arbo:matrix.org> it IS annoying to be like, oh are you sending Eth on Eth, are you sending Eth on Poly, are you sending Eth on Optimism? Oh damn my exchange doesn't support Eth on Arbitrium.

<monero.arbo:matrix.org> It's a UX nightmare to have level twos be that sharded, for sure

<kayabanerve:matrix.org> Agree UX can be difficult, though there's extensive work to improve that in the Ethereum eco

<kayabanerve:matrix.org> Just as privacy's UX can be difficult and we've done extensive work there

<monero.arbo:matrix.org> yeah I think we are stuck with L2s (if we're lucky enough to be so successful), I'm just sayin

<rottenwheel:unredacted.org> @testtank:matrix.org: First time? lol

<articmine> Payment channels have been deemed money transmission

<kayabanerve:matrix.org> We cannot fit 7 billion users' transactions onto the devices of each of their users.

<articmine> They can be part of the solution but are not a replacement for level 1 scaling

<kayabanerve:matrix.org> We can fit settlement proofs of 7 billion users' transactions onto the devices of each of those users

<kayabanerve:matrix.org> Yes but the goal of L1 scaling cannot be everything

<kayabanerve:matrix.org> It must be sufficiency

<redsh4de:matrix.org> @articmine: Agree

<kayabanerve:matrix.org> The work we're doing will create a more than sufficient result

<kayabanerve:matrix.org> We shouldn't block L1 progress in the name of the impossible

<articmine> Fair enough. Make it work > <@kayabanerve:matrix.org> We can fit settlement proofs of 7 billion users' transactions onto the devices of each of those users

<lm:matrix.baermail.fr> Jus a interjection: if today BS are making txs on chain to reduce the level of ringct, implementing fcmp would actually decrease current tx/day and make more room for everyone

<articmine> @lm:matrix.baermail.fr: They can try but it doesn't work

<lm:matrix.baermail.fr> @articmine: That was the fear when we had the spam episode

<articmine> There is a lot of FUD regarding spam in Monero

<lm:matrix.baermail.fr> Nothing prevents a BS to do it again, I think that's even why seraphis was abandoned for fcmp++

<sashimi.:matrix.org> spam literally did happen tho, wouldnt consider it just a "FUD" tbh

<articmine> @sashimi.:matrix.org: It stopped at the scaling. This is why the vulnerabilites in the code were not triggered

<boog900> bugs in the wallet was found though

<sashimi.:matrix.org> it stopped but still impacted regular users with their transactions not able to be included in blocks

<sashimi.:matrix.org> if you care about p2p digital cash, best UX possible with less "downtimes" for users is also to keep in mind

<articmine> @boog900: As a result of stress net

<boog900> no

<articmine> So it was fixed

<boog900> in the real spam we had last year (?) wallets were not setting their fee correctly IIRC

<articmine> Yes there was no recommendation

<monero.arbo:matrix.org> not having RBF is really the worst part about Monero having a transaction backlog

<boog900> but the argument was more about how the current tx rate could drop with FCMP, if BS are trickling txs now to try own a lot of the outputs

<monero.arbo:matrix.org> that's how transactions get stuck. "wrong fees" are gonna happen regardless if TX volume is high enough

<articmine> @monero.arbo:matrix.org: If the node relay fees are set properly and the recommendations are set properly this can be fixed

<articmine> It is not even a consensus issue

<boog900> it still prevented prevented scaling as fees were too low

<boog900> and thats a critical issue right?

<boog900> we should have died right?

<articmine> @boog900: It slowed it down.

<articmine> It does not prevent scaling

<boog900> as so slow scaling is ok now?

<monero.arbo:matrix.org> the issue is that you might think a fee is high enough, then after you send the transaction, but before it gets mined, a bunch of new transactions show up in the mempool and your fee is no longer high enough > <@articmine> If the node relay fees are set properly and the recommendations are set properly this can be fixed

<monero.arbo:matrix.org> this can't be fixed with better software

<monero.arbo:matrix.org> you can't see what the future mempool will be

<articmine> What killed Bitcoin is consensus changes to prevent scaling

<articmine> @monero.arbo:matrix.org: This is not a consensus issue

<sashimi.:matrix.org> thought was the other way around

<sashimi.:matrix.org> blocksize limit was added in late 2010 or so

<sashimi.:matrix.org> then the blocksize war happened later, since couldnt get to the consensus of making the actual changes

<sashimi.:matrix.org> so the limit stayed

<monero.arbo:matrix.org> @articmine: right, my point is that consensus can't fix the issue of transactions getting stuck

<articmine> @sashimi.:matrix.org: Which is why consensus limits on scaling are so dangerous

<monero.arbo:matrix.org> right, that's the whole point of having a dynamic block size

<articmine> @monero.arbo:matrix.org: Exactly

<monero.arbo:matrix.org> but we're talking about short term limits within that dynamic system

<sashimi.:matrix.org> @monero.arbo:matrix.org: for bitcoin it was supposed to be temporary as well, short term to prevent spam

<articmine> We are talking about long term consensus rules

<sashimi.:matrix.org> i guess point is that, when limit is introduced then it will be harder later on to get consensus to remove the limit

<hardhatter> I mean overall I agree with you about this and with why it’s useful to have the L1 there to further secure the consensus done on networks on the L2 > <@kayabanerve:matrix.org> Not really, as they resolve to the L1 consensus

<hardhatter> but some individual L2 networks are going to have less secure consensus inherently due to their smaller size before it reaches the L1. I don’t really have any problem this. People just need to be cognizant of the risks. But I think there are people who will have a problem conceptually with this.

<hardhatter> Personally I think the level of decentralized consensus here is very similar to what some people have a problem with (i don’t necessarily). But consensus additionally resolving back to L1 greatly improves stability of the L2 economy.

<monero.arbo:matrix.org> @sashimi.:matrix.org: not the same sort of "temporary" --- the argument is about how fast to let scaling happen. literally nobody is arguing for BTC style hard limits

<articmine> @sashimi.:matrix.org: So one fights the introduction of the limit into consensus in the first place

<hardhatter> Do we have any models about how the L1 will scale relative to the L2 in with this set up? Cause that might still end up being a problem down the line?

silent majority here :) I agree with the perspectives presented by monero.arbo , boog900 and others and believe that they understand the valid points made by articmine

<sashimi.:matrix.org> @monero.arbo:matrix.org: then yall math guys need to get some actual numbers and figure what those limitations are

<sashimi.:matrix.org> today's discussion didnt have much numbers...

<kayabanerve:matrix.org> @hardhatter:monero.social: I don't think you understand how consensus works with a proper L2. Its consensus _is_ the L1's.

<kayabanerve:matrix.org> Eh, if we had OSPEAD and Seraphis-style rings, we could continue playing the cat and mouse game where we can say it may be 'decent' but we'll still have targeted attacks and can never know for sure.

<kayabanerve:matrix.org> But that's the issue. It's never actually private to my standards. It's just 'fine' if you aren't targeted. That shouldn't be the promise nor the goal of Monero.

thumbup ^^

<monero.arbo:matrix.org> @sashimi.:matrix.org: For sure, analysis would be extremely good to do/have, but also hard to do when fcmp is changing so fast.

<rottenwheel:unredacted.org> speaking of L2, what's the status of the L2 announced by... Idk who anymore at MoneroKon 5?

<monero.arbo:matrix.org> a lot of optimizations have been / are being made still

<rottenwheel:unredacted.org> where are these great fellows? are they in this room?

this, rottenwheel? github.com/grease-xmr/grease

<rottenwheel:unredacted.org> DataHoarder: correct! grease!

<hardhatter> @kayabanerve:matrix.org: yea I might have misunderstood the type of L2 network you’re talking about. I’m not sure exactly which one you have in mind so I made an assumption

<rottenwheel:unredacted.org> apparently neither are on Matrix. :(

<articmine> @monero.arbo:matrix.org: Actually some people have proposed a rigid simple proposal that amounts to the same thing. Even worse if on factors in the proposed difference in transaction weights

<hardhatter> If consensus completely resolved on the L1 a the moment im confused how the bottle neck is adequately resolved. I get there will be some computational burdens lessened but not asymptotically I imagine

<articmine> We cannot ignore the human element here

<monero.arbo:matrix.org> for reference, checking the stressnet channel, seems like we were doing 100k per day there. I have an older quad core laptop that was keeping up but like, idk just 2 or 5 blocks per minute. that's on the latest release, 1.4. just to give a ballpark idea. I recommend everyone taking part in this discussion try it for themselves tbh

<sashimi.:matrix.org> @hardhatter: i think: monero-project/research-lab #129

<sashimi.:matrix.org> is too techy for me so i cant speak on that, but that might have been what he's been talking about

<hardhatter> Ahh yea I should’ve checked that link he sent thanks

<articmine> @monero.arbo:matrix.org: 100k on FCMP?

<monero.arbo:matrix.org> @articmine: according to you (:

<monero.arbo:matrix.org> I never checked the numbers but it's what you had said at some point

<monero.arbo:matrix.org> err, sorry ofrnxmr said that

<monero.arbo:matrix.org> my bad

<ofrnxmr> 100k tx/day?

<monero.arbo:matrix.org> yes

<articmine> Yes like 4x current

<ofrnxmr> And more, yea

<ofrnxmr> probably got well over 500k (700 tx/block)

<monero.arbo:matrix.org> nice, but yeah, my experience with testnet is that feels like it's near the limit for current consumer hardware. and if anyone hasn't tried syncing it themselves, please do

<articmine> so like 6 NB

<articmine> MB

<ofrnxmr> The reported block sized are not right on current stressnet (sum of txs is less than reported block size)

<ofrnxmr> So im not actually sure the real block size

<articmine> 500 K transactions per day is like 25x. the current rate

<monero.arbo:matrix.org> yes

<articmine> So I am not that far off after all

<monero.arbo:matrix.org> I would be okay with growing fast up to that point, then slowing growth beyond that significantly

<monero.arbo:matrix.org> or you know, "about" that point

<articmine> @monero.arbo:matrix.org: In consensus this becomes a real problem

<monero.arbo:matrix.org> but understand that some nodes are already going to be falling off the network at 500k per day, or become unviable to sync

^ poor recent released RPI 4 / 5

<articmine> They have time to adjust

<monero.arbo:matrix.org> It's not just "adjusting" some people have limited hardware availability and imo they matter too

<articmine> @monero.arbo:matrix.org: They NB need to consider alternatives

<articmine> Need*

ofrnxmr what are the # of inputs for the txs on stressnet, are they the 128 input ones or a mix?

<monero.arbo:matrix.org> @articmine: this type of thing (hgih hardware requirements) are exactly the sort of thing that pushed people towards the centralized solutions you are so against

<articmine> @monero.arbo:matrix.org: No I have to disagree here

<monero.arbo:matrix.org> It's why I don't run my own Ethereum node, I'll tell ya that much

<articmine> That is the excuse that was used in Bitcoin

<articmine> @monero.arbo:matrix.org: What is preventing you!

<ofrnxmr> nioc: For the 100k numbers? Mostly 1 or 2 input

thx

<ofrnxmr> Doubt that. We have 2gb ram nodes syncing fine > <@monero.arbo:matrix.org> but understand that some nodes are already going to be falling off the network at 500k per day, or become unviable to sync

<monero.arbo:matrix.org> @articmine: hardware and bandwidth requirements. even though I technically could do it. and I'm an enthusiast who runs nodes for like, 3 or 4 different networks. and uses Ethereum!!

<articmine> What bandwidth requirements?

<ofrnxmr> ethereum nodes have like a 16gb ram min or recommended requirement, dont they?

<monero.arbo:matrix.org> I'm just one person, but to say hardware requirements don't push users away from running their own node is just on it's face untrue

<ofrnxmr> @monero.arbo:matrix.org: Youre like, making stuff up

<ofrnxmr> you can sync stressnet with 2gb ram

<articmine> Please understand why I have to take a hard line here

<ofrnxmr> Storage is the issue that we'd hit with sustained large volume, so obv we need to deploy an easy-to-use solution to allow splittingtje db across storage mediums

<monero.arbo:matrix.org> @ofrnxmr: bro you know I've been running a stressnet node

<ofrnxmr> so reduce your ram to 2gb and test your theory

<monero.arbo:matrix.org> my primary concern has, for about the third time this conversation, been compute requirements

<ofrnxmr> Reduce your vcpus to 4 and test your theory

<monero.arbo:matrix.org> I'm running it on a 4-core laptop and can see the performance with my own eyes sir

<ofrnxmr> Oh, you're having problems staying in syns?

<ofrnxmr> Sync*

<articmine> @monero.arbo:matrix.org: Which will easily be addressed with an increase in the price of Monero

<ofrnxmr> I havent seen you report any issues sar

<monero.arbo:matrix.org> @ofrnxmr: Not at all, I was saying in my original comment that I have been syncing 2-5 blocks per minute

<articmine> Seriously a 20x increase in on chain adoption will impact the price

<ofrnxmr> At what block sizes?

<monero.arbo:matrix.org> I was literally just trying to give people an idea of where performance is currently at with fcmp

<monero.arbo:matrix.org> @ofrnxmr: at whatever they've been, that's why I was asking

<ofrnxmr> Your idea is false thiugh! The speed is similar to ringct

<monero.arbo:matrix.org> ok? that's neither here nor there

<monero.arbo:matrix.org> I literally just said, hey, this is how fast I sync at this TX volume with fcmp on my laptop. you're reading so much into my comments that I did not say

<articmine> Anyway I have to leave for now

<ofrnxmr> its not some new problem. What is a new problem, is that sync with checkpoints is slowed

<ofrnxmr> Also, if you have more than 4cores, use --prep-blocks-threads=$(nproc) to greatly increase sync speed

<ofrnxmr> @ofrnxmr: Only works w/o checkpoints

<monero.arbo:matrix.org> I intentionally used this laptop to see how it performs on average to below average hardware

<monero.arbo:matrix.org> because I think that's important

<ofrnxmr> what are the specs that you're running with

<monero.arbo:matrix.org> oof hold on let me look

<monero.arbo:matrix.org> it's a 10th gen i5 with like, 32 GB of RAM

<monero.arbo:matrix.org> The people I'm thinking of downloaded the GUI from getmonero.org and open it up, maybe once a month, maybe once every 3 months, and they used to default option to run their own node, so they have to catch up the sync every time they open their wallet.

<monero.arbo:matrix.org> And if that's not how we want people to use Monero anymore, well we need to stop channeling people down that path

<ofrnxmr> Blocks are currently 300kb

<ofrnxmr> @ofrnxmr: On stressnet.

<ofrnxmr> 1. Start your monerod with --offline

<ofrnxmr> 2. flush_txpool

<ofrnxmr> 3. pop_blocks 100[... more lines follow, see mrelay.p2pool.observer/e/muK7hssKTkV6TTFY ]

<monero.arbo:matrix.org> It's a couple weeks behind rn tbh but I can fire it up

<monero.arbo:matrix.org> we can also move to the #monero-stressnet:monero.social channel for this if you want

<gingeropolous> i need to dive into these github threads or something because i really don't get what the issue is. From reading through this conversation everyone seems to agree that we need a dynamic block size that has the two tier mechanism - a shorter term dynamic cap and then a longer term one (that will ultimately increase the shorter term one). I need graphs and stuff.

<ofrnxmr> Spackle has graphs

<gingeropolous> from my perspective we can get the numbers on what our current hardware can do, and adjust the scaling parameters accordingly. It might even be worthwhile to bake in some optimism re: tech advancement, just like a 2% increase in whatever parameter per year

<gingeropolous> i recent got my old core2 quad up and running again....

<articmine> @gingeropolous: This is not entirely true. There is at least one person who is opposed

<articmine> Opposed to the adaptive blocksize

<articmine> When I say opposed, I mean opposed to everything Monero has done in this area going back to the Monero genesis block in 2014and furthermore to the scaling specification in the Cryptonote whitepaper

<articmine> This is why this was also an issue ahead of the last hard fork

<articmine> The proof of the above lies in this simple proposal.

<monero.arbo:matrix.org> that poposal doesn't seem to have any traction as far as I can tell

<articmine> For good reason.

<articmine> ... but that doesn't stop the proponent from lobbying behind the scenes

<articmine> I went through all of this before ahead of the last hard fork

<articmine> unbekoming.substack.com/p/hijacking-bitcoin-the-hidden-history

<articmine> We must keep in mind that there are serious economic interests to the tune of billions of US dollars at stake here for the blockchain surveillance industry

<pubertus:matrix.org> technically a sidechain. and this is needed either way for defi. > <@monero.arbo:matrix.org> yeah if we get too successful I don't see how we avoid needing a level 2. the blockchain trilemma still exists

<pubertus:matrix.org> an L2 would bloat the L1 which is obviously not something anyone wants.

<articmine> I am actually working on an analysis of the impact of scaling on blockchain surveillance (BS).

<articmine> My preliminary assessment is that scaling is really bad for blockchain surveillance. So I can really see the incentives here

<pubertus:matrix.org> how do you want to ensure users of an L2 always have the escape hatchet to the L1 in case the L1 stops? > <@kayabanerve:matrix.org> I think the best argument for scaling is layer twos and am disappointed the current discussion is on trying to place everyone's transactions onto each individual's device (n -> 1) instead of distributed solutions FWIW.

<pubertus:matrix.org> how do you want to ensure users of an L2 always have the escape hatchet to the L1 in case the L2 stops? > <@kayabanerve:matrix.org> I think the best argument for scaling is layer twos and am disappointed the current discussion is on trying to place everyone's transactions onto each individual's device (n -> 1) instead of distributed solutions FWIW.

<articmine> @pubertus:matrix.org: This is why Bitcoin Lighting has failed. A good L2 does not replace the L1 . It complements and enhances the L1

<pubertus:matrix.org> @articmine: yes. we have the privacy. now we need to get XMR into defi. and looking at the regulatory frameworks being prepared for us (CARF, MiCA, etc), we can see what it will need to look like long-term.

<pubertus:matrix.org> the current regulations for centralized exchanges etc. will start transferring to dexes eventually. and chains. making also chains compliant.

<pubertus:matrix.org> we can already see that several infras like bridges are implementing various mechanisms.

<pubertus:matrix.org> from this point of view, something like an L2 would be good for Monero's resilience

<gingeropolous> how will xmr benefit from defi?

<sashimi.:matrix.org> "liquidity"