Monero (XMR)

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 (#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…

tevador proceeds with Option A (standard CSIDH-1024 parameters) for Jamtis: 400-character addresses. All transactions embed a CSIDH-1024 public key in tx_extra; legacy wallets ignore it with no scan-time change. An optional interactive symmetric-crypto payment protocol is being developed for users wanting stronger PQ privacy. Discussion covered quantum-adversary capabilities, mobile-wallet UX, harvest-now-decrypt-later risks, address hygiene, and Tachyon-like alternatives. rucknium: 5. Post-quantum encryption ( #issuecomment-4281932714" target="_blank" rel="nofollow noopener">github.com/monero-project… ). tevador: Quick update: Based on the last meeting, I decided to go with Option A for Jamtis and use the standard CSIDH-1024 parameters. The address length will be 400 characters. I'm working on an interactive payment protocol that will be able to provide full privacy without an on-chain key exchange (it will be an appendix to the address specs). vtnerd: Not a fan of it being interactive - is that portion mandatory? The user cannot opt out of an interactive key exchange? tevador: To clarify: there will be both options. A non-interactive PQ key exchange based on CSIDH-1024 and an optional interactive one based on symmetric crypto only. vtnerd: Hmm. Symmetric crypto is a sure way to anger a QC rucknium: More noob questions from me, about scan time. What happens when an old-style (non-quantum-resistant) wallet scans a quantum-resistant output. Any slowdown? And the reverse: Any speedup when a new-style wallet scans a non-quantum-resistant output? jberman: I don't really see another feasible route on the table here tbh. If we want mobile wallets to be able to restore a wallet from seed, then the more secure PQ key exchange algos don't seem practical by the figures here articmine: A related question is how effective is parallel processing here? tevador: The goal is for all transactions to have a CSIDH-1024 public key in tx extra. Legacy wallets will simply ignore the key. Scan times will be about the same as now for both legacy and Jamtis. tevador: enote scanning is obviously parallelizable, but the amount of computation required makes CSIDH view tags infeasible rucknium: jberman: Do you mean the interactive protocol or Option A for non-interactive? jberman: That comment applies to both. I don't see another route on the table aside from those 2 routes: Option A for non-interactive, or the interactive protocol rucknium: What if we wait until better PQ algorithms are discovered? tevador: I also think that option A and an additional interactive protocol is the best compromise. Addresses will remain usable and the interactive protocol can be used by users who want more PQ privacy than Jamtis will offer. rucknium: Hard to know what the future may hold, of course. tevador: Waiting is not an option due to "harvest now, decrypt later". rbrunner: At least with A we don't get astronomical scan times, with mobile wallets completely unable to scan themselves jberman: It could theoretically be implemented and not deployed until the QC threat passes some threshold, and in that time if some better algo arises, perhaps we could swap it in rucknium: With Option A, a quantum adversary cannot identify all the outputs sent to an address that it does not know, correct? There would be limited ability to try to cluster the behavioral information. gingeropolous: but then there's n years of data to decrypt jpk68: As rbrunner mentioned last week (I think), making scan times infeasible for mobile wallets (basically, anything that would force you to self-host something like LWS) would eliminate a huge amount of people from being able to use Monero jpk68: In my opinion this is infinitely more of a UX burden than long addresses, for example rucknium: I think people could still use Monero. But would not be protected from a quantum adversary. jeffro256: rucknium: With option A, a QA can identify all outputs sent to any address sharing that one's view key. And it can identify spends in most cases rucknium: But not any outputs of a view key that it does not know any addresses of? endogenic: all ecdh and signing is broken by qc guys rucknium: It would ID spends because of change outputs sent to own addresses, I assume endogenic: you can't still use monero jeffro256: rucknium: Yes. but that is true of CARROT and legacy addresses too tevador: rucknium : With option A, if the QA knows one of your addresses, they can calculate primary and secondary view tags, but can only probabilistically identify enotes to unknown addresses unless the address is reused. tevador: jeffro256 : No, it cannot identify spends. rucknium: If the adversary had the addresses of the sender and recipient, that would reveal the spending behavior fully. Not the amount. Correct? tevador: Internal enotes use a symmetric key for view tags. jeffro256: tevador: I mean that it can sometimes identify the spend location of external enotes, not internal enotes luke: I agree with Rucknium's comment of potentially waiting for more PQ options. Isogeny based scheme make me nervous. tevador: If the adversary has Alice's and Bob's addresses, they can see enotes (without amounts) coming to Alice's and Bob's wallet, but can't infer they are transacting with each other. endogenic: if mallory has a and b addrs then mallory can get a and b sec keys no ? tevador: jeffro256 : It cannot, at least not for Jamtis enotes. rucknium: lu: Thank you for your comment. Could you elaborate? rucknium: (Luke S is with Cypher Stack cypherstack.com/about.html ) endogenic: I guess he's talking about lattice etc problems tevador: luke : I'm actually quite confident about CSIDH. tevador: The original idea behind CSIDH is from 1996 IIRC, so fairly old. luke: Sure. Me and the other mathematicians have spent a great deal of time talking about PQ security stuff, both at CS and in our academic careers and it is the loose consensus that isogeny based problems are the least favorite of the potential PQ primitives. jeffro256: tevador: Maybe I'm remembering an attack which works on Seraphis, but not FCMP++ because of the key image composition. I'll look at it again. At least with Jamtis previously, if two enotes were spent from the same address, even if a QA didn't know the spend key extensions, they could tell that they were the same between 2 (one-time address, key image) pair, thus allowing them to correlate where external enotes were spent jeffro256: It's been a while since I looked at that particular attack luke: Lattice based problems are fine but I personally am a big proponent of Code based cryptography. I think it is probably the most likely to retain its PQ status in the time to come. tevador: jeffro256 : IIRC that was a Seraphis-only attack, FCMP++ has perfectly hiding linking tags. jeffro256: Seraphis also had perfectly hiding linking tags, though. The foil might be the hash-to-point in FCMP++ luke: I agree, but it is entirely possible that we might see some sort of improvement in the near future. tevador: luke : Yes, McEliece would have been great if it wasn't for the 250 KB public keys :) tevador: A bit impractical for an address. tevador: Yes, but waiting means more exposed legacy addresses that will be broken and deanonymized. jberman: tevador: for the non key exchange route, Tachyon may have a better set of tradeoffs worth considering as well I think tevador: I'm not familiar with Tachyon jberman: seanbowe.com/blog/tachyon-s… jberman: As I understand it, there's an always-on server that scans state without leaking privacy, and there's no key exchange protocol tevador: jberman : I checked the Tachyon blog post. It seems that Zcash wants to eliminate non-interactive transfers, which is probably not what we want? tevador: quote : "As a start, we'll be assuming that Zcash's future payment flows involve out-of-band payments where the sender and the recipient use a separate channel for secret distribution." jberman: tevador: I agree. In any case, their intent seems to be to roll it out in phases, which implies a period of time where they'd support both. Considering how they've done things in the past, I'd assume the "tachyon" pool is incompatible with the existing anonymity pools though. And ya I would agree distinct anon pool is not what we'd want jberman: But perhaps there could be some tweak that enables a compatible anon set with an interactive protocol jberman: non-interactive* jberman: I would be surprised if that design isn't achievable jberman: tevador: I agree and am not raising it to shift UX to interactive payments jberman: You mentioned exploring an optional interactive route that would require out of band communication, I'm mentioning a Tachyon-like design as worth considering for that optional component alongside the non interactive jberman: Also it doesn't seem like the protocol requires a single centralized server, and a user could spin up their own instance. I imagine the UX would include some payment request that points to their own instance of choice jberman: That design obviously seems worth considering if we're discussing interactive payments jberman: A 3-round protocol is hard to see gaining traction without a server in between helping automate the flow jberman: I would guess that wallet apps may implement a communication protocol with their own infra (or maybe work something out with some service provider) jberman: And so long as a server would be involved, then it's worth thinking on further and weighing expected UX ixr3: I hope Jeffro implements the carrot key hierarchy soon after the HF, or earlier if the HF is significantly delayed. Internal forward secrecy will help in the meantime until better PQ solutions are available. Churning will become increasingly important for anyone concerned with post‑quantum security. ixr3: "harvest now, decrypt later" is bad and the Jamtis-PQ release will probably take longer than expected tevador: jberman : it's not about the anon pool. It's the UX shift to interactive transactions that we don't want. Zcash is a for profit company, they can afford to run infrastructure to help users interact during payments, but it's not a viable solution for Monero. jberman: I agree and am not raising it to shift UX to interactive payments You mentioned exploring an optional interactive route that would require out of band communication, I'm mentioning a Tachyon-like design as worth considering for that optional component alongside the non interactive Also it doesn't seem like the protocol requires a single centralized server, and a user could spin up their own instance. I imagine the UX would include some payment request that points to their own instance of choice That design obviously seems worth considering if we're discussing interactive payments tevador: I'm not going to place any infrastructure requirements in my proposal. The interactive payment protocol will be executed by passing 3 alphanumeric strings between the recipient and the sender over any communication channel of their choice. sgp_: some wallets already do this for payjoin. I hate implementations where this would be expected, but wallets often use stuff like this today for helper functions. The fewer that are needed, the better. #L33" target="_blank" rel="nofollow noopener">github.com/cake-tech/cake… tevador: The flow in my sketch protocol is: Receipient -> Sender -> Recipient -> Sender, where each arrow is a ~400 character string. jberman: A 3-round protocol is hard to see gaining traction without a server in between helping automate the flow I would guess that wallet apps may implement a communication protocol with their own infra (or maybe work something out with some service provider) And so long as a server would be involved, then it's worth thinking on further and weighing expected UX sgp_: I think that an interactive payment protocol would be a huge loss :( if the requirement of max address length of 420 was dropped, would BC1024 be the most appealing? or would you still prefer A?I admit to being tempted by BC512. Yes, the security guarantees are smaller with CSIDH-512 than CSIDH-1024. But the privacy gains with option B over A are considerable to me. If we consider a "collect now and decrypt later" scenario as the most dangerous at the moment, it seems to suggest that we should prefer greater privacy (1/256 enote narrowing down vs knowing all received enotes) to the security margin. If it would take "65 thousand quantum computers running for 5 years" to break the security of a single key with CSIDH-512, we at least would have ample (in relative terms, it would still suck!) time to implement a migration strategy to more secure wallets. Am I misinterpreting something? tevador: sgp_ : Why would and additional interactive protocol be a loss? If it's optional for people who want to use it. IMO it's a net gain. sgp_: I mean requiring it for PQ privacy of received enotes (even in the 1/256 form) would be unfortunate If options A or B are selected, I'm not against an optional interactive thingy for even better post quantum privacy tevador: Option B is kinda suboptimal, that's why I preferred A or C. B adds: some (but not a lot) of enote privacy, but the costs are: much larger addresses, a much larger pruned transactions (up to 2-3 KB for 16-out transactions) and awkward filter assist (light wallets are supposed to run the heavy CSIDH instead of the filter server). tevador: And B still lacks PQ unlinkability, so if you have 2 online identities and use the same wallet, they can be linked in a PQ scenario. tevador: Only option C gives full PQ privacy. sgp_: I definitely wasn't factoring in the filter assist, but I do think 1/256 is hugely better than nothing (it's like ring sigs, but better) linkability is unfortunate but we deal with janus now, so advanced users should be aware of potential limitations, and they can be informed that limitations would persist I suppose one argument for Option A is that senders already know what enotes they send to addresses they are aware of, so this could be a user education problem, where recipients are told to always use fresh addresses per sender. Address hygiene becomes more of a requirement. Basically, we try to UX our way out of most limitations (leaving some footguns), and for everything else, there's an interactive protocol tevador: For maximum privacy, you should use a fresh wallet per sender, unless we go with Option C. #c672772" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

Tune-in to @MoneroTalk Thursday at 7pm est live with @justinberman95 !!! One of the main devs who has been developing and implementing the FCMP++ and Carrot upgrade over the past 2 years. This beta stressnet will be the second live network testing the FCMP++ and Carrot integration open to the public. FCMPs is closer than ever. Come learn all about it, what you can do to help test it, and what the next steps are before Monero goes live with one of its biggest updates ever! See the official Beta stressnet announcement here:

Full-Chain Membership Proofs (FCMP++) - The Next Generation of Monero's Privacy Thanks to @VOSTOEMISIO and @xenumonero for producing this excellent explanatory video and to our generous community for funding it!

❗️Only 1 month remains until MoneroKon 🎟️ Tickets: shop.twed.org/twed/MK6/

The FCMP++ 1a/1b integration audit has officially kicked off. @MagicGrants selected Trail of Bits (Vendor 1) over the other shortlisted vendor due to significantly better scheduling (expected start May 11 after a preparation week, completion by May 22). The chosen auditors bring strong relevant experience in cryptographic theory, implementation review, and Rust FFI. @cypher_stack is conducting an independent, unfunded parallel code review and has already made substantial progress. sgp_: The FCMP++ 1a/1b audit process has kicked off. I have a call to discuss GBPs with zksec tomorrow. I hope to move forward with that quickly, with a goal of final approval during next week's meeting. sgp_: For FCMP++ 1a/1b, we ended up going with vendor 1 instead of 4 due to scheduling. Both are good choices, but vendor 1 will deliver 2 months sooner tevador: Who is Vendor 1? jberman: Vendor 1 is Trail of Bits rucknium: > The FCMP++ 1a/1b audit process has kicked off. rucknium: > I have a call to discuss GBPs with zksec tomorrow. I hope to move forward with that quickly, with a goal of final approval during next week's meeting. rucknium: > The divisors paper from zksec suggested small fixes and we're looking at those, but we don't expect these to require actual changes in the code. rucknium: > A helioseleine secondary audit will be prudent. I need to write up what makes the most sense for that. Some stuff was formally proven, but other stuff wasn't and needs manual review rucknium: > For FCMP++ 1a/1b, we ended up going with vendor 1 instead of 4 due to scheduling. Both are good choices, but vendor 1 will deliver 2 months sooner jberman: The specific candidates Trail of Bits (ToB) shared who would work on the integration audit had direct relevant experience on cryptography theory and impl review, as well as with Rust FFI's jeffro256: ToB can allegedly start working May th jeffro256: 4th jberman: May 11th* articmine: ..and expected completion jberman: With expected completion date of May 22nd jeffro256: Did they change it? jberman: They want to use next week to prepare and plan with us, and then actually begin the 11th tevador: I have a comment about the future audit of mx25519: Since Carrot doesn't use the scalar inversion code, it could be removed from the library to simplify the audit. Pinging jeffro256 to confirm. jeffro256: Yes, Carrot doesn't ever use the scalar inversion code jeffro256: Although, wouldn't Jamtis still use it for the Janus check? tevador: Yes, Jamtis will use it, but I'll have to check if your changes in the library are compatible. tevador: It might be better to leave it for a future Jamtis audit. jeffro256: That's totally fair. It could definitely be excluded from an audit scope koe000: It may be more efficient to review the inversion now instead of later, since the auditor will already be in the mindset. Separating means paying for an auditor to set up that mindset twice. tevador: koe000: the inversion code is completely separate from the ladder code, it should have been two libraries instead of one diego: hi can I speak on the audit thing? I can do so after the meeting rucknium: diego, Yes diego: Cypher Stack is doing a code review too. We weren't chosen for the money, but it doesn't matter. We started weeks ago. You should still go with the other group too btw. Should be done in a few weeks. Big progress on it already. #c671214" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

Monero FCMP++ beta stressnet is a go! github.com/seraphis-migra…

jberman: Update: we've decided on @quarkslab (Vendor 4) for Phase 1 of the FCMP++ integration audit. They indicated that they can start ASAP (end of Apr, early May), and so we would expect it to be complete by early July, which should not end up blocking the FCMP++ timeline. Repeating, Quarkslab committed to 400 man-hours of work and estimated a 6-8 week timeline from start to finish, at a rate of $50,000. Here is some of their relevant xp: blog.quarkslab.com/security-audit… blog.quarkslab.com/security-audit… blog.quarkslab.com/audit-of-the-m…

tevador presented a simplified summary of the 7 options (Option A/B combined with CSIDH-512/1024/2048 or NTRU-509) and invited comments on proceeding with BC1024 (CSIDH-1024). The MRL compared it to Zcash’s inferior O(N) scanning approach, examined de-anonymization risks for HD wallets/Carrot addresses/shared view keys, self-sends’ privacy value, and why static reusable addresses remain critical. CSIDH was favored over lattice KEMs like NTRU due to no address-generator collusion risk and better multi-output performance/tx sizes. UX concerns (long addresses ~600+ chars, QR scannability) were tested live with examples; hardware-wallet checksums and merchant/RPC adoption were addressed. No major opposition; further comments welcomed. (See full GitHub thread: #issuecomment-4281932714" target="_blank" rel="nofollow noopener">github.com/monero-project… and related github.com/monero-project….) tevador: I wrote a simplified summary without any gory math details. The point is to agree on one of the 7 choices. sgp_: Ty tevador for all your work on this and your work organizing this rbrunner: Likewise ofrnxmr: seconded rucknium: Yes, thank you tevador :) tevador: For comparison, Zcash is going with something similar to AN509, but worse, because they will have O(N) scanning time with N = number of addresses. plowsof: +1 tevador: Does anyone have any comments? Any opposition to moving forward with BC1024? rucknium: I am going to ask some noob questions. If a PQ adversary has one of the Carrot addresses of a wallet, they can de-anonymize the txs of the wallet that share a common private key seed, e.g. the Hierarical Deterministic (HD) wallet seed phrase. Is that correct? Then an impractical countermeasure is to eliminate HD wallets and go back use-once private keys for each tx packed into wallet.dat. Would that actually work? tevador: They can deanonymize transactions that share a private view key. You can avoid that by having a different view key for each transaction, but that means O(N) scanning time. tevador: Different view key for every address* jeffro256: rucknium: For the new Carrot key hierarchy, the QA can deanonymize the transaction graph of the output receives externally. They cannot deanonymize the outputs which were self-sended rucknium: Another hypothetical: Why would a party that is cooperating with a PQ adversary set up the infrastructure to send XMR to this special PQ address? Wouldn't they just say "Sorry, you must use the old addresses"? Isn't this a big part of the threat model that these PQ addresses are , um, addressing? tevador: Yes, but self-sends are not very important in practice anyways. jberman: A comment on potentially large (1kb+) address length: perhaps we could implement something like ASCII qr codes? So instead of copying and pasting massive clunky addresses, copy pasting ASCII qr codes. I see that the huge addresses aren't the only downside to the algos with huge addresses (pruned tx sizes seem lager too, which is significant and also affects scan time from downloading), but perhaps there is a solution that renders them not so terrible tevador: If the Monero-RPC accepts the new address format, I don't see a reason for a merchant not to support it. jeffro256: tevador: It is important because it hides where the wallet sent their funds. They would also gain importance once people realize the PQ implications and begin using self-sends as such rucknium: Another question: Do these addresses get Monero closer, at all, to a countermeasure to PQ counterfeiting? I assume no, but I wanted to check. tevador: No, this is purely for PQ privacy jeffro256: A QA can, in many circumstances, calculate the spending location of externally received funds, not just where they were received. So a self-send in between would hide the spend locations of those outputs jeffro256: rucknium: The mitigation of using ephemeral private keys for each tx would work. Note that your wallet scanning time would be O(N) for the number of pairs generated tevador: Yes, but the QA learns the received amounts to the known address in any case, whatever you do afterwards, which is a biggest leak IMO. rucknium: If the keys are designed to be single-use, then you could stop scanning after you found the first receive tx. tevador: Addresses in Monero are not single-use. jeffro256: tevador: Fair rucknium: Going back to 2009 jeffro256: tevador: There could a specific address format which singles "hey don't use this twice please" jeffro256: signals tevador: Single use addresses would prevent the whole-wallet leak, but don't prevent the main problem of leaking the receiving transaction. jeffro256: tevador: It's the biggest leak if trying to conceal income. Not the biggest leak if trying to conceal purchases rucknium: I am developing the hypothetical with the sending adversary you don't trust fully, on privacy at least. So you would stop listening for txs after you got the one from the untrusted party. tevador: I think you can already do this with a throwaway wallet seed. rucknium: Yes. It would be a UX change. jberman: tevador sorry if this is included somewhere, but why is the 2/16 tx size so much larger than the 2/2 tx size for NTRU-509 than it is for the other algos? tevador: How would you do donation addresses with a single-use address format? tevador: jberman: Good question. NTRU needs 16 ciphertexts in that case, but CSIDH needs just 1 shared public key for all 16 outputs in option A. ixr3: It will take on tremendous importance! > It is important because it hides where the wallet sent their funds. They would also gain importance once people realize the PQ implications and begin using self-sends as such rucknium: BTCPay Sever does single-use addresses for Monero, which are used by at least one nonprofit for XMR donations. Just show each user a different address. rucknium: Server rucknium: Just thinking outside the box here. tevador: Do we want Monero to move to single-use addresses? Technically not publishing addresses ever (except to the sender) would solve the PQ privacy issue. ofrnxmr: Tracking a lot of subaddresses begins to take its toll on scanning though, unless you stop scanning one once used? rucknium: plowsof's Wishlist as a Service also shows each user a different address. sgp_: Single, static donation addresses have their place ofrnxmr: What happens if someone sends 2 txs to the same address? Would the 2nd tx be rejected? ofrnxmr: something like silent payments maybe? jeffro256: ofrnxmr: Not on CPU speed, just storage tevador: I think these services would be vulnerable a denial of service by generating 1000s of addresses but never sending anything. Then the wallet has to keep scanning. tevador: Also if interactive addresses are OK, we can just do this: monero-project/research-lab #106 rucknium: I didn't intend to distract so much from your question, tevador, about the best PQ encryption algorithm for the addresses. Can we have more comments on the options from meeting participants? jberman: I think privacy-preserving static addresses are a critical Monero feature gingeropolous: agree re: jberman tevador: Btw, Jamtis brings other improvements to addresses apart from PQ privacy. PQ privacy was means as an extra feature. rucknium: Reconsidering, if a service didn't offer the PQ addresses, then a competitor service could offer it. Market forces may squeeze out the non-adopter. Or at least there would be a good alternative for users who are aware of the quantum problem. tevador: Technically we could still go with classical Jamtis, which has 260-char addresses. jberman: I have a half debate in my head continuing about the acceptability of NTRU / a lattice based algo. Your arguments in favor of CSIDH are strong tevador , that's still where my head is at though rucknium: But many services have a lot of market power, i.e. close to a monopoly. rucknium: I will put this agenda item closer to the beginning next meeting. tevador: Thanks rucknium: More comments on this item? tevador: I didn't mention this, but NTRU and other KEMs have an extra issue in that the address generator tier can collude with the quantum attacker to deaononymize transactions. tevador: CSIDH doesn't have this issue. jberman: tevador: ack jpk68: Noob-ish question from me: is it really worth prioritizing smaller QR code sizes over shorter encoded address lengths? In my opinion, shorter addresses would be better from a UX perspective jpk68: (I'm referring to the use of Base32 over Base62/etc.) ixr3: rucknium: No, but I want to thank tevador for this very important work. It's hard to follow alongside all other developments going on tevador: base62 would shorten addresses only aby about 16% tevador: QR codes would become larger by 45% jpk68: Would there be any real-world difference when scanning/using the QR codes though? For example, would scanning a payment terminal be reasonably more difficult with higher-resolution QR codes? jpk68: I mean, of course it would (with insanely large codes) but with the 45% larger ones, I mean tevador: I'm not sure what is the max reasonable QR code size to scan with a phone jeffro256: Probably depends on camera quality and lighting jbabb: Stack Wallet uses QR codes to exchange FROST information and we found that up to about 4000 chars is usable jpk68: Just saying, from a UX perspective (in my opinion), a 16% decrease in address sizes is a 16% benefit for me. However a 45% larger QR code is about 0% less convenient, so long as the QR code is actually usable tevador: What QR code size is that? in modules rucknium: jbabb: Is that with zero error correction? IIRC, you can set different levels of error correction in a QR code. tevador: I think Jamtis in base32 would be 69x69 jpk68: I know this is probably just bikeshedding, but I thought it would be worth bringing up jbabb: tevador: 177x177, version 40 iirc, worked. but version 10-20 (57x57 to 97x97) is better and i think everything fits under these, ill have to check what the actual payloads are in practice tevador: 177x177 is the largest possible size AFAIK jbabb: was awhile since that work was done. versions 10-25 are practical imo jbabb: rucknium: I will have to recheck these details sorry, twas awhile back we integrated kaya's frost jpk68: I can't remember exactly, but when I looked into this a few days ago, the minimum QR code size that could be used for Base32 Jamtis addresses (13? 14?) had to be bumped up "only" two sizes from before tevador: I think the encoding format can be resolved later anyways tevador: I'm not opposed to base32 for the prefix + base62 for the data. tevador: Yes, I think it would go from version 13 to 15 jpk68: xmr1a is valid Base62 though, no? jpk68: Wrong prefix, oops tevador: YEs, but the prefix also includes the 24-char checksum jpk68: Oh, I see tevador: This one should stay case insensitive for human readability rucknium: We can end the meeting here. Feel free to continue discussing. Thanks everyone. tevador: Thanks ofrnxmr: I can generate a qr code right now for an example? jpk68: Thanks tevador: syntheticbird: In the prefix, that would be "li". In the data payload - nobody cares. rucknium: How would the PQ address work in hardware wallets? Is the checksum prefix enough to prevent accidental or malicious substitution of the address? tevador: Answer here: #523-visual-checksum" target="_blank" rel="nofollow noopener">gist.github.com/tevador/639d08… rucknium: Thanks. ofrnxmr: mrelay.p2pool.observer/m/monero.socia… ofrnxmr: 621 chars, seems to scan fine jpk68: In Base62? ofrnxmr: most of it vtnerd: Damn this may crush lwcli/monero-wallet-cli lol sgp_: mrelay.p2pool.observer/m/monero.socia… sgp_: 2953 test jpk68: ofrnxmr: Works for me, up to around 6 feet away (average Android phone) jbabb: scanned for me without even zooming it in. had to be 6in away from the screen tho jbabb: strangely, zooming in didn't really help (scannable at about a foot from the screen) tevador: Now make the version 40 qr code 5x5 cm and try to scan it jpk68: sgp_: 2,953 characters of Bech32? ofrnxmr: i zoomed the pic out so its only like 5cm across ofrnxmr: "this" = sgp's 2953 qr code jpk68: Are you using a telescope? Lmao sgp_: mrelay.p2pool.observer/m/monero.socia… sgp_: 4296 characters, alphanumeric (uppercase only) jpk68: tevador: the payload is 368 bytes for BC1024 sgp_: mrelay.p2pool.observer/m/monero.socia… sgp_: for 1379 characters alphanumeric, it fits in qr code version 34 with error correction level high tevador: So probably more like 617 chars in base32 sgp_: version 22 with error correction low UkoeHB: Why would QR codes be different sizes based on encoding? Can't encodings be translated? base-whatever -> QR code ideal -> QR code -> QR code ideal -> base-whatever sgp_: mrelay.p2pool.observer/m/monero.socia… jpk68: QR codes apparently have different modes, so if you restrict yourself to a smaller charset (i.e. Base32) you can encode more efficiently jpk68: I suppose one could encode the payload as a QR itself (in bytes) UkoeHB: Sure, my question is why QR encoding has to equal address encoding. tevador: UkoeHB: presumably we only want one address format (string). But yes, a binary address encoding would be tiny bit more efficient in QR codes UkoeHB: 45% doesn't seem tiny, unless you mean relative to b32 tevador: alphanumeric encoding encodes a 5-bit base32 character with 5.5 bits of encoding space, so the overhead is 10%. #c669723" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

Update on beta stressnet: kayabanerve completed a deeper review of the GBP fix, identifying a spec mismatch and implementing a new version that reduces the proof-size increase. Additional issues were opened on the fix repo. After weighing the low risk of further material changes to proof sizes or code paths (alpha stressnet caught issues independently of size), the team reached consensus to proceed with beta stressnet using the latest code/figures. Proposed fork date is May 6 (binaries next week after ofrnxmr's testing); the relevant table in seraphis-migration/monero #317 will be updated immediately after the meeting. jberman: We have an interesting update to consider for beta stressnet: kayabanerve has taken a deeper pass at the GBP fix and found a mismatch to spec (kayaba would be able to speak to it best). After another pass, a new impl reduced the increase to proof sizes an estimated 25% (need to confirm the exact figures still) kayabanerve: reduced the increase itself, not reduced the increase to just 25% relative to the old version jberman: kayaba has also opened further issues on the GBP fix repo: github.com/cypherstack/ge… kayabanerve: I just wanted to clarify what was reduced, how. I'll let you cite any exact numbers you want, jberman jberman: got it jberman: kayabanerve also mentioned that there is still further back and forth to be had with CS on it, but expects it to resolve as expected with these new figures jberman: That was also the case last week though, and we have new figures today tevador: Can this table be updated whent he new numbers are known? seraphis-migration/monero #317 jberman: Ya I'll do it right after this meeting tevador: Thanks jberman: Didn't get the chance tevador: So I guess we have also covered agenda item 5 jberman: So w.r.t beta stressnet, there is still an expected risk that there is some material change to proof sizes jeffro256: 12500 is still probably a decent choice for reference tx size jberman: It's an open question when exactly this GBP fix will be fully resolved jberman: So imo, we have virtually similar info as last week, and it probably still makes sense to move forward with beta jberman: The code is pretty much ready to proceed. We could set a date today jeffro256: So two choices: 1) go forward with beta, knowing that the proof size on beta may be ~8% bigger than mainnet. 2) wait until we know whether or not proof sizes will change sgp_: so beta tomorrow? /s tevador: I'd say go forward jberman: "knowing that the proof size on beta may be ~8% bigger than mainnet" kayabanerve has already implemented the changes, so we can use the latest sgp_: my completely uninformed opinion is to go forward jeffro256: Well done kayabanerve. A lot happened while I was sleeping last night ;) rucknium: How different will the code paths be if the proof size shrinks 8%? How big is the risk that beta stressnet would materially test the "wrong" code and there would be surprises on mainnet? jeffro256: I personally vote 1. Even if the proof size does change downwards slightly, the whole point of a stressnet is to stress tevador: Yeah, 8% more stress testing can't hurt jberman: Tbc, we can use the latest that implements the latest proof sizes with kayaba's expected fix fully implemented (which I'd advocate for using) rucknium: jberman: That sounds good to me jeffro256: So then there's two options for option 1 :): use bigger proof tx sizes (old), or 2) use smaller proof tx sizes (new) jberman: The risk to a further change in proof size imo is to the up or down, not necessarily certain to be smaller imo jeffro256: Fair jberman: rucknium: Imo the code paths are not likely to be materially impacted. Alpha stressnet e.g. caught tons of different issues where a change to proof size wouldn't have made them any less likely caught rucknium: I am OK with setting a beta stressnet start date today. jbabb: let's please proceed to stressnet beta even if minor changes may still be necessary jeffro256: rucknium: If the size / validation is off within a bound of 10%, the stressnet's stressing effects will overcome it either way. The only thing I could think of is some sort of a DoS bug in the new mainnet code that doesn't appear in the beta stressnet, but may be triggered in an edge case we didn't see jbabb: these github.com/cypherstack/ge… have been forwarded on and are being looked at jberman: jeffro256 and I have discussed a proposed fork date of 2 weeks from today, May 6th. I'd also like to have ofrnxmr do a quick round of testing, and then we release binaries next week rucknium: jberman: Sounds good to me #c669604" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

Cuprated v0.0.9 Molybdenite released! This is the last alpha version of Cuprate and it features a new database for 1 hour fast-sync on consumer hardware and usable HDD. For beta, RPC is also on its way with 2.6x faster wallet syncing than monerod. github.com/Cuprate/cuprat…

Full-Chain Membership Proofs (FCMP++) - The Next Generation of Monero's Privacy Thanks to @VOSTOEMISIO and @xenumonero for producing this excellent explanatory video and to our generous community for funding it!