Code is ready. Target fork Monday 5 Oct 2026; binaries expected within a day. jeffro256 proposed a 10 MB initial penalty-free zone to skip warm-up and resume prior spam volumes; leftover bugs should match the earlier raise to 625K. libera.monerologs.net/monero… 1/2

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…