<c​haser:monero.social> with the switch to Carrot, for new wallets, can we do away with the prefix difference between main and subaddresses (4... vs 8...)?

<c​haser:monero.social> also, am I correct assuming that...

<c​haser:monero.social> * ...for hardware wallets and wallets derived from 25-words mnemonics, the user will need to know the version of their wallet and choose it during the import flow?

<c​haser:monero.social> * ...for future Polyseeds (generated after the FCMP++ fork), this hell *could* be avoided if Polyseed and its implementations are updated in time to use one of the free feature bits to bump the wallet version?

Reminder for enthusiasts! MoneroKon 5 conference still seeks your ground-breaking ideas on security, privacy, and decentralization. Share your insights and be part of the dialogue. Submit your talk proposal today! Apply: cfp.twed.org/mk5/cfp

If not interested in applying at the moment, share with friends and privacy-adjacent communities!

<c​haser:monero.social> (cont.) assuming the latter point is correct, it would work reliably only for the bumped Polyseeds, since a user may not update the wallet they use for mnemonic generation by the fork date

<r​ucknium:monero.social> MRL meeting in this room in two hours.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1134

<r​ucknium:monero.social> 1) Greetings

<c​haser:monero.social> hello

<s​yntheticbird:monero.social> Hello

Hello

<r​ucknium:monero.social> Happy New Year

<j​berman:monero.social> *waves*

Likewise!

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<r​ucknium:monero.social> me: OSPEAD. Probably will be submitting milestone 2 next week.

<r​ucknium:monero.social> MoneroKon 2025 has posted its call for presentations. The submission deadline in March 25: cfp.twed.org/mk5/cfp

OSPEAD!? Nice!

Milestone 2 - Deliver initial probability density function to scientific review panel

<r​ucknium:monero.social> These plots are beautiful, I tell you

Looking forward. About time. :-P

Almost in sync with FCMP++!

<r​ucknium:monero.social> 3) Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography monero-project/research-lab #131

<r​ucknium:monero.social> In the last two meetings we discussed resistance to quantum counterfeiting attacks. Maybe we can discuss PQ privacy.

<s​yntheticbird:monero.social> I would like to ask a pretty dumb question. Under FCMP++, the breaking of a wallet with its public address by a QC, do not give adversary info on other public addresses used for its transactions?

<j​berman:monero.social> My update: testing my reimplementation of @kayabanerve's faster torsion check impl in order to speed up building the merkle tree for FCMP++. Moving back over to FCMP++ tx construction next

<s​yntheticbird:monero.social> s/FCMP++/Carrot/Jamtis

<s​yntheticbird:monero.social> my bad

<r​ucknium:monero.social> SyntheticBird: I have had the same question in my mind

<s​yntheticbird:monero.social> cool. The perfect forward secrecy make me think it isn't the case, otherwise one public address compromise all the underlying tx graph, but i have a doubt.

<c​haser:monero.social> SyntheticBird: TBH I'm not sure I understand your question and would value a rephrasing

<s​yntheticbird:monero.social> Afaik, on chain data are immune to quantum computer, as in no quantum adversary could break the transaction graph solely based on on-chain data. One limitation that has been shared however is that if a quantum adversary obtain a wallet public address, it can break the public key up to the wallet primary private key, compromising its privacy. The question is, does breaking a wallet<clipped me

<s​yntheticbird:monero.social> private key and therefore history, give access to this quantum adversary to other public addresses of wallet which has been transacted to.

<s​yntheticbird:monero.social> first paragraph, assuming FCMP++

<r​ucknium:monero.social> With respect to PQ privacy, there are some PQ RingCT proposals, but the tx sizes would be huge. And that would require going back to rings instead of having a FCMP-like privacy. IIRC kayabaNerve suggested that there may be more size-efficient PQ FCMP-like proposals.

Is this equivalent to the question whether having the private key allows the QC to break the stealth addresses in the transactions out of that wallet as well?

<a​rticmine:monero.social> The ballpark figure of ~50000 bytes is huge but doable

<s​yntheticbird:monero.social> rbrunner yeah thats equivalent, assuming of course in the context Carrot/Jamtis/FCMP++

<a​rticmine:monero.social> Sorry 500000 bytes

<a​rticmine:monero.social> For a TX

<c​haser:monero.social> SyntheticBird: got it. I'm not sure, and would like to know as well

Lacking details, I just assumed that they do continue to use something worth the name "stealth address" ...

