04:11:31 This may be a bit redundant, however, I'd like to ask about how you guys feel regarding the security of CSIDH 512. I ask this mostly because it could potentially be helpful for ruling out options. 07:27:58 Thorchain is disappointed. Does monero value freedom of speech 07:30:14 Monero != moderating, wrong room and goodbye 08:06:12 The recommended reading in preparation for today's meeting is this comment, the following comment and the comment linked in it. https://github.com/monero-project/research-lab/issues/151#issuecomment-4412416686 11:11:51 I'm happy with AC1024 when it's clarified that while an adversary may see your address received an output, they can't see for how much _or_ where it was spent. Despite not achieving address unlinkability, I believe that's most of the actual benefit we want. cc @tevador to explicitly confirm that as while it's a straightforward [... too long, see https://mrelay.p2pool.observer/e/0O-h1IILbE1IRDRL ] 11:12:02 (and thank you, tevador, for all your hard work on this in general) 12:13:57 For whatever it matters, my personal view is that a "might" is always better than certainty. 13:15:03 I think either AC1024 or BC512 are sensible choices based on those tables. Thus I think AC1024 wins for practicality 13:17:09 I know that somewhat contradicts my advocacy for BC512 earlier, so apologies for dragging that out 13:31:55 Now that the mining attack is over, might this be reconsidered? https://github.com/monero-project/research-lab/issues/98 13:40:41 @camphor:matrix.org: I don't know if anyone has the available time at the moment to reopen the selfish mining mitigation discussion, but I hope we will in a few months. But if someone wants to push for it, they can lead analysis and discussion. 15:03:04 MRL meeting in this room in two hours. 16:40:38 I want to briefly add that an RFQ was sent out for Helios/Selene review. No action needed here (yet) 17:00:49 Meeting time! https://github.com/monero-project/meta/issues/1388 17:00:53 1. Greetings 17:00:54 hi 17:00:54 Hi 17:00:58 waves 17:01:00 hi 17:01:04 Hello 17:01:08 Hi 17:02:19 2. Updates. What is everyone working on? 17:02:31 beta stressnet 17:02:40 monerosim v0.1.0 is out: https://github.com/Fountain5405/monerosim 17:02:50 me: Keeping stressnet stressed and reporting issues. 17:02:54 Hello 17:03:24 Jamtis-PQ 17:03:29 Hi. Me: multisig wip 17:03:31 Polyseed, still 17:03:56 me: updating/rebasing serialization PR and looking at how to alleviate serialization limitations wrt to blocksize 17:04:11 it might be possible to alleviate issues without adopting a new serialization framework, but it’ll be gross and probably rejected 17:04:18 Hello 17:05:01 3. Audit of Helios/Selene Rust library. 17:05:20 @sgp_: @sgp_:monero.social said "I want to briefly add that an RFQ was sent out for Helios/Selene review. No action needed here (yet)" 17:05:45 AFAIK no further discussion of this item is needed, but please speak up if it is needed. 17:05:54 Action will be required around May 30 :) 17:06:33 4. Post-quantum encryption (https://github.com/monero-project/research-lab/issues/151#issuecomment-4412416686). 17:07:16 Howdy 17:07:35 The goal for today is to hopefully make a final decision on the PQ encryption variant for Jamtis. See the table in the linked comment for details. 17:07:39 me: beta stressnet issues and features 17:09:20 Any objections to going forward with Jamtis-AC1024? 17:11:10 "Monero adopts a PQ protocol" = Resistance to PQ counterfeiting and theft, right? 17:11:14 None from me. Just to clarify, AC512 isn't considered because it doesn't offer meaningful efficiency compared to AC1024 right? The extra margin is cheap in this case? 17:11:22 is the argument against BC512 mainly the 5x scan time? 17:11:59 rucknium: Yes, that has to be adopted before Q-Day. 17:12:39 I think it's worth noting that clients would have to download the pruned tx data, so mobile scan time (which is presently usually bottlenecked by download speeds via remote daemons) would increase from pruned tx sizes as well 17:12:47 tevador, how confident are you that CSIDH-1024 won't be broken for 60 years? 17:13:13 I note this because Jamtis-AN509 looks pretty attractive in that table as well, but when considering the 4.35x pruned tx size impact on mobile wallets, it's harder to swallow 17:13:28 I'm fairly confident about CSIDH-1024. 17:13:28 because "Alice received an enote in tran. X." vs. "Alice might have received an enote in tran. X." seems like quite the difference 17:14:14 There are 2 arguments against BC512: 1. Scan time 2. (in-)security 17:14:36 All things considered, I +1 that Jamtis-AC1024 is the strongest option on this table here as a positive incremental step forward toward improved PQ privacy 17:14:42 Although even BC512 is likely good for ~20 years longer than Curve25519 17:14:51 gingeropolous: the key distinction is that you can't continue using that information to discover transactions where those outputs might be spent. That significantly mitigates the privacy downside 17:14:57 2 security is a concern for me 17:15:08 Would AN509 allow for a non-interactive protocol like CSIDH would? 17:15:22 2^60 vs 2^72 ? 17:16:00 Yes, AC1024 and AN509 are functionally *almost* equivalent, except AN509 loses privacy if the address generator tier is compromised, AC1024 does not. 17:17:23 Yes, 2^72 is 4096 times harder to break (actually more due to practical reasons) than 2^60. 17:18:14 yeah 20 vs 50 yrs as in your scenario. though part of me is attracted to the 20 b/c it keeps the fire lit. 50 years ppl can handwaive "its fine......" 17:19:35 The choice is either high privacy for 20 years and then none vs medium privacy for 50 years and then none. 17:19:42 We have to deal with PQ to prevent hidden inflation, so the timeline is sooner than 20 years regardless 17:19:46 Besides the fact that it still doesn't hide the social graph with timing information? I have a feeling that with all these variations, our addressing protocol suite might end up like TLS: many different modular cryptographic components with one overarching generalized architecture > Any objections to going forward with Jamtis-AC1024? 17:19:53 and can't really be handwaved 17:20:24 I guess there are no variants of NTRU-509 that are bit less heavy, but still quite attractive? NT-300 or whatever ... 17:20:36 *NTRU-300 17:20:56 No, the security of lattices drops very fast, NTRU-300 would be completely insecure. 17:22:41 jeffro256: Depends on what you mean by social graph. AC1024 is enough to hide spends. 17:25:52 I was initially drawn to the "flashy" privacy of BC over AC, but in practice it's a high extra cost (and in practice, a lower security margin) to provide better privacy only in a specific edge case, at least that's how I currently view it 17:26:12 So are we disabling LWS for AC1024? 17:26:30 Or we send s_vv to the LWS ? 17:26:43 s_vb 17:26:56 No, LWS will work independently of the PQ encryption layer. 17:27:38 Okay so primary vt is still PQ insecure right ? 17:27:40 The expensive CSIDH-1024 calculation kicks in after a 24-bit view tag match, which is a relatively managable amount of CPU time. 17:28:09 For AC1024, the whole view tag is classical. For BC512, the secondary view tag is PQ. 17:28:14 yeah i can get behind AC1024 17:29:08 gingeropolous: Can you elaborate? 17:29:42 i mean the arguments for it vs. the bc512 make sense. 17:31:06 So if both secondary and primary view tags are not hidden from a QA, then the social graph is revealed with extremely high probability , getting exponentially higher the more interactions b/t 2 entities 17:31:35 i think either are probably fine, if we're going to bolt on a PQ preventative thing, based on whats been presented to my feeble brain 17:31:53 jeffro256: How so? The QA can find received enotes, but cannot locate outgoing payments. 17:32:15 @jeffro256:monero.social this is minimized because they need to know what address to check to see if it received funds, right? 17:33:01 Yes, the all this assumes that your Jamtis address is known to the attacker and the attacker is not the sender. 17:33:58 tevador: They can locate view tags for change enotes , and all outgoing txs must have a change enote even if change amount is 0 17:34:40 No, view tags for change enotes are calculates with symmetric crypto, which is PQ-proof. 17:35:14 Even if they weren't, you could use a different change address 17:36:08 Then LWS cannot find change enotes for AC1024 . Thats fine if that's the tradeoff we want to take , but that should be noted 17:36:37 LWS can locate the enotes, because users will give the LWS server their symmetric secret for internal view tags. 17:37:22 If they choose that option to reduce the download bandwidth. 17:37:24 Oh , but a different symmetric secret from s_vb? 17:37:37 Yes, a single purpose secret, s_fa 17:38:26 https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832#43-additional-keys 17:39:26 Can't ever have too many keys and secrets :) 17:39:38 Ah interesting , I didn't see that in the updated spec, sorry. Interesting . so now there's 3 scan paths 17:39:59 Yeah that could work 17:40:01 jeffro255: we discussed it a few weeks ago in here, maybe you forgot 17:41:09 In that case, I think AC1024 is a decent choice 17:41:23 Good evening, all. 17:41:35 Given the performance of better privacy options 17:41:47 @jeffro256: Yeah. Given it's sufficiently strong and still PQ with reasonable overhead, I'd choose AC1024. 17:42:13 @koe000:matrix.org: Yes I do remember discussing , but I guess I didn't quite get that we were talking about slightly different things 17:47:58 I see some Matrix people typing, but no message yet 17:48:45 We should probably move to the next item. I will leave it to tevador to decide whether the discussion today is enough to go forward with AC1024 R&D or if even more discussion is needed. 17:48:55 You can ignore my typing, I have nothing really worth sharing about this :) 17:49:01 I do have a question about BC1024 and related. 17:49:01 We already sort of concluded that performance overhead for it is entirely undesirable (see https://github.com/monero-project/research-lab/issues/151#issuecomment-4412416686), however, I would like to know if PEGASIS or CSURF would make this at all feasible. 17:49:01 I'm just curious as to whether or not this would be viable after both variants receive more scrutiny. 17:49:46 I don't have much else to add here since most topics seem to have been covered. I'm just throwing out a curiosity I have. 17:50:47 CSUDH-1024 performs the same as CSIDH-1024 and PEGASIS is not much faster and only has a proof of concept, far from practically usability. 17:50:55 CSURF-1024* 17:51:47 5. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). 17:52:06 @rucknium: I saw some crazy stuff go down on the stressnet, haha. 17:52:22 @jberman:monero.social: Do you want to share the GH issues that have appeared on stressnet? 17:52:28 From the PEGASIS paper: Our implementation in SageMath takes 1.5s to compute a group action at the CSIDH-512 security level, 21s at CSIDH-2048 level and around 2 minutes at the CSIDH-4096 level 17:52:43 Sure 17:53:42 We got to 5MB blocks and 1.4GB txpool. There was an accidental deep reorg. And a rare confession by the reorg-er :) 17:53:47 Red Failed to verify spam after deep reorg, node unresponsive, investigation still ongoing (we attempted another deep reorg that didn't trigger the issue): https://github.com/seraphis-migration/monero/issues/372 17:54:19 Double spend errors / rescan_spent apparently not resolving (this may be a regression from alpha, investigating further today): https://github.com/seraphis-migration/monero/issues/365 17:54:23 I think that j-berman has identified an issue which causes ridiculous slowdowns after a large reorg when the node is set to mine and/or provide block templates over RPC. It could happen on mainnet as well too 17:54:25 tevador: Yikes. 17:54:35 I am surprised that we seem to be hitting a ceiling at 5MB blocks, despite txs with fee level 2. Maybe I shouldn't be surprised. 17:54:58 Higher ban frequency (some theories on why, definitive cause not identified yet): https://github.com/seraphis-migration/monero/issues/373 17:55:07 I assume the new scaling rules have something to do with it. 17:55:45 Failed to switch to alternative blockchain in the logs (narrowed in on the cause, looks like a not-too-serious / not-too-difficult to rectify issue): https://github.com/seraphis-migration/monero/issues/374 17:56:25 One node's pool not catching up to another (not yet deeply investigated, @nahuhh shared a theory on the issue): https://github.com/seraphis-migration/monero/issues/375 17:57:00 @rucknium: It makes sense since there is an 8x cap on the median 17:57:23 Windows GUI binary crashing, but not self-compiled windows version (possibly caused by another solved issue with @redsh4de:matrix.org's help): https://github.com/seraphis-migration/monero/issues/376 17:57:35 People are using my spammer, but the reorgs are making it difficult sometimes! https://github.com/Rucknium/xmrspammer 17:58:32 And we've solved an RPC issue causing problems for cross-platfrom wallet -> daemon (thanks to @redsh4de's help) : https://github.com/seraphis-migration/monero/issues/367 17:59:12 "One node's pool not catching up to another" is disappointing to me because we have had this symptom since the very first stressnet, which was non-FCMP. 17:59:46 Different nodes having different txpool contents would usually make accepting 0-conf txs unsafe. 18:01:07 On alpha we used ad hoc code for refilling the pool to reduce bandwidth usage of the stressnet. Now we have tx relay v2, and we reintroduced the current node's logic for pool refilling. So that one will take some investigation to see why it's not working as expected 18:01:19 So are we stuck at 5MB blocks until the long-term median starts rising? 18:01:37 @rucknium: Is the divergence worse under FCMP or just more noticeable here with the spammer? 18:01:43 @rucknium: Yea 18:02:52 @neptunian:unredacted.org: No. The txpool divergence has occurred with about the same severity for the last 3 stressnets. Maybe not so bad in the 2nd stressnet (FCMP alpha). 18:03:11 @rucknium: the long term median was decreased for stressnet fwiw 18:03:21 One can go to 10 MB by paying the max fee with no scaling 18:04:04 I am assuming that the ML is starting at ZM 18:04:16 @ofrnxmr:monero.social: Do you remember what it's set to? I guess I could try to look for the config constant. 18:04:40 2 weeks 18:04:47 https://github.com/seraphis-migration/monero/pull/301/changes 18:05:21 Thanks, @jberman:monero.social 18:05:49 So blocksize can increase with ~1 week of spam 18:06:14 @jberman: Then one can go to 6MB 18:06:25 I'm going to stop trying to spam with level 2 fees. Just level 1 and wait for the long term median to kick in. 18:07:25 @rucknium: It wull not with no spam 18:07:35 This is by design 18:08:08 Then I will go for level 2 fees 18:08:09 I think would be good if we have another try at repro'ing that deep reorg red verified spam 18:08:44 What can be done different this time? 18:09:21 We discussed in the stressnet channel invalidating lots of txs, we can move discussion back in there 18:09:33 I think DataHoarder[m] may possibly have a node in the bad state from the first reorg. Last hope. 18:10:28 One should be able to maintain the short term median with level 1 fees 18:11:00 From what I can see this is working as designed 18:12:50 More about stressnet? 18:14:04 Hoping we'll have made good progress on those issues by next week :) 18:14:35 and v1.2 coming soon that also solves a number of issues: https://github.com/seraphis-migration/monero/pull/380 18:14:45 @yiannisbot:matrix.org 18:14:55 Hi 👋 18:15:02 6. CCS proposal: ProbeLab P2P Network Metrics Proposal (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667). 18:15:35 The CCS system is back up. Thanks for everyone who helped get it working again: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667 18:16:32 In the last discussion, a few people were not happy with the part of the CCS that was a monitor dashboard, similar to https://xmrnetscan.redteam.cash/ 18:17:01 Yup, correct. 18:17:02 oh wow look at the new nodes in the last few days 18:17:25 :( 18:17:56 so much adoption 🚀 18:18:37 @plowsof:matrix.org is working on a better DNS-based blocklist that could contain more addresses: https://github.com/monero-project/monero/pull/10572 18:19:21 The dashboard would give more insights regarding the new nodes, but indeed there was some disagreement from the community to proceed with this. 18:19:38 By "this", I mean Milestone 1 of the proposal. 18:21:03 thanks for sharing, after review comments from iamamyth im moving to obtaining a url:hash for the ban list and applying it directly. same effect none the less 18:21:30 I don't think it would give us much more insight, we pretty much know that 1000 real nodes did not come online overnight 18:23:47 Agreed. So AFAIU, the community is in favour of dropping M1 from the proposal and moving on with M2 - is that correct @rucknium:monero.social ? 18:24:30 I think M1 has received negative feedback. M2 needs more feedback. 18:24:31 The XMR/EUR exchange rate is a bit off 18:25:41 For M2, you would probably want to get an estimate of how frequently nodes rotate peers. I had some rough results here: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf 18:26:17 Line 329 - 349, pages 20 - 21. And Figure 14 18:27:24 If you were to do M2, I would want to have a confidence interval on your estimator for the number of unreachable nodes. I don't really want you to solve the estimation problem by setting up hundreds of nodes (or proxies) and get a good estimate by brute force. 18:27:58 So you could derive the confidence intervals mathematically (ideal, but difficult) or do Monte Carlo and/or bootstrapping to get the confidence intervals. 18:30:57 Sure, but out of curiosity, why would this not be desired? 18:30:57 > I don't really want you to solve the estimation problem by setting up hundreds of nodes (or proxies) and get a good estimate by brute force 18:33:01 Bloats your costs. Bloats MRL's costs if it wants to take samples over time. And deploying that many nodes and collecting all the data together is like spying on users. 18:34:15 The task is to use mathematics to get the estimate. Throwing more infrastructure is...not difficult enough! 18:34:46 We want to use your expertise. Not just have SaaS (software as a service) 18:35:09 I should say I want that. I shouldn't speak for others. 18:35:18 I see, yes. I think a combination of both would be ideal. If costs are unbearable, it could be that deploying nodes could be done once a week/month/whatever. 18:35:23 I shouldn't speak for others on that statement. 18:36:05 You should be able to express the confidence interval as a function of the number of nodes you need to deploy. Then make a decision about how many nodes would give you an acceptable confidence interval. 18:36:19 Is it recommended then to add the following statement in M2 of the proposal? 18:36:19 > So you could derive the confidence intervals mathematically (ideal, but difficult) or do Monte Carlo and/or bootstrapping to get the confidence intervals. 18:36:51 @yiannisbot:matrix.org: @yiannisbot:matrix.org: Yes. I think so. 18:36:53 @rucknium: Yes, exactly. That's what I also had in mind. But needs some more thinking. 18:37:24 Or, I could try to figure out that part of the project, but it would reduce your budget accordingly. 18:37:32 @rucknium: And then bring the topic back here next week? Or what's the process going forward? 18:38:04 I try to get more people involved in Monero research instead of being greedy with tasks that are in my area. 18:39:03 @rucknium: Not sure I'm getting this :) 18:39:12 @yiannisbot:matrix.org: You need more feedback on Milestone 2. 18:39:15 WDYM? 18:40:02 @rucknium: Sure, how can we make that happen? Are there people here that we can bring into the discussion? 18:40:43 @yiannisbot:matrix.org: I am a statistician (actually, economist with empirical focus) and therefore proposing and exploring the properties of a statistical estimator is in my area. But I don't want to lay claim to a task just because it's in my area. Anyway, there is much more research on Monero stats than I can do alone. 18:41:16 https://ccs.getmonero.org/how-to-ccs/ 18:41:16 > 7. You're done. Now go drum up some support. Good job on getting all the way here. When you finish, the community will be discussing your proposal on the merge request itself. If you want to weigh in on the discussion, feel free. It will be up to you to get people to support your proposal, both for it to be moved to the Funding Required stage, and also while its awaiting donations. 18:43:04 I think you should ask for feedback on M2 from the people who have already given feedback on M1. That includes people who have given negative feedback. A lot of people don't have a specific interest enough to give feedback. You can go to the broader community like #monero-community:monero.social , Monero Reddit, Twitter, or o [... too long, see https://mrelay.p2pool.observer/e/v7aW4YILdUxjVi1v ] 18:43:16 I think 113 XMR is quite a bit for this task ngl. 18:43:40 Is that the amount it'll be? 18:46:13 We're 1:45 into the meeting. I will end the meeting here and discussion on topics can continue. Thanks everyone. 18:46:22 The amount is estimated to be about that, yes. We'll revisit though once we have the full feedback of what is desired here. 18:46:39 Rucknium gave some constructive feedback on the direction. 18:48:15 @rucknium: Yes, I suspect that this is the most likely feedback we're going to get. So in order for this to go forward, it will need feedback from a few technical people. That's what we've seen generally. So if you know people that would care/appreciate this kind of work it would be great to talk to them (during this meeting or elsewhere). 18:49:51 Those people would probably be @boog900:monero.social , @vtnerd:monero.social , @syntheticbird:monero.social , @ofrnxmr:monero.social , @sgp_:monero.social , @plowsof:matrix.org 18:50:38 And @articmine:monero.social 18:51:56 (If I didn't mention you and you think I should have, now is your time to speak up and comment!) 18:53:05 rbrunner could comment, too, since he wrote the anti-spy subnet deduplication code. 18:56:57 Doing that right now btw > <@jberman> I think would be good if we have another try at repro'ing that deep reorg red verified spam 18:58:47 Thank you! Message to those folks: please contribute ideas to the discussion, either here, or in the Lounge or in the proposal repo itself. I think this would speed things up quite a bit. > <@rucknium> Those people would probably be @boog900:monero.social , @vtnerd:monero.social , @syntheticbird:monero.social , @ofrnxmr:monero.social , @sgp_:monero.social , @plowsof:matrix.org 19:01:05