In collaboration with @FOUNDATIONdvcs we are brining @cakewallet with Monero and others to the Passport Prime! A sneak peek:

Cake Wallet v6.2.0 is here 🙌 ✅ Trezor Monero support 👀 ✅ Improved WalletConnect experience ✅ Pay Anything enhancements ✅ New nodes screen UI ✅ BTC/LTC sync improvements ✅ Bug fixes Update now on both Google Play and iOS 📲

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…

Jamtis: Why a new address format? When Monero was created in 2014, it inherited the CryptoNote addressing scheme. Originally, each wallet only had a single public address and payments were disambiguated with payment IDs. In 2017, subaddresses were introduced, which allowed each wallet to generate a virtually unlimited number of seemingly unlinkable addresses. In 2019, a weakness of subaddresses was identified, which allows an attacker to link two subaddresses belonging to the same wallet. This is called the "Janus attack". In 2026, Monero will upgrade to a new transaction protocol called Carrot, which provides mitigations for the Janus attack and offers address-conditional forward privacy (i.e. forward privacy if addresses are kept secret). However, several issues with the legacy addressing scheme remain unresolved: 1. Wallets with publicly known addresses lose nearly all privacy against a quantum-enabled adversary. 2. Wallets that use a third party service for scanning the blockchain lose nearly all privacy. 3. Generating subaddresses requires keeping track of a global counter, which complicates implementations and may cause merchants to prefer legacy integrated addresses. 4. The detection of outputs received to subaddresses is based on a lookup table, which can sometimes cause the wallet to miss outputs. 5. Checking two addresses for equality is difficult for humans because CryptoNote addresses are long and case-sensitive. The goal of Jamtis is to tackle the shortcomings of CryptoNote addresses that were mentioned above. Specifically: 1. Jamtis wallets with publicly known addresses retain a certain level of privacy even against a quantum-enabled adversary. 2. Jamtis wallets using a third-party scanning service retain a certain level of privacy. 3. Jamtis addresses can be safely generated without keeping track of a global counter. 4. Balance recovery for Jamtis wallets can be done reliably without the need to use a precomputed table of keys. 5. Jamtis addresses can be quickly compared thanks to a "visual prefix" consisting of 30 lowercase characters. Jamtis focuses on post-quantum privacy because all past and present Monero transactions are vulnerable to quantum privacy-breaking attacks due to the "harvest now, decrypt later" strategy. Additional goals are: 1. Backward compatibility with Carrot without hard forking changes. 2. Enotes sent to Jamtis addresses are indistinguishable from enotes sent to legacy addresses. 3. Jamtis addresses retain existing security properties of Carrot, especially Janus attack protection. Jamtis also comes with a new 16-word mnemonic scheme called Polyseed that will replace the legacy 25-word seed for new wallets. Non-goals An explicit non-goal of Jamtis is post-quantum soundness. This includes preventing a quantum-enabled adversary from: 1. opening Pedersen commitments to arbitrary monetary values 2. forging spend authorization proofs and linking tags 3. forging membership proofs Past and present Monero transactions are safe from soundness-breaking quantum attacks, assuming no cryptographically relevant quantum computers exist at this moment. Both Carrot and Jamtis support a migration protocol that will be used in a future fully post-quantum upgrade. Read more: gist.github.com/tevador/639d…

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…

🧭 Monero Ecosystem updated by Mondetta monero.eco 🟢 Projects added: monero.jobs monero.one TWIM 🔴 Projects removed: Revuo 📎 Links updated: OrangeFrens 🎨 Logos / icons updated: POS / Merchant MoneroKon 6 Forum TWIM Docs CCS

.@cypher_stack's Phase 1 code audit of the FCMP integration concluded successfully, identifying only informational findings and receiving praise for its depth and rigor. One high-priority verification: confirming that no existing or historical blockchain output would cause the new output_to_tuple function to fail, was only partially addressed due to time constraints. The final report includes an elegant mathematical proof of the unbiased hash-to-point scheme. The team is now addressing the informational recommendations, expanding test vectors, and verifying equivalence between the C and Rust hash-to-point implementations. jberman: 6. FCMP integration audit. ( github.com/seraphis-migratio… ) jberman: The audit went well, only information issues identified. Currently working on remediations for the informationals, and still awaiting the final document jberman: There was one item from Phase 1B that they were not able to complete a comprehensive audit on within the time allotted (though they did look into it) jberman: Specifically this item: "Verify the claim that no output or commitment detectable as a valid receive on the Monero blockchain today (or at any point in the past) would cause output_to_tuple to throw. This is critical because it means that an output that is detectable as a valid receive under existing/prior rules would not be spendable after FCMP goes into effect." UkoeHB: Were my comments here included in the audit? github.com/seraphis-migratio… jberman: It's an important item. I think it's understandable that it wasn't completed within the timeframe. I do think they were rigorous in the items they did explore jberman: I had updated both those bullets to try to cover those comments a while back jberman: (prior to the audit) UkoeHB: It didn't include equivalence of the unbiased hash to point impls. jberman: > which may simply involve verifying that the C implementation is fully Elligator2-spec-compliant jberman: it included that part UkoeHB: You mean the audit included that? It isn't in the bullets that I can see, unless I am blind. UkoeHB: Wait I see it now! jberman: > Does the implementation match Elligator 2 as specified in the Elligator paper: eprint.iacr.org/2013/325.pdf ? We are aware the implementation does not match the IRTF specification. jberman: That was added after/from your coment jberman: and prior to the audit jberman: and the audit did include that UkoeHB: The remark about being off-spec implies it could not match with the rust version, hence my being anal about this. Do we even have any test vectors the rust version is checking? jberman: Will look closer post meeting (also pinging kayabanerve). One of the valid suggestion they made during the audit was also to add more test vectors with known answer tests for various items UkoeHB: Thanks. Does the fcmp C API expose any code paths that actually depend on the rust version of the Hp impls? jberman: That's a good q. I'm not sure, also can look into that jeffro256: Off the top of my head, I want to say that the FCMP membership verification and SA/L verification is independent of the hash-to-point function chosen UkoeHB: Yeah sal is independent. jberman: Further comments on integration audit? I'll get back to those q's, and continuing on remediation / awaiting final report diego: are we on code audit? diego: I have the completed version from CS diego: mrelay.p2pool.observer/m/cyp… (FCMP_Code_Implementation_Audit.pdf) jberman: Nice, thank you ! jberman: Will take a closer look luke: All feedback would be much appreciated! Also, there is a rather elegant proof about the unbiasedness of the hash to point scheme included. jberman: Will do in the coming days libera.monerologs.net/monero…

Testing Monero on @Trezor 7 on @cakewallet over Bluetooth!

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…