<j​berman:monero.social> Pinging jeffro256. I may be wrong on this, but IIRC a break would compromise the wallet's seed, which an adversary could use to derive the wallet's other addresses

Isn't that a different question altogether?

<s​yntheticbird:monero.social> ah. that wasn't the point.

<s​yntheticbird:monero.social> its not about the wallet A's other addresses, but the addresses of other wallet B, C that wallet A transacted to

<j​berman:monero.social> Ah, I'm not sure

<s​yntheticbird:monero.social> mhm ig its time to panic

<c​haser:monero.social> FWIW, I know this wasn't the question, but a QC can't "connect" addresses of a Carrot wallet, it would imply being able to break the Blake2b hashing algo: github.com/jeffro256/carrot/blob/ma…d#613-subaddress-keys-new-hierarchy

<s​yntheticbird:monero.social> ig my question is over if we want to focus on economic stability of monero in the PQ era

<r​ucknium:monero.social> Here's one of the PQ RingCT papers by the way: Esgin, Steinfeld, and Zhao (2022). "MatRiCT+: More Efficient Post-Quantum Private Blockchain Payments" ieeexplore.ieee.org/document/9833655

<r​ucknium:monero.social> The use the "+" convention, too :D

<r​ucknium:monero.social> Double plus good.

<c​haser:monero.social> sorry jberman, just realized I restated the same thing you said

<c​haser:monero.social> but, to get back on topic, is it just me, or does a PQ migration with the current primitives and implementations mean putting up with very big, potentially impractical, addresses and tx sizes?

<s​yntheticbird:monero.social> chaser afaik yes, the current PQ primitives (Module lattices, Fourier transform based, Hash-based signature, NTRU) are all requiring much much bigger key or signature sizes

<s​yntheticbird:monero.social> maybe there is a way to cheat this from a UX perspective

<s​yntheticbird:monero.social> I don't think this represent a scalability challenge tho

<a​rticmine:monero.social> When Nielsen's Law of Bandwidth is factored in this is not that different from RingCT in 2017

<s​yntheticbird:monero.social> I'll note tho. tevador seraphis-pq draft didn't tested S-NTRU.

<c​haser:monero.social> I hope so. one thing that's hard to cheat on is address length. I've had doubts even about 244 characters in Jamtis-RCT

<r​ucknium:monero.social> Animated address QR codes will be embedded in a little movie so at least users are entertained while their device reads them.

<s​yntheticbird:monero.social> NTRU sizes for reference: ntruprime.cr.yp.to/security.html

<s​yntheticbird:monero.social> Ok now that i see that I might understand why it wasn't shared. It's KEM not DSA

<s​yntheticbird:monero.social> my bad

<c​haser:monero.social> this, or encoding over the UTF-8 character space. I'm personally undecided

<r​ucknium:monero.social> IIRC Brandon Goodell (surae) was working on PQ lattice cryptography before joining Cypher Stack.

<f​ede:xmr.mx> Maybe sharing a 32-byte hash of the actual address, which must be registered in a sort-of DHT.

<s​yntheticbird:monero.social> yeah i think we heard of that idea before.

<c​haser:monero.social> it would be good to have him on board for this topic.

Before I worry too much about those lengths I will have a look what the quantum proofing research will bring in the next few years. Won't hardly stand still, I think.

<c​haser:monero.social> I really don't like those approaches, but if something really has to give, on-chain registration is an option too.

<c​haser:monero.social> Kayaba's Monerokon 2024 "unorthodox crypto for scaling" presentation may be adjacent related

<c​haser:monero.social> rbrunner: very much indeed. I expect many novelties and optimizations. I don't know though how much we can afford waiting for those to become realized.

Agree

At least Monero "knows how to hardfork" if something decidedly better comes around ...

<j​effro256:monero.social> Knowing address A does not reveal the sender of transactions that address A received XMR in. It also doesn't reveal which *other* addresses receive XMR to funded by those enotes. But if the QC knows of *any* public address of wallet A as well as wallet B, if can see that A sent B funds if there wasn't a churn in between to the "internal" view-balance secret

<j​effro256:monero.social> Sorry for being so darn late

<f​ede:xmr.mx> On-chain registration has UX issues: you must either pay a transaction fee for registering an address, which means it's impossible for newcomers to register it, or solve a PoW puzzle, which can frustrate users with long wait time. I'd rather use a non-permanent off-chain DHT which is less subject to scalability issues.

<s​yntheticbird:monero.social> Thanks, that confirm that we can use disposable wallets for receiving funds and then send them an internal wallet and have QC protection

