Join us for very first @monero Meetup in Budapest - luma.com/3an58yx2 Tuesday, 16 June @ 19:00, Enter Bar - enterbar.hu $xmr #monero

BREAKING.: Biggest privacy token $ZEC crashed over -50% in the last 24 hours and wiped out $5 Billion from its market cap. The flaw was hidden inside Zcash's Orchard privacy pool since May 2022 and remained undetected for nearly 4 years despite multiple security audits. Security researcher Taylor Hornby reportedly used Claude Opus 4.8 AI model to build a working proof-of-concept that successfully generated counterfeit ZEC in local testing on May 29. Although the bug has now been patched on June 2, The issue is that Zcash's privacy design makes it impossible to know if any fake ZEC was minted before the fix. Unlike Bitcoin, where anyone can verify the supply, Zcash's privacy design makes it impossible to audit whether fake coins were secretly minted before the fix. The team denies any fake ZEC was minted, but traders are selling on the fear alone. Imagine someone secretly adding extra chips to a casino, but because of the way the system works, neither the casino nor the players could tell which chips were real and which were fake. Shielded Labs is exploring a proposed Network Upgrade to allow anyone to verify the integrity of Zcash supply.

MoneroKon 2026 begins tomorrow morning 🌅 Doors open at 9 am First talk is at 10 am 🗓 Schedule: cfp.twed.org/mk6/schedule/

The FCMP v2.0 beta stressnet is running smoothly with no major disruptions observed so far; full-scale spamming tests have not yet begun. Rucknium's stressnet monitors are active and publicly accessible: stressnetnode1.redteam.cash/ stressnetnode2.redteam.cash/ stressnetconsensus1.redteam.… stressnetconsensus2.redteam.… rucknium: 5. FCMP beta stressnet (github.com/seraphis-migratio…) jberman: v2.0 seems to be going smooth for now. Spamming hasn't kicked into gear yet rucknium: My monitors for the new stressnet are up and running: stressnetnode1.redteam.cash/ stressnetnode2.redteam.cash/ stressnetconsensus1.redteam.… stressnetconsensus2.redteam.… jberman: I'm working on a windows GUI binary crash at the moment rbrunner: Just curious, can you use a proper debugger there now? jberman: no, I don't have a good dev env for windows jberman: but I think I'm close to getting at the cause of the issue redsh4de: rbrunner: you can capture a crash dump with prodcump and run it through WinDbg. used that to produce the crash report for the issue rbrunner: Ah, I see. That makes sense. libera.monerologs.net/monero…

