XMR Future

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…

Meet Kimi K2.6: Advancing Open-Source Coding 🔹Open-source SOTA on HLE w/ tools (54.0), SWE-Bench Pro (58.6), SWE-bench Multilingual (76.7), BrowseComp (83.2), Toolathlon (50.0), Charxiv w/ python(86.7), Math Vision w/ python (93.2) What's new: 🔹Long-horizon coding - 4,000+ tool calls, over 12 hours of continuous execution, with generalization across languages (Rust, Go, Python) and tasks (frontend, devops, perf optimization). 🔹Motion-rich frontend - Videos in hero sections, WebGL shaders, GSAP + Framer Motion, Three.js 3D. 🔹Agent Swarms, elevated - 300 parallel sub-agents × 4,000 steps per run (up from K2.5's 100 / 1,500). One prompt, 100+ files. 🔹Proactive Agents - K2.6 model powers OpenClaw, Hermes Agent, etc for 24/7 autonomous ops. 🔹Claw Groups (research preview) - bring your own agents, command your friends', bots & humans in the loop. - K2.6 is now live on kimi.com in chat mode and agent mode. For production-grade coding, pair K2.6 with Kimi Code: kimi.com/code - 🔗 API: platform.moonshot.ai 🔗 Tech blog: kimi.com/blog/kimi-k2-6 🔗 Weights & code: huggingface.co/moonshotai/Kim…

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!