03:10:19 dns patch should be fastest to apply & we shouldn't wait for another attack while a permanent/better solution is found > <@angled:matrix.angled.rip> as in there is a plan to actually implement one of the other non temporary solutions? which one(s)? 03:12:16 @jack_ma_blabla:matrix.org: Wish it was so simple 03:12:36 But the reorg handling was broken (perhaps always has been) and needs a rewrite 03:18:37 the dns patch works and we have the tools. running an active checkpointer can get nodes stuck, effectively, on reorgs, so that must be fixed before using it (see backlog on previous MRL meetings) 07:52:13 https://github.com/monero-project/research-lab/issues/152 07:52:22 doesnt this destroy fee uniformity? 07:57:31 Instead of four fee levels, it adds ~50. I personally think actual fees will cluster around only a few fee levels (depending on market conditions). But.... people are often not rational with fees. Also, different wallets may have detectable bias when it comes to fee selection, so yes, it is likely to hurt fee uniformity in some way. How much it does so is difficult to quantify. 07:59:09 I don't think current fees are governed by consensus at all, but by a gentleman's agreement between most wallets to only use specific fee levels. 07:59:30 Forcing fees to be a power of 2 as a consensus rule is an interesting idea. 08:00:22 @torir:matrix.org: Indeed, on today's chain we still see non-standard fees sometimes. 08:01:54 I think the idea maybe needs to be taken back to the drawing board and properly analyzed for privacy impact and other concerns that were not addressed in the proposal. 08:02:02 "lmao ill have my program use 67 picos as fee so funny" -> all users tagged ✅️ 08:03:53 Having fee levels be a consensus rule is probably not a bad idea, but the flex block space part of the proposal seems to forget that Monero already has a block scaling algorithm in place. 08:05:27 From the proposal: "To add more predictable scaling parameters." 08:05:27 Okay, I suppose the existing algorithm for block space is maybe not very predictable. I guess I just want a comparison of before/after to be able to properly evaluate this proposal. 08:15:04 I don't understand how scaling works presently to understand how this proposal differs. 10:47:45 someone might find it curious, I implemented the low order torsion attack on key image described on https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html as part of the ring signature tests (done on original pre-ringct signatures) 10:47:45 https://git.gammaspectra.live/P2Pool/consensus/commit/19f9d795833a7be71a9145fb95735673224c6fcd 10:49:25 it makes a ring of 3 decoys + 1 spend, verifies it; then attempts to forge the same ring (and private key) except with the key image torsioned by a low order point 10:49:52 it confirms it'd pass verification, if not for the explicit torsion checked Verify method 10:51:42 the test uses deterministic rng to ensure the random tries find a point in the given attempts (given this runs on CI) https://paste.debian.net/hidden/7ee64f03/ 13:35:42 hello 13:35:59 what is the difference between this group and #monero-research-lab? 13:37:41 Research lab is pretty strict about being on-topic, but otherwise they are pretty much the same. 13:39:56 Which chanel should I use to ask my questions about Monero Cryptography? 13:40:15 here 13:40:36 ++ 13:41:16 for general questions, unless you are proposing a change or noticed some issues 13:41:48 no, just studying and learning it 13:57:24 I'm learning xmr cryptography for a while, and I already studied the main part (RingCT, ring sig -MLSAG and LSAG-, stealth addresses, pedersen and rangeproofs etc.), and I wanna study FCMP++ now. 13:57:39 The problem is that I cannot get the intuition from raw maths, and only sources I was able to find were the papers of IACR (Curve Trees, ZKP of EC Inner Products from Principal Divisors etc.) -and some notes from dev github repos-. 13:57:50 My workflow is more about having a main article which simplifies the maths and highlights the intuition, and I bounce between the main article and IACR,MRL papers and codebase whenever I need more accurate informations and to make certain points more clear. 13:58:01 So, is there any articles or explanations about FCMP++ which would give me intuition first, so that I can dive into maths with this intuition? 13:58:15 I'm also open for any cryptography, monero and math workflow recommendations. 14:00:43 Start with how Zero Knowledge proofs work: https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/ this focuses on intuition, but the ZKP used in FCMP is different from the one demonstrated in the article. 14:02:30 ++ 14:48:39 ArticMine look up what firm Edman works for https://bitcoinmagazine.com/news/tornado-cash-trial-defenses-digi-forensics 14:50:38 I was an expert for Pertsev's defense 14:50:40 stop speculating about crap you don't understand 14:52:00 I do understand what is going on here 14:52:19 BS does not scale big time 14:54:45 @articmine:monero.social: so in your opinion monero would be more vulnerable with FCMP and @sgp_:monero.social proposal, than current day RingCT given our tx volumes 14:55:38 Or do you think monero can be traced right not due to our tx volume and RingCT? 14:56:10 Chainalysis did get some tracing to work 14:57:44 The issue is that if the anonymity set is small enough Monero would be vulnerable. 14:57:45 The real attack is forcing moat transactions of chain onto centralized ledgers 14:58:03 This is what has happened with Bitcoin 14:59:11 By the way I was certified in Blockchain Surveillance as part of my work for the defense in the Sterlingov case 14:59:25 @sgp_:monero.social has said the parameters are flexible, what tx volume is enough to avoid blockchain surveillance in your opinion ? 15:00:06 @boog900: Maybe we could start with a base level of transactions per day, right now, to answer that Q 15:00:16 BS has started to have issues at Ethereum scaling rates 15:00:21 (ArticMine's suggestion of what that should be today) 15:01:03 The reality is that the greater the anonymity set the greater the privacy 15:01:32 All of this is dynamic because technology does not stay still 15:02:16 suppose this second, there was a demand for a million Monero transactions per second. What would you want the Monero transaction limit to this second, for Monero not to be a failure in your view? 15:02:32 This is why fixed limits are so dangerous 15:03:04 both your proposals allow infinite growth over enough time 15:03:37 so you would want to fully accommodate the million per second in that example? If Monero only did 500k/second, that would be a failure in your view? Again, let's assume this is today and today's infra costs, not 10, 100, etc years from now 15:04:56 It is not possible to reach those rates today. We both know that 15:05:35 I do see VISA transactions rates as realistic in a decade 15:05:49 Yeah but I mean what would you say is reasonable today, so we have somewhere to start. Assuming infinite demand 15:06:43 @articmine: I can try to work back from this if you want me to, discounting by moore's law 15:06:46 There is no sch thing as infinite demand 15:07:08 You will get my proposal 15:07:42 If you work back from VISA in a decade 15:08:23 yeah give me a sec to do that. I'll work back from 300 billion txs a year 15:08:34 ViSA is about 7000 TPS with a surge factor of ~ 20x 15:09:14 what growth rate per year do you want me to use for moore's law? 50%? 15:09:23 Yes 15:09:52 50% is correct 15:11:50 one moment 15:12:46 https://mrelay.p2pool.observer/m/monero.social/SGxprNVjqqMmPpAuVHDoKGIs.png (image.png) 15:14:47 One has to factor in a 20x surge for holiday shopping 15:15:44 https://mrelay.p2pool.observer/m/monero.social/rfPOyYRsoFJWFgvYsRVyLOiM.png (image.png) 15:15:47 like that? 15:16:28 There is a dev draft of the FCMP++ protocol considered the FCMP++ paper @zarathust 15:16:34 Yes 15:17:00 Ok cool, now we have a baseline :) 15:17:16 The surge will be handled by the 16x in the short term median 15:17:27 @kayabanerve:matrix.org: They left right before you responded 15:17:40 So we are looking at the long term and sanity. Medians 15:19:31 2x maximum growth for the long term median and a factor of 256 to 1024 for the sanity median 15:20:15 The thii to keep in mind is that growth will not be constant 15:21:18 ofrnxmr: :( 15:21:24 Can you remind me how long the long term median is? It's not 1 year right? 15:21:49 100000 blocks 15:22:17 Sanity will be 1000000 blocks 15:22:26 so roughly 138 days 15:22:32 Both grow at 2x 15:26:45 I see 193 MB blocks right now and tbh, I'm quite concerned. Even before the 20x surge feature. And I'm concerned about growth at 2x up to ~2.5x a year, even if it's unlikely to grow as fast as allowed 15:28:06 How do you get 192 MB blocks right now? 15:28:49 that's the value when discounting 10 years of moore's law from Visa levels today 15:28:50 Before the surge? 15:29:09 E2 > <@sgp_> https://mrelay.p2pool.observer/m/monero.social/rfPOyYRsoFJWFgvYsRVyLOiM.png (image.png) 15:30:34 FWIW we cannot handle that with the current code, you will hit serialization limits in the P2P network 15:30:43 even with stressnet changes 15:31:09 I know that's not the number used in your proposal, but it's the implied number that's needed to get to your goal of Visa level throughput in 10 years, growing 50% per year 15:31:49 You are assuming a constant rate of growth 15:32:53 We are also dealing with a priced network 15:33:15 I have to leave now. At least some progress 15:35:08 @boog900: And packet size limits 15:35:55 I don't think any rate of growth makes this possible FWIW 15:36:43 off topic: Boog, do me a fav and poke, prod, nudge 0x to wrap up tx relay 🙃 15:36:50 My point in going through this exercise is to help show why Visa rate isn't achievable, even in 10 years, without some major efficiency gain. And while I want efficiency gains, if we find one, we can always change the scaling again to account for that, rather than committing us to a scaling disaster that needs to be averted 15:37:38 @ofrnxmr:xmr.mx: Please and thank you 15:37:46 @ofrnxmr:xmr.mx: lol I have been meaning to give that another review too :) 15:38:20 It has a bunch of review comments that need to be addresses before merge on stressnet 15:49:38 Re: bandwidth and ECC, Curve Forests would effectively flatten the proof size for membership at the cost of much more notable computation. 15:49:38 Moving into the future, the focus will need to be on delegating work out to users, block builders, and even segments of the network via RGC?, IVC, and L2-esque strategies. 16:47:35 @sgp_: Monero has been around since 2014 with far more generous scaling rates and there has been no "scaling disaster". 16:47:35 I find statements that peer to peer electronic cash at scale is not possible in a decade actually very troublesome and such a philosophy does not belong at all in the Monero consensus code 16:53:07 If there is a legitimate reason to temporarily throttle the growth of the Monero network there are many tools available through node relay to do this. Of course the consensus burden will then fall on those who wish to limit growth as opposed to those who wish to allow growth. That consensus would only be achieved if there is a [... too long, see https://mrelay.p2pool.observer/e/mMXwqcMKODFWVkFa ] 16:57:04 I do believe that if Monero were to achieve say 200 transactions per second that would be the end of the Blockchain Surveillance industry, not only in Monero but also in so called surveillance coins 16:59:39 This means that the viability of companies worth billions of dollars is at stake here. 17:01:44 There could have been a scaling disaster. https://github.com/noncesense-research-lab/Blockchain_big_bang 17:02:30 just because something hasn't happened doesn't mean its not possible, stressnet has demonstrated it is possible 17:03:10 It does not justify baking failure into the consensus code 17:03:32 > there are many tools available through node relay to do this 17:03:32 You cannot limit block size by node relay 17:04:24 If the nodes limit bandwidth how can you grow the blocks? 17:04:32 Allowing 2x bloc growth ~2.5 times a year means that current scaling proposals would allow what, ~6x growth every year? A 10x increase at maximum than even the Moore Law calculation? 17:05:29 You forget there has been no growth in the last 5 years due to the lobbing effects of the BS companies 17:05:40 @articmine: failure here means it does not support enough txs (like bitcoin in your opinion). The real failure is being too aggressive with scaling and causing nodes to fall out of consensus with each other. 17:06:25 At 6x growth per year, why even have limits 17:08:36 Bitcoin is a failure not only as peer to peer electronic cash but also as a central bank reserve asset 17:08:49 It is only a matter of time 17:09:43 @sgp_: We need to catch up to undo the harm done by the BS companies for starters 17:10:12 >undo 17:10:14 @articmine: it is still alive, can we say the same of a coin that allows double spends due to nodes falling out of sync? 17:10:18 >blockchain 17:10:34 i think it's too late 17:10:58 @articmine: Even accepting that, why not set the current max block size to "the value Monero should be at this point" (calculated in my sheet at 193 MB blocks) and then set the max growth rate to 50%/yr? 17:11:15 Who do you think is behind the lobbying of governments to delist Monero from exchanges? 17:11:31 @articmine: police? 17:11:37 (ik BS) 17:12:34 No those who profit from selling blockchain surveillance even though it does not work. 17:12:34 It is a multi billion dollar industry 17:13:20 I was arguing the danger of blockchain surveillance back in 2018 17:13:27 *it does work at low tx levels 17:13:32 It does not work in Bitcoin 17:13:49 @boog900: Kind of 17:14:45 Enough to fool governments to part with their money 17:15:24 probabilities becomes certainty, and suspicions turns into culpability 17:15:54 maybe controversial opinion but we should not be limiting ourselves to VISAs txs/s, if we can do more we should do more 17:15:56 ... and the innocent get convicted 17:16:12 @boog900: Of course 17:16:23 if we can't, we should do less 17:17:09 @boog900: Or wait until we can 17:17:19 @articmine: I won't wait 17:17:30 Which why I am so opposed to consensus limits 17:17:35 I've the finger on the red button waiting to release Seraphis 17:17:55 @articmine: again the limits are not bandwidth or CPU currently 17:18:00 it is code 17:18:12 is 6x scaling a compromise then in your view, with the alternative being no limits? 17:18:34 @boog900: Which is and can be fixed 17:18:56 @boog900: so baking in scaling that we are not sure if we can hit is not a great idea 17:19:15 @sgp_: My position will be in my personal 17:20:00 @boog900: although a sufficiently "slow" expansion of blocks is probably ok 17:20:22 @boog900: Scaling was baked in since the genisis block 17:20:58 exactly and how often has it been in play? 17:21:14 last time was the spam IIRC and that broke wallets 17:21:15 People bought into Monero on that understanding 17:21:18 as we had bugs 17:21:37 Which were fixed 17:22:03 testing in production isn't a great idea for Monero ngl 17:22:21 @articmine: if there is one thing i've understood since i joined the monero community is that the colossal majority of people using monero understands what they want to understand, so no guarantee about that 17:23:06 @articmine: yeah a sufficiently slow expansion of blocks I would support 17:23:12 I bought in for the transparent amounts /s 17:23:44 fwiw I 100% agree that scaling up capacity is an important value for Monero to retain 17:24:21 but it's obviously not the only value, or else RingCT would have never happened 17:24:34 What determines capacity especially in the future? 17:26:02 Privacy is a huge value in the Monero community. Privacy is heavily dependent on scaling 17:27:18 its just not, the scaling code has rarely been activated 17:27:41 more txs are better sure, but not heavily 17:28:33 and no parameters have been selected yet 17:29:11 surly the best thing for privacy is 10 GB blocks right now? 17:29:31 It works both ways . If one cripples scaling one is also testing in production. This is what Bitcoin did in 2010 with its "temporary" 1 MB block size limit > <@boog900> testing in production isn't a great idea for Monero ngl 17:30:34 @articmine: I mean, are we bound to be literally dev consensus ddosed like bitcoin core? 17:30:36 fwiw, I think that the Monero community has demonstrated a strong willingness to change things that need to be changed 17:31:14 I would suggest that there should at least be hard agreement between the scaling design and the actual daemon performance in the short term. 17:31:14 A simple rule might be that the daemon must be capable of handling the most extreme limits of the scaling design until the long term median adjusts. 17:31:24 We could pick 10% growth rate now and choose 20% later. Or a one-time jump. Or really whatever makes sense 17:31:36 @sgp_: It has not diverged from its social covenant 17:31:59 @articmine: we have changed the scaling code making block growth smaller before 17:32:35 @sgp_: i would pick 10%.. per day 17:32:46 @sgp_: fwiw there are already theoretical improvements cooking in the back of the kitchen. So it's not like we're putting a limit now that we don't know if it will be changed, we have short/mid term plans for improving things 17:32:51 e.g. curve forests 17:32:52 With a daemon able to handle the full potential of the scaling design with a default long term median, a hard guarantee of ~2 months is in place for a development response without there being an issue. 17:33:08 10% per year is WORSE than using our current low fee tier 17:33:31 worse how, specifically? 17:33:59 Low fee tier will raise block size by > 10% per year 17:34:23 10% per year might as well be 0 17:34:34 oh you just mean more restrictive in terms of max scaling 17:34:38 yea 17:34:50 @ofrnxmr:xmr.mx: I suspect that is the idea 17:35:00 @ofrnxmr:xmr.mx: too boring, we should make yearly block increase by O(n!) 17:35:14 So that spam that we had, at low fee tier, has more scaling than 10% per year 17:35:27 And crippled the network 17:35:45 I don't consider that an argument in your favor lol 17:35:57 @ofrnxmr:xmr.mx: tbf the network stayed connected and in consensus 17:36:01 that we should cripple the network throughput intentionally? 17:36:21 no no no, that's a fundamental misunderstanding of fees 17:36:27 @boog900: When i say crippled, i mean, if the spam was consistent and reached 600+mb, then all new txa would be immediarwlt dropped 17:36:46 Because the spam was incompetent, ir never reached > 200mb, and txs werent rejected 17:36:55 users would need to pay higher fees than the spam to be confirmed with priority, like in any case 17:37:08 @ofrnxmr:xmr.mx: so do you think we need more scaling? 17:37:19 @boog900: more than current? No 17:37:28 More than low fee scaling? Yes 17:37:30 @ofrnxmr:xmr.mx: do you think we need less? 17:37:54