13:13:31 https://github.com/seraphis-migration/monero/issues/44 13:13:56 I do believe we have consensus here. 13:14:27 Correction m 13:19:04 I do not believe we have consensus on the scaling parameters. 13:19:04 We also may have a significant conflict of interest here, given the very radical counter proposal that was presented. 13:22:29 https://github.com/monero-project/research-lab/issues/152 13:26:02 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 13:33:42 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. 13:37:26 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. 13:38:26 This is the most common type of Monero transaction. 13:41:05 Do we really peer to peer cash and privacy or or centralized ledgers and surveillance? 13:43:13 Bitcoin has become the latter, Monero is still the former. 13:46:50 while i dont really have the knowledge to fully understand those github threads 13:46:50 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) 13:46:50 is the whole "flex space" thing is what literally happened to bitcoin tho? 13:46:50 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 13:48:04 The flex space is very similar to one of the proposals in Bitcoin 13:48:53 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? 13:48:57 (on 44) 13:51:29 @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 13:54:02 do we? 13:54:34 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. 13:54:36 I don't think the network can handle 20x or 100x transactions in a 12-18 month period, even if scaling parameters allow it 13:55:11 @monero.arbo:matrix.org: Why? Because of rot in the code? 13:55:12 which means, imo, scaling parameters shouldn't allow it. A short term fee market is more than acceptable, it's preferable 13:55:58 because FCMP transactions are really heavy in terms of compute requirements, and 100x would imply 2,000,000 transactions per day 13:56:00 2 million 13:56:52 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 13:57:08 but tons of peers would fall behind, unable to sync 13:57:22 Then we should stay with RingCT until we are ready 13:58:19 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 13:58:56 even Ethereum only does like 1.5 million per day 13:59:44 @monero.arbo:matrix.org: ... and breaks blockchain surveillance with little if any privacy 14:00:53 We can be prudent about this HF if we need to. 14:01:45 We do not have to rush into FCMP++ before we are ready. 14:03:38 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 https://mrelay.p2pool.observer/e/uqbmgcsKamVDTXdk ] 14:04:37 the scaling today on RingCT is too aggressive 14:04:54 I agree 14:04:57 sticking with it is not a solution 14:05:40 When demand has been suppressed for a decade, what happens if the suppression is removed? 14:06:17 Do we suppress ourselves? 14:06:23 yes 14:06:32 staying alive ? dying 14:07:00 @articmine: enough to keep the network running smoothly, yes 14:07:00 No caving in to the BS industry 14:07:11 Bitcoin is dying 14:07:11 what use is 100x growth if it becomes unusable 14:08:00 I understand the concern but we're just talking about practical limits of what's possible 14:08:02 What use is Bitcoin? 14:08:20 well I find a lot of use for Bitcoin but that's neither here nor there 14:08:38 What is the use 14:09:23 Case? 14:09:24 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 14:09:31 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. 14:10:09 not by trying to find how much growth is needed as that can be changed by so many factors 14:10:23 that's my take as well 14:11:00 @boog900: This is what I proposed and was shot down because of the long term threat to the BS industry 14:11:45 you are trying to propose being able to scale up to 100x in 18 months 14:11:55 that's so far past the limit of the system 14:15:12 I MB in 2008 when the Bitcoin whitepaper was released is like 1GB today 14:16:40 Are you saying peer to peer cash is not viable? 14:17:45 with current tech in monero onboarding the world is not possible, no 14:18:24 Then we cannot be increasing the burden 14:18:45 exactly so lets lower the growth rate lol 14:19:17 No let's stop the bloat 14:19:27 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 14:19:51 I think the increase in privacy is well worth the decrease is txs per MB 14:19:55 might not be able to compete to mastercards level (50k/s) but i think visa levels (3k/s) should be able to 14:19:55 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 14:19:57 Then FCMP has to wait 14:20:27 who is for BS again? 14:20:43 What is the point if people cannot use it? 14:21:02 people can 14:21:13 just like with RingCT the whole world can't 14:21:35 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 14:21:45 @boog900: ... But you agree it is lightrt 14:21:58 yeah if we get too successful I don't see how we avoid needing a level 2. the blockchain trilemma still exists 14:22:00 Lighter 14:22:27 @articmine: for sure, it's a question of tradeoffs, we all get that 14:22:35 BS cannot scale at all 14:22:37 @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 14:23:12 So we are better off staying with RingCT 14:23:29 @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 14:24:05 @articmine: why? we have capacity to grow with FCMP still 14:24:09 @articmine: if you want to prioritize maximum room for growth, then yes, and we should also decrease the ring count for that matter 14:24:10 again, it's a question of tradeoffs 14:24:25 fuck it ring size 1 14:24:27 @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 14:24:27 And Bulletproofs++ (instead of +) can reduce current BP proof sizes by 38% 14:25:01 back to ring sigs instead of ringCT ... 14:25:37 The prudent course of action is to stay where we are and focus bon code optimization instead 14:25:49 @boog900: fuck it let's just go fully transparent like BTC for maximum scaling 14:26:01 cashfusion is good enough 14:26:31 @monero.arbo:matrix.org: why decentralization? centralization allows more growth 14:26:44 We have decent privacy where we are now 14:27:41 We are better off privacy wise scaling what we have 14:27:45 (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) 14:27:55 @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. 14:28:41 ... but current tx rates are the result of external suppression 14:28:58 I wonder if you could do like HCMP (half chain) or even less and be more efficient, hmmm 14:29:14 > <@boog900> just like with RingCT the whole world can't 14:29:14 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 14:29:35 @articmine: yeah and what says that without suppression RingCT is too heavy and we need to go the ring sigs? 14:30:12 Yes an option FCMP with limited scaling is an option 14:30:32 As an opt in 14:31:07 @boog900: This has not been proven 14:31:26 @articmine: EXACTLY 14:31:53 neither has FCMP being too heavy with no suppression 14:32:19 we are talking about made up scenarios that fits exactly into your argument 14:32:43 @boog900: So why bake in the suppression into the consensus 14:32:52 Right now is about the "lightest" Monero has ever been relative to "current" hardware. We definitely have room, if that's the metric. 14:33:20 @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 14:33:23 @articmine: because scaling is limited by reality and some of us want the scaling model to stay within the bounds of reality 14:33:31 @articmine: we are allowing growth .... 14:33:34 otherwise fuck it, unlimited block size 14:34:24 @monero.arbo:matrix.org: what are the current numbers right now for ringCT and FCMPs that are "within the bounds of reality"? 14:34:25 @hardhatter: splitting the network is one of the things we'd most like to avoid. it's not good for anyone 14:34:28 @monero.arbo:matrix.org: At least this allows the market to deal with it 14:35:12 @monero.arbo:matrix.org: I agree with that. That’s why said if “we had to resort to it” 14:35:29 @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 14:35:40 We do not have consensus for change so we stay as we are 14:36:13 When we get consensus then we change 14:36:44 @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 14:36:59 I think we can move if everyone agrees but 1 person 14:37:17 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 14:38:09 @quadriocellata:matrix.org: You mean like Bitcoin 14:39:14 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? 14:39:30 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. 14:39:30 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. 14:39:30 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 https://mrelay.p2pool.observer/e/9tHpgssKVjRyXzdz ] 14:39:47 @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 ? 14:39:59 @boog900: There has been no growth in like 6 years 14:40:13 @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 14:40:24 @articmine: yeah and what if we get 1000000x growth tomorrow? 14:40:44 @boog900: We don't have that 14:40:45 you should imagine there would be consensus in the future to allow further growth when the hardware etc catches up 14:41:06 @boog900: consensus as of right now is the few devs over the ccs that have a voice for consensus 14:41:06 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 14:41:10 @articmine: How do you know? 14:41:14 predicting the future is impossible so its not like you know what will happen if monero gets listed on exchanges again or whatever 14:41:22 @quadriocellata:matrix.org: No. Vested interests get in the way 14:41:47 @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 14:42:25 We have users 14:42:44 We have the silent majority 14:43:02 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. 14:43:28 when that future is just a hypothetical 14:44:27 While we argue the goalposts are changing in our favor 14:45:00 So prudence here makes a lot y sense 14:45:47 We don't have to rush into this 14:46:08 exactly why we are here talking 14:46:32 but you haven't managed to convince me we are going to grow into that perfect zone 14:46:34 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” 14:47:41 @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 14:47:44 but I agree 14:50:56 @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 14:51:00 @sgp_:monero.social: thanks for joining the conversation, your github thread: https://github.com/monero-project/research-lab/issues/152 is what's being discussed rn i guess 14:52:02 @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 14:52:02 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 14:52:02 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 https://mrelay.p2pool.observer/e/1ZiXg8sKUFBYVTBK ] 14:53:20 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? 14:53:43 Why let privacy slow us down at all, accepting that view? 14:55:18 @sgp_: There is actually a case for privacy by growth 14:55:42 So privacy is important because it induces demand? 14:56:21 One gets privacy as a result of growth 14:57:04 @articmine: Right so accepting that, why not go 100% on efficiency and growth? Drop FCMP and ringct 14:57:35 There are tradeoffs 14:58:34 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? 14:59:41 @monero.arbo:matrix.org: One can let the market deal with this. 15:00:04 Better than a hard coded limit 15:00:05 How can the market deal with node hardware requirements? 15:00:32 Node limit relay 15:00:42 you can't allow the market to deal with consensus rules 15:00:50 thats how you get chain splits 15:01:07 > <@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 15:01:07 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 15:01:38 https://mrelay.p2pool.observer/m/matrix.org/uRjSpbBkzaVNyAIaARWHEXlL.jpeg (90a429d4-af24-4beb-bb05-a38c06cad027.jpeg) 15:01:52 @hardhatter: Shared secrets 15:02:00 @boog900: which allow double spends FWIW 15:02:35 @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 15:02:49 @monero.arbo:matrix.org: Oh good 15:03:54 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 15:04:08 There’s more manageable approaches to deal with timing and correlation attacks in that case 15:04:22 @sgp_: fwiw delaying dont mean dropping 15:04:57 I don't think anyone besides ArticMine would be sad if we cut their max growth rate by 90% tbh 15:05:15 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? 15:06:42 @monero.arbo:matrix.org: even if this allowed us to reach @articmine:monero.social's numbers why does it matter? 15:06:55 they arn't special 15:06:56 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. 15:07:39 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. 15:07:57 Personally I always value security and privacy above scaling. Scaling comes a distant third to me 15:07:59 As for if complete membership privacy is 'necessary'... obviously? There's more than enough issues with rings. 15:08:12 @sgp_: N!/((N-K)!K!)). Is not order of K 15:08:56 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). 15:09:22 It's more important to get privacy right than to try to compete with Visa's scale 15:09:38 @sgp_: Actually no 15:09:54 @boog900: I just like to know what the options / tradeoffs are, and I do have a concern with how heavy fcmp is on testnet 15:10:25 The binomial coefficient does not scale lineraly 15:11:11 @kayabanerve:matrix.org: My point is give this a chance frst 15:11:31 @sgp_: visa scales would increase the pool of users which is shared with fcmps so more users also means more privacy there 15:11:31 but i agree with kaya, those are changes that needs to be made eventually 15:11:31