Monero (XMR)

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!

We're pleased to share Revuo #Monero Issue 255: April 1 - 12, 2026 is now available! revuo-xmr.com/weekly/issue-2…

The audit of Serai's blockchain has completed! We are incredibly excited to have our node implement all of the required protocol functionality and to have received review from Security Research Labs @SecReLabs, leaders in the Substrate/Polkadot ecosystem.

ccs.getmonero.org/proposals/vtne… My new CCS is in funding! Upcoming: LWSF /feed unit testing, investigate (indirect) block limits, and new lib for encrypting wallet data with FIDO2. Done: LWS+F ready for fmcp++, LWS+F /feed implemented, monerolws.com, and Docker improvements.

Monero devs: FCMP++/CARROT hardfork proceeds on schedule with no further delays. CARROT key hierarchy integration deferred post-fork to preserve stability and momentum. Wallet API philosophy refined for simplicity; GPU-accelerated validation PoC (Slang/Vulkan) advancing; Seraphis migration prep underway. Full logs: libera.monerologs.net/no-wallet-left…

emsczkp presented the Bulletproofs* (BP*) folding scheme, demonstrating conceptual decoupling of the NARK prover from the folding prover; this enables third-party folding of already-generated proofs and has potential applications in Monero for block producers aggregating multiple-party proofs without secret knowledge, with the paper planned for peer-reviewed submission upon completion. emsczkp: Regarding questions posed in the previous MRL meeting by jberman, which I thank for valuable comments on the paper and questions: the folding prover does not necessarily have to coincide with the NARK prover. The NARK prover knows the original secret witness, whereas the folding prover operates on the NARK proofs. emsczkp: In BP*, NARK proofs are split into instance and witness parts. The folding prover takes both parts as input and performs the fold. Precisely, the witness data used here are those required by the (modified BP) algebraic verifiers for constraint checks and the commitment-consistency check. Such witness data differ from the original secret witness. emsczkp: So, to answer to jberman, the paper designs a folding scheme in which the NARK prover and the folding prover are conceptually decoupled. The folding prover does not need the original secret witness, but it does need the instance-witness parts for the proof and accumulator required by the folding relation. In that sense, a third party could fold already-generated NARK proofs. emsczkp: I would phrase the application level implications cautiously, since the paper itself at this stage focuses on the folding scheme design rather than a concrete deployment scenario. But, My current intuition is that this decoupling could be useful in applications where one entity produces proofs and another entity folds them. emsczkp: And that's the case, as also pointed out with jberman: github.com/monero-project… emsczkp: Here, BP* could potentially enable the idea outlined by kayabanerve, where a block producer folds many proofs from many parties without knowing secrets or interacting with parties. jberman: When we were initially discussing this CCS proposal, I expressed a desire / interest in seeing if the BP* design that could potentially enable exactly that^, so it's exciting to me that this potential is on the table with BP* jberman: I admit my math expertise is not deep enough to give a very strong review of the actual math itself, but it seems to pass a smell test with adequate rigor imo. It would be great to get it reviewed by those with the deeper math expertise, but generally I think this work is potentially bearing larger frui ts than was initially even proposed, and I'm cautiously optimistic about the direction rucknium: emsczkp: Do you plan to submit the paper to a peer-reviewed conference or journal when it is finished? emsczkp: yes, that's when all future works/steps will be addressed. #c665161" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

Status update confirmed that kayabanerve is completing the final task items for the FCMP beta stressnet, after which the network will be ready for launch and community testing. rucknium: 4. FCMP beta stressnet (github.com/seraphis-migra…). jberman: kayaba is working on last remaining task items, then we should be ready to go. #c665155" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

We're pleased to share Revuo #Monero Issue 254: February 27 - April 1, 2026 is now available! revuo-xmr.com/weekly/issue-2…

rucknium introduced Google's Quantum AI research on optimized Shor's algorithm circuits for ECDLP-256 (≈20-fold reduction in physical qubits), prompting discussion on accelerated urgency for Monero's post-quantum transition post-FCMP++; participants advocated prioritizing a complete PQ protocol design (building on tevador's PQ key-exchange work) and potentially contracting dedicated research teams, with post-quantum issues added to the next meeting agenda. rucknium: research.google/blog/safeguard… rucknium: quantumai.google/static/site-as… rucknium: Before the meeting, semisimple suggested a discussion, at some unspecified time, about Google's new lower estimates for breaking the discrete log problem. rucknium: Maybe people want to discuss a little now or we can agree to put it on the agenda next meeting. I don't know if there is a lot more to say than has already been said except for post-quantum is closer than expected. rucknium: Some discussion on the MRL GitHub repo: Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography (github.com/monero-project…). articmine: This is making the case for the acceleration of the post quantum issue. rucknium: > Specifically, we have compiled two quantum circuits (a sequence of quantum gates) that implement Shor's algorithm for ECDLP-256: one that uses less than 1,200 logical qubits and 90 million Toffoli gates and one that uses less than 1,450 logical qubits and 70 million Toffoli gates. We estimate that these circuits can be executed on a superconducting qubit CRQC with fewer than 500,000 physical qubits in a few minutes, given standard assumptions about hardware capabilities that are consistent with some of Google™'s flagship quantum processors. rucknium: > This is an approximately 20-fold reduction in the number of physical qubits required to solve ECDLP-256 and a continuation of a long history of gradual optimization in compiling quantum algorithms to fault-tolerant circuits. rucknium: I don't know how to interpret that or how many widgets can be stabilized for how long and in what timeline. vtnerd: They've still got to build a working prototype that does it, which is sort of the frustration in knowing when/if/maybe never jberman: After all FCMP++ / Carrot research tasks are complete, I'd advocate for a strong concerted effort on designing a complete PQ protocol. tevador has already begun on a PQ key exchange protocol here: github.com/monero-project… jberman: I think it may be worth contracting a research team on a full-time basis for that work rbrunner: As I see it, that's more or less the only "wiggle room" we realistically have: No more "conventional" improvements after the FCMP++, but directly onwards to PQ resilience rbrunner: *after the FCMP++ hardfork rbrunner: Maybe that proposal will be able to get "loose consensus" in the light of this Google paper ... rucknium: Should post-quantum issues be put on next week's agenda? rbrunner: I would give it a "why not" :) articmine: Yes syntheticbird: Yes rucknium: I will put it on the agenda. rbrunner: Getting a research team maybe just got a lot more difficult, if many more parties will take it seriously. rucknium: Or easier, because Monero can build on others' work :) rbrunner: "Dear Quantum researcher, don't work for Google, don't work at a world-class university, don't work for IBM, and so ... your place is at the side of the Monero team!" rbrunner: Well, we need post-quantum crypto researchers, but still articmine: rbrunner: The question is what other chains are taking this issue seriously. articmine: Starting with chains with a greater market cap than Monero #c665187" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

A proposal by jeffro to substantially speed up Monero light wallet server subaddress scanning. It comes with a negligible scanning time increase for most wallet end users. If the new method is implemented, the legacy method would remain available. github.com/vtnerd/monero-…

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!

Monero's RandomX v2 is released! 🎉 github.com/tevador/Random…