Schmidt

With many crypto fans souring on bitcoin, some are getting behind Zcash, a privacy token that lets users shield transaction details and remain anonymous on.wsj.com/435cPir

MRL reviewed the ProbeLab CCS proposal for P2P network metrics. M1 (dashboard) received negative community feedback and is likely to be dropped. Discussion focused on M2: statistical estimation of unreachable nodes with confidence intervals (preferred mathematical derivation or Monte Carlo/bootstrapping rather than brute-force node deployment). Rucknium emphasized using ProbeLab's expertise for rigorous estimators, avoiding cost bloat and privacy concerns from large-scale node setups. yiannisbot agreed to refine M2 with confidence intervals and seek broader feedback (including from network devs). Budget (~113 XMR) and AGPL licensing were noted; further community input needed before advancing. rucknium: 6. CCS proposal: ProbeLab P2P Network Metrics Proposal (repo.getmonero.org/monero-project…). rucknium: The CCS system is back up. Thanks for everyone who helped get it working again: repo.getmonero.org/monero-project… rucknium: In the last discussion, a few people were not happy with the part of the CCS that was a monitor dashboard, similar to xmrnetscan.redteam.cash yiannisbot: Yup, correct. boog900: oh wow look at the new nodes in the last few days boog900: so much adoption rucknium: plowsof is working on a better DNS-based blocklist that could contain more addresses: github.com/monero-project… yiannisbot: The dashboard would give more insights regarding the new nodes, but indeed there was some disagreement from the community to proceed with this. yiannisbot: By "this", I mean Milestone 1 of the proposal. plowsof: 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 boog900: I don't think it would give us much more insight, we pretty much know that 1000 real nodes did not come online overnight yiannisbot: Agreed. So AFAIU, the community is in favour of dropping M1 from the proposal and moving on with M2 - is that correct rucknium ? rucknium: I think M1 has received negative feedback. M2 needs more feedback. jpk68: The XMR/EUR exchange rate is a bit off rucknium: For M2, you would probably want to get an estimate of how frequently nodes rotate peers. I had some rough results here: github.com/Rucknium/misc-… rucknium: Line 329 - 349, pages 20 - 21. And Figure 14 rucknium: 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. rucknium: So you could derive the confidence intervals mathematically (ideal, but difficult) or do Monte Carlo and/or bootstrapping to get the confidence intervals. yiannisbot: Sure, but out of curiosity, why would this not be desired? yiannisbot: > 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 rucknium: 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. rucknium: The task is to use mathematics to get the estimate. Throwing more infrastructure is...not difficult enough! rucknium: We want to use your expertise. Not just have SaaS (software as a service) rucknium: I should say I want that. I shouldn't speak for others. yiannisbot: 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. rucknium: 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. yiannisbot: Is it recommended then to add the following statement in M2 of the proposal? yiannisbot: > So you could derive the confidence intervals mathematically (ideal, but difficult) or do Monte Carlo and/or bootstrapping to get the confidence intervals. rucknium: Yes. I think so. yiannisbot: And then bring the topic back here next week? Or what's the process going forward? rucknium: I try to get more people involved in Monero research instead of being greedy with tasks that are in my area. yiannisbot: Not sure I'm getting this :) rucknium: yiannisbot: You need more feedback on Milestone 2. yiannisbot: WDYM? yiannisbot: Sure, how can we make that happen? Are there people here that we can bring into the discussion? rucknium: 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. rucknium: ccs.getmonero.org/how-to-ccs/ rucknium: > 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. boog900: I think 113 XMR is quite a bit for this task ngl. boog900: Is that the amount it'll be? rucknium: We're 1:45 into the meeting. I will end the meeting here and discussion on topics can continue. Thanks everyone. yiannisbot: The amount is estimated to be about that, yes. We'll revisit though once we have the full feedback of what is desired here. yiannisbot: Rucknium gave some constructive feedback on the direction. yiannisbot: 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). rucknium: Those people would probably be boog900 , vtnerd , syntheticbird , ofrnxmr , sgp_ , plowsof rucknium: And articmine rucknium: (If I didn't mention you and you think I should have, now is your time to speak up and comment!) rucknium: rbrunner could comment, too, since he wrote the anti-spy subnet deduplication code. ofrnxmr: Is the current plan to gpl / foss any work? I need to re-look at m2 yiannisbot: Yes. We agreed in the previous meeting to go with AGPL. Let us know thoughts. yiannisbot: 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. #c675060" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

MRL reviewed ongoing FCMP beta stressnet results and issues. jberman listed several GitHub issues including post-reorg spam verification failures, double-spend/rescan_spent problems, higher ban frequency, txpool sync divergences between nodes, RPC slowdowns after deep reorgs, and a Windows GUI crash (later resolved). Block sizes hit a ~5MB ceiling due to the 8x median cap and current scaling rules; long-term median rise requires sustained spam. Participants noted txpool divergence has been a recurring symptom across stressnets and discussed next steps for reproduction and fixes (v1.2 PR upcoming). Overall progress acknowledged with plans for continued testing. rucknium: 5. FCMP beta stressnet (github.com/seraphis-migra…). neptunian: I saw some crazy stuff go down on the stressnet, haha. rucknium: jberman: Do you want to share the GH issues that have appeared on stressnet? rucknium: We got to 5MB blocks and 1.4GB txpool. There was an accidental deep reorg. And a rare confession by the reorg-er :) jberman: Red Failed to verify spam after deep reorg, node unresponsive, investigation still ongoing (we attempted another deep reorg that didn't trigger the issue): github.com/seraphis-migra… jberman: Double spend errors / rescan_spent apparently not resolving (this may be a regression from alpha, investigating further today): github.com/seraphis-migra… jeffro256: 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 rucknium: 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. jberman: Higher ban frequency (some theories on why, definitive cause not identified yet): github.com/seraphis-migra… rucknium: I assume the new scaling rules have something to do with it. jberman: 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): github.com/seraphis-migra… jberman: One node's pool not catching up to another (not yet deeply investigated, nahuhh shared a theory on the issue): github.com/seraphis-migra… articmine: rucknium: It makes sense since there is an 8x cap on the median jberman: Windows GUI binary crashing, but not self-compiled windows version (possibly caused by another solved issue with redsh4de's help): github.com/seraphis-migra… rucknium: People are using my spammer, but the reorgs are making it difficult sometimes! github.com/Rucknium/xmrsp… jberman: And we've solved an RPC issue causing problems for cross-platfrom wallet -> daemon (thanks to redsh4de's help) : github.com/seraphis-migra… rucknium: "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. rucknium: Different nodes having different txpool contents would usually make accepting 0-conf txs unsafe. jberman: 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 rucknium: So are we stuck at 5MB blocks until the long-term median starts rising? neptunian: rucknium: Is the divergence worse under FCMP or just more noticeable here with the spammer? articmine: rucknium: Yea rucknium: neptunian: 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). ofrnxmr: rucknium: the long term median was decreased for stressnet fwiw articmine: One can go to 10 MB by paying the max fee with no scaling articmine: I am assuming that the ML is starting at ZM rucknium: ofrnxmr: Do you remember what it's set to? I guess I could try to look for the config constant. jberman: 2 weeks jberman: github.com/seraphis-migra… rucknium: Thanks, jberman jeffro256: So blocksize can increase with ~1 week of spam articmine: jberman: Then one can go to 6MB rucknium: 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. articmine: rucknium: It wull not with no spam articmine: This is by design rucknium: Then I will go for level 2 fees jberman: I think would be good if we have another try at repro'ing that deep reorg red verified spam rucknium: What can be done different this time? jberman: We discussed in the stressnet channel invalidating lots of txs, we can move discussion back in there rucknium: I think DataHoarder may possibly have a node in the bad state from the first reorg. Last hope. articmine: One should be able to maintain the short term median with level 1 fees articmine: From what I can see this is working as designed rucknium: More about stressnet? jberman: Hoping we'll have made good progress on those issues by next week :) jberman: and v1.2 coming soon that also solves a number of issues: github.com/seraphis-migra… #c675010" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

The MRL discussed finalizing the post-quantum encryption variant for the Jamtis address scheme. After comparing options in the provided table (AC1024, BC512, AN509 etc.), there was general support for proceeding with Jamtis-AC1024 due to its strong security margin, reasonable performance impact on scan times and pruned tx sizes, and privacy properties. Concerns around BC512 (higher scan time, lower relative security) and alternatives like NTRU variants or PEGASIS/CSURF were addressed. LWS compatibility and view tag handling (including change outputs) were clarified with additional symmetric secrets. No major objections; tevador to decide on next steps for R&D. rucknium: 4. Post-quantum encryption (#issuecomment-4412416686" target="_blank" rel="nofollow noopener">github.com/monero-project…). tevador: 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. tevador: Any objections to going forward with Jamtis-AC1024? rucknium: "Monero adopts a PQ protocol" = Resistance to PQ counterfeiting and theft, right? sgp_: 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? gingeropolous: is the argument against BC512 mainly the 5x scan time? tevador: rucknium: Yes, that has to be adopted before Q-Day. jberman: 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 rucknium: tevador, how confident are you that CSIDH-1024 won't be broken for 60 years? jberman: 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 tevador: I'm fairly confident about CSIDH-1024. gingeropolous: because "Alice received an enote in tran. X." vs. "Alice might have received an enote in tran. X." seems like quite the difference tevador: There are 2 arguments against BC512: 1. Scan time 2. (in-)security jberman: 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 tevador: Although even BC512 is likely good for ~20 years longer than Curve25519 sgp_: 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 articmine: 2 security is a concern for me jpk68: Would AN509 allow for a non-interactive protocol like CSIDH would? gingeropolous: 2^60 vs 2^72 ? tevador: Yes, AC1024 and AN509 are functionally almost equivalent, except AN509 loses privacy if the address generator tier is compromised, AC1024 does not. tevador: Yes, 2^72 is 4096 times harder to break (actually more due to practical reasons) than 2^60. gingeropolous: 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......" tevador: The choice is either high privacy for 20 years and then none vs medium privacy for 50 years and then none. jberman: We have to deal with PQ to prevent hidden inflation, so the timeline is sooner than 20 years regardless jeffro256: 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 jberman: and can't really be handwaved rbrunner: I guess there are no variants of NTRU-509 that are bit less heavy, but still quite attractive? NT-300 or whatever ... rbrunner: NTRU-300 tevador: No, the security of lattices drops very fast, NTRU-300 would be completely insecure. sgp_: 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 jeffro256: So are we disabling LWS for AC1024? jeffro256: Or we send s_vv to the LWS ? jeffro256: s_vb tevador: No, LWS will work independently of the PQ encryption layer. jeffro256: Okay so primary vt is still PQ insecure right ? tevador: The expensive CSIDH-1024 calculation kicks in after a 24-bit view tag match, which is a relatively managable amount of CPU time. tevador: For AC1024, the whole view tag is classical. For BC512, the secondary view tag is PQ. gingeropolous: yeah i can get behind AC1024 tevador: gingeropolous: Can you elaborate? gingeropolous: i mean the arguments for it vs. the bc512 make sense. jeffro256: 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 gingeropolous: 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 tevador: jeffro256: How so? The QA can find received enotes, but cannot locate outgoing payments. sgp_: this is minimized because they need to know what address to check to see if it received funds, right? tevador: Yes, the all this assumes that your Jamtis address is known to the attacker and the attacker is not the sender. jeffro256: tevador: They can locate view tags for change enotes , and all outgoing txs must have a change enote even if change amount is 0 tevador: No, view tags for change enotes are calculates with symmetric crypto, which is PQ-proof. sgp_: Even if they weren't, you could use a different change address jeffro256: Then LWS cannot find change enotes for AC1024 . Thats fine if that's the tradeoff we want to take , but that should be noted tevador: LWS can locate the enotes, because users will give the LWS server their symmetric secret for internal view tags. jeffro256: Oh , but a different symmetric secret from s_vb? tevador: Yes, a single purpose secret, s_fa tevador: #43-additional-keys" target="_blank" rel="nofollow noopener">gist.github.com/tevador/639d08… rbrunner: Can't ever have too many keys and secrets :) jeffro256: Ah interesting , I didn't see that in the updated spec, sorry. Interesting . so now there's 3 scan paths jeffro256: Yeah that could work koe000: jeffro255: we discussed it a few weeks ago in here, maybe you forgot jeffro256: In that case, I think AC1024 is a decent choice jeffro256: Given the performance of better privacy options neptunian: Yeah. Given it's sufficiently strong and still PQ with reasonable overhead, I'd choose AC1024. jeffro256: Yes I do remember discussing , but I guess I didn't quite get that we were talking about slightly different things rucknium: 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. neptunian: I do have a question about BC1024 and related. neptunian: We already sort of concluded that performance overhead for it is entirely undesirable (see #issuecomment-4412416686" target="_blank" rel="nofollow noopener">github.com/monero-project…), however, I would like to know if PEGASIS or CSURF would make this at all feasible. neptunian: I'm just curious as to whether or not this would be viable after both variants receive more scrutiny. neptunian: 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. tevador: 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. tevador: CSURF-1024 tevador: 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 #c674935" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…