tevador presented updates to the Jamtis post-quantum (Jamtis-PQ) specification. The revisions add an identify-received public key that resolves longstanding weaknesses in the filter-assist tier, specifically preventing linkage of enotes to known addresses and detection of multiple enotes received to the same address. In the post-quantum context, this key adds only ~40 characters to an already ~400-character address, a cost the MRL participants viewed as well worth the privacy gain. The secondary view tag construction was also hardened so a quantum adversary cannot reliably determine enote ownership in many common cases. On consensus enforcement of the required CSIDH-1024 key in tx_extra, participants converged on Option 3B (no mandatory on-chain validation), citing marginal security benefit, modest CPU overhead (~10 ms), and the desire to preserve a clean soft fork while minimizing metadata leakage. jberman: 3. Post-Quantum Encryption ( github.com/monero-project/re… ). tevador: I updated Jamtis specs to reflect what was discussed in the past few meetings. gist.github.com/tevador/639d… tevador: Still a lot of work left, mainly in the appendix. jberman: tevador you mentioned Monday that the Jamtis-PQ solves the weaknesses in the filter-assist tier from Jamtis-Seraphis (specifically that the tier can't link enotes to known addresses and that it can't know if the same address received >1 enote) using an additional identify-received key. Tbc, that's an additional pub key in the address jberman: Was my rationale above accurate in explaining the stronger justification for an additional pubkey? "With the addition of PQ protection, seems the additional key has a more marginal impact on address sizes now" tevador: Yes, the additional pubkey only adds ~40 characters, which is small compared to the address length of 400 characters tevador: And the benefits are definitely worth it I think jberman: I would agree, that's a significant benefit for much lower cost than it originally was rbrunner: But only relatively? rbrunner: 40 of 400 is 10%, 40 of 200 is 20% tevador: Yes, the addition of PQ encryption shifted the scale rbrunner: Ok. I think that's a valid point of view :) tevador: Also a notable change in the specs is that the secondary view tag is constructed differently so a quantum attacker cannot always decide if an enote belongs to the wallet with a high probability. gist.github.com/tevador/639d… tevador: I think this is also worth the extra 3 bytes in each address. neptunian: tevador to clarify regarding Appendix B (Interactive payments) in the Jamtis spec, I just want to know if atomic swaps will become a concern in the future. tevador: neptunian: I don't follow. Why would an optional interactive payment protocol have any effect on atomic swaps? neptunian: I just realised I misread it. Disregard what I said lol jberman: Arguably an atomic swap protocol may be more included to use the interactive protocol (since atomic swaps are interactive) and would benefit jberman: more inclined* tevador: Yes, it might be beneficial for atomic swaps, not concerning. neptunian: Good to know. Thanks. tevador: The interactive protocol is there to enhance the overall PQ resistance, but it's not always possible to use it. Jamtis of course supports traditional non-interactive transactions. tevador: I will add a clarification in Appendix B. jberman: PQ protection on view tags is a nice added bonus. That would bring Option A closer to Option B in terms sounds like jberman: From this table: github.com/monero-project/re… tevador: Yes, but it works only in some cases, notably for enotes that have been received to an address the QA doesn't know and the wallet must not have received more than 1 enote to the same address. jberman: Ha, that pesky caveat. Still a solid improvement that I agree is worth an additional 3 bytes in each address jberman: Anything further on PQ encryption today? Thank you tevador for your continued quality work on this neptunian: Unless someone wants to talk on the question of Jamtis enforcement, I have nothing further to add. tevador: I think that can be left for later. jberman: What's the question of Jamtis enforcement? As in enforcement at consensus? neptunian: jberman: Yes. gist.github.com/tevador/639d… tevador: Jamtis requires a special tx-extra field. The question is if nodes should enforce its presence. tevador: Transactions lacking this field cannot be sending to a Jamtis address, which leaks information. tevador: It's similar to the issue with the number of transaction public keys and subaddresses. jberman: I'd lean toward Option 3B jberman: Ideally we'd also enforce a consistent tx format for tx pubkeys and subaddresses at consensus neptunian: jberman: My thinking as well. I was in favour of 3A or 3B tevador: CSIDH-1024 key validation takes ~10 ms of CPU time (for options 3A vs 3B) jberman: Part of the leaning toward deprecating tx extra was hardening protocol fields in tx format at consensus. I think enforcing consistent tx formats is a good goal neptunian: tevador: Would it be possible for 3A to come first with 3B after as to minimise metadata leakage? jberman: Key validation = decompressing the point? So wallets will need to do it anyway? If it was the case that if consensus doing it could save the wallet some ops during scanning, I'd be more inclined for 3A jpk68: Is the key only put in tx_extra because that allows Jamtis to be a soft fork? jpk68: Rather than adding a separate field tevador: jberman: key validation is similar to checking if an EC point is on the curve. It needs to be done before acting on the public key with a private key to avoid attacks. syntheticbird: epic matrix parsing neptunian: syntheticbird: lol tevador: jpk68: exactly, Jamtis is supposed to be a soft fork vtnerd: an attacker could re-use the same key too right? meaning 3A is of marginal use compared to 3b tevador: I was thinking it would be mostly to deter lazy wallet developers, but yeah, they can just ship a hardcoded valid CSIDH key... tevador: Not sure if it's a real concern jberman: or they could chuck other things into the tx that pass validation. I agree it seems doing extra crypto ops validation on the key at consensus is probably of marginal benefit here vtnerd: I don’t think its an issue, other than de-compressing the point has somewhat low utility jberman: presumably wallets would break if the key is invalid too, so lazy wallet devs would be deterred by having a broken wallet neptunian: I doubt it would manifest in a significant manner if it's only in lazy-dev-wallets. jberman: We can circle back to this convo in a future meeting, but Option 3B seems sanest to me fwiw tevador: Agreed neptunian: jberman: That sounds good. libera.monerologs.net/monero…

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 (github.com/monero-project/re…). 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: gist.github.com/tevador/639d… 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 github.com/monero-project/re…), 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 libera.monerologs.net/monero…

Naomi Brockwell @naomibrockwell on Reclaiming our Right to Privacy in the Digital Age | Tune-in to a LIVE MoneroTalk episode Thursday 5/14 at 7:00PM-EDT! Watch here on X or on YT ➡️: youtube.com/watch?v=qwMMsGHC… Twitch ➡️: twitch.tv/monerotalk Rumble ➡️: rumble.com/user/monerotalk Thank you to our show sponsors @cakewallet & @StealthEX_io