<j​effro256:monero.social> But if wallet A receives some XMR, then churns it back to itself using the new Carrot key hierarchy, *then* sends it to wallet B, even though a QC could know the private view-incoming key for both wallet A and B, it can't say for certain that the funds moved from A->B. It could perform probabilistic timing and amount analysis, but there isn't a deterministic link

<c​haser:monero.social> fede: that's true.

<j​effro256:monero.social> Yeah at that point the privacy becomes similar to a cleartext amount BTC mixer under a quantum adversary. If a QC can see that wallet A received 398737693740037 pXMR, and then wallet B shortly thereafter received 398737693740037 - fee pXMR, then they can say with high probability that the funds were likely transferred A->B

<j​effro256:monero.social> So *transferred* amount quantization as well as fee quantization is something we would likely want to look at in the future for posterity's sake

<r​ucknium:monero.social> Having really high XMR precision must have seemed so clever at the time ;)

<r​ucknium:monero.social> at the time it was decided, I mean. I guess that was Bytecoin that decided that

<j​effro256:monero.social> Also you don't need a disposable wallet the way that Carrot key hierarchy is written, there is a symmetric secret used solely in hash functions that shouldn't *ever* leak due to ECC arithmetic. All change enotes are sent to this secret, which automatically makes change/selfsend forward secret *unconditionally*

<j​effro256:monero.social> Existing wallets don't get this feature, and must migrate, but once migrated, this feature is completely opaque to the user

<a​rticmine:monero.social> A caution here is that probabilistic guessing can still be used to falsely accuse the innocent

<j​effro256:monero.social> Yes, of course, but we can give them ammo to try if we're not careful

<a​rticmine:monero.social> I agree we must eliminate the illusion of surveillance

<s​yntheticbird:monero.social> jeffro256 would you happen to know a bit more about PQ primitives? we were talking size and practicality, do you know if there are ways to avoid this in the future

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone.

<s​yntheticbird:monero.social> thanks

<a​rticmine:monero.social> Thanks

<j​effro256:monero.social> Thanks !

<j​effro256:monero.social> Well basically the one thorn in the side of FCMP++ forward secrecy at the moment is the Diffie-Helman key exchange against the public addresses. All Carrot/Jamtis/legacy addresses easily reveal the private view key to a quantum computer, so getting rid of discrete log based key exchanges would more or less solve all on-chain privacy issues. There's multiple different ways to get r<clipped messag

<j​effro256:monero.social> id of discrete log based key exchanges, but they mostly fall under two categories: 1) use a PQ key exchange, or 2) don't do an on-chain key exchange at all

<s​yntheticbird:monero.social> Oh the second option was tevador proposal iirc

<j​effro256:monero.social> I recommend reading the discussion in monero-project/research-lab #106 for discussion of the latter

<j​effro256:monero.social> That's something that is doable in the very near future without a lot of cryptography research needed

<j​effro256:monero.social> It changes UX for sure though, don't get me wrong

<j​effro256:monero.social> I think that people should start looking at and getting familiar with off-chain key exchanges, since it's an option much more accessible to developers who aren't familiar with PQ cryptography

<j​effro256:monero.social> And it doesn't involve any changes to the transaction format, and as such, doesn't require widespread consensus

<j​effro256:monero.social> So good for experimentation and getting PQ privacy sooner rather than later

<c​haser:monero.social> since a SPHINCS+ pub key that targets 128-bit security is 32 bytes long (sphincs.org/data/sphincs+-r3.1-specification.pdf#page=58, Table 8), isn't that conducive to a PQ addressing scheme with the same base58 address lengths as we have today?

<s​yntheticbird:monero.social> Yes but SPHINCS+ signature are HUGE

<s​yntheticbird:monero.social> Last time i tested asurar0 PQ tool, the signature was like 40kB or smth

<j​effro256:monero.social> You wouldn't need signatures for a key exchange AFAIK

<s​yntheticbird:monero.social> jeffro256 KEM based KEX ?

<s​yntheticbird:monero.social> S-NTRU might return into play if its the case

<c​haser:monero.social> SyntheticBird: yeah, for now I'm just brainstrorming and handwaving every other problem away by e.g. hoping Nielsen's Law will hold. compute/bandwidth/storage/power can get cheaper over time, human attention and human willingness is much less likely to do so.

<s​yntheticbird:monero.social> SNIPPERRR!!!

<s​yntheticbird:monero.social> everyone take cover