08:41:06 <m-relay> <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...)?
09:34:33 <m-relay> <c​haser:monero.social> also, am I correct assuming that...
09:34:37 <m-relay> <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?
09:35:08 <m-relay> <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?
09:50:35 <dukenukem> 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: http://cfp.twed.org/mk5/cfp
09:50:44 <dukenukem> If not interested in applying at the moment, share with friends and privacy-adjacent communities!
09:54:51 <m-relay> <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
15:00:54 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in two hours.
17:00:39 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/1134
17:00:46 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:01:04 <m-relay> <c​haser:monero.social> hello
17:01:05 <m-relay> <s​yntheticbird:monero.social> Hello
17:01:07 <rbrunner> Hello
17:01:23 <m-relay> <r​ucknium:monero.social> Happy New Year
17:01:24 <m-relay> <j​berman:monero.social> *waves*
17:02:12 <rbrunner> Likewise!
17:03:01 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:03:36 <m-relay> <r​ucknium:monero.social> me: OSPEAD. Probably will be submitting milestone 2 next week.
17:04:10 <m-relay> <r​ucknium:monero.social> MoneroKon 2025 has posted its call for presentations. The submission deadline in March 25: https://cfp.twed.org/mk5/cfp
17:06:29 <dukenukem> OSPEAD!? Nice!
17:07:00 <dukenukem> Milestone 2 - Deliver initial probability density function to scientific review panel
17:07:03 <dukenukem> https://ccs.getmonero.org/proposals/Rucknium-OSPEAD-Fortifying-Monero-Against-Statistical-Attack.html
17:07:06 <m-relay> <r​ucknium:monero.social> These plots are beautiful, I tell you
17:07:26 <dukenukem> Looking forward. About time. :-P
17:07:35 <dukenukem> Almost in sync with FCMP++!
17:08:01 <m-relay> <r​ucknium:monero.social> 3) Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography https://github.com/monero-project/research-lab/issues/131
17:08:59 <m-relay> <r​ucknium:monero.social> In the last two meetings we discussed resistance to quantum counterfeiting attacks. Maybe we can discuss PQ privacy.
17:09:11 <m-relay> <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?
17:09:12 <m-relay> <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
17:09:37 <m-relay> <s​yntheticbird:monero.social> s/FCMP++/Carrot/Jamtis
17:09:42 <m-relay> <s​yntheticbird:monero.social> my bad
17:10:18 <m-relay> <r​ucknium:monero.social> SyntheticBird: I have had the same question in my mind
17:11:07 <m-relay> <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.
17:13:18 <m-relay> <c​haser:monero.social> SyntheticBird: TBH I'm not sure I understand your question and would value a rephrasing
17:16:26 <m-relay> <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
17:16:28 <m-relay> <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.
17:16:50 <m-relay> <s​yntheticbird:monero.social> first paragraph, assuming FCMP++
17:19:22 <m-relay> <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.
17:20:50 <rbrunner> 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?
17:21:21 <m-relay> <a​rticmine:monero.social> The ballpark figure of  ~50000 bytes is huge but doable
17:21:43 <m-relay> <s​yntheticbird:monero.social> rbrunner yeah thats equivalent, assuming of course in the context Carrot/Jamtis/FCMP++
17:21:47 <m-relay> <a​rticmine:monero.social> Sorry 500000 bytes
17:22:21 <m-relay> <a​rticmine:monero.social> For a TX
17:22:26 <m-relay> <c​haser:monero.social> SyntheticBird: got it. I'm not sure, and would like to know as well
17:22:27 <rbrunner> Lacking details, I just assumed that they do continue to use something worth the name "stealth address" ...
17:22:57 <m-relay> <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
17:23:48 <rbrunner> Isn't that a different question altogether?
17:24:02 <m-relay> <s​yntheticbird:monero.social> ah. that wasn't the point.
17:24:02 <m-relay> <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
17:25:52 <m-relay> <j​berman:monero.social> Ah, I'm not sure
17:26:34 <m-relay> <s​yntheticbird:monero.social> mhm ig its time to panic
17:28:28 <m-relay> <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: https://github.com/jeffro256/carrot/blob/master/carrot.md#613-subaddress-keys-new-hierarchy
17:30:49 <m-relay> <s​yntheticbird:monero.social> ig my question is over if we want to focus on economic stability of monero in the PQ era
17:31:06 <m-relay> <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" https://ieeexplore.ieee.org/document/9833655
17:31:23 <m-relay> <r​ucknium:monero.social> The use the "+" convention, too :D
17:31:33 <m-relay> <r​ucknium:monero.social> Double plus good.
17:35:07 <m-relay> <c​haser:monero.social> sorry jberman, just realized I restated the same thing you said
17:38:27 <m-relay> <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?
17:39:54 <m-relay> <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
17:40:17 <m-relay> <s​yntheticbird:monero.social> maybe there is a way to cheat this from a UX perspective
17:40:32 <m-relay> <s​yntheticbird:monero.social> I don't think this represent a scalability challenge tho
17:41:25 <m-relay> <a​rticmine:monero.social> When Nielsen's Law of Bandwidth is factored in this is not that different from RingCT in 2017
17:42:39 <m-relay> <s​yntheticbird:monero.social> I'll note tho. tevador seraphis-pq draft didn't tested S-NTRU.
17:43:05 <m-relay> <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
17:44:06 <m-relay> <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.
17:44:15 <m-relay> <s​yntheticbird:monero.social> NTRU sizes for reference: https://ntruprime.cr.yp.to/security.html
17:45:08 <m-relay> <s​yntheticbird:monero.social> Ok now that i see that I might understand why it wasn't shared. It's KEM not DSA
17:45:41 <m-relay> <s​yntheticbird:monero.social> my bad
17:47:40 <m-relay> <c​haser:monero.social> this, or encoding over the UTF-8 character space. I'm personally undecided
17:48:12 <m-relay> <r​ucknium:monero.social> IIRC Brandon Goodell (surae) was working on PQ lattice cryptography before joining Cypher Stack.
17:48:20 <m-relay> <f​ede:xmr.mx> Maybe sharing a 32-byte hash of the actual address, which must be registered in a sort-of DHT.
17:48:35 <m-relay> <s​yntheticbird:monero.social> yeah i think we heard of that idea before.
17:49:21 <m-relay> <c​haser:monero.social> it would be good to have him on board for this topic.
17:49:41 <rbrunner> 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.
17:50:50 <m-relay> <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.
17:51:44 <m-relay> <c​haser:monero.social> Kayaba's Monerokon 2024 "unorthodox crypto for scaling" presentation may be adjacent related
17:55:10 <m-relay> <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.
17:56:21 <rbrunner> Agree
17:57:41 <rbrunner> At least Monero "knows how to hardfork" if something decidedly better comes around ...
17:57:51 <m-relay> <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
17:58:00 <m-relay> <j​effro256:monero.social> Sorry for being so darn late
17:58:24 <m-relay> <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.
17:59:09 <m-relay> <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
17:59:38 <m-relay> <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
18:00:46 <m-relay> <c​haser:monero.social> fede: that's true.
18:01:29 <m-relay> <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
18:02:07 <m-relay> <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
18:02:24 <m-relay> <r​ucknium:monero.social> Having really high XMR precision must have seemed so clever at the time ;)
18:02:46 <m-relay> <r​ucknium:monero.social> at the time it was decided, I mean. I guess that was Bytecoin that decided that
18:04:01 <m-relay> <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*
18:04:43 <m-relay> <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
18:04:58 <m-relay> <a​rticmine:monero.social> A caution here is that probabilistic guessing  can still be used to falsely accuse the innocent
18:05:27 <m-relay> <j​effro256:monero.social> Yes, of course, but we can give them ammo to try if we're not careful
18:06:46 <m-relay> <a​rticmine:monero.social> I agree we must eliminate the illusion of surveillance
18:08:11 <m-relay> <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
18:08:12 <m-relay> <r​ucknium:monero.social> We can end the meeting here. Thanks everyone.
18:08:16 <m-relay> <s​yntheticbird:monero.social> thanks
18:13:33 <m-relay> <a​rticmine:monero.social> Thanks
18:14:23 <m-relay> <j​effro256:monero.social> Thanks !
18:17:54 <m-relay> <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
18:17:54 <m-relay> <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
18:18:37 <m-relay> <s​yntheticbird:monero.social> Oh the second option was tevador proposal iirc
18:18:46 <m-relay> <j​effro256:monero.social> I recommend reading the discussion in https://github.com/monero-project/research-lab/issues/106 for discussion of the latter
18:19:13 <m-relay> <j​effro256:monero.social> That's something that is doable in the very near future without a lot of cryptography research needed
18:19:28 <m-relay> <j​effro256:monero.social> It changes UX for sure though, don't get me wrong
18:21:13 <m-relay> <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
18:21:51 <m-relay> <j​effro256:monero.social> And it doesn't involve any changes to the transaction format, and as such, doesn't require widespread consensus
18:22:16 <m-relay> <j​effro256:monero.social> So good for experimentation and getting PQ privacy sooner rather than later
18:35:35 <m-relay> <c​haser:monero.social> since a SPHINCS+ pub key that targets 128-bit security is 32 bytes long (https://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?
18:36:14 <m-relay> <s​yntheticbird:monero.social> Yes but SPHINCS+ signature are HUGE
18:36:54 <m-relay> <s​yntheticbird:monero.social> Last time i tested asurar0 PQ tool, the signature was like 40kB or smth
18:37:03 <m-relay> <j​effro256:monero.social> You wouldn't need signatures for a key exchange AFAIK
18:38:11 <m-relay> <s​yntheticbird:monero.social> jeffro256 KEM based KEX ?
18:38:28 <m-relay> <s​yntheticbird:monero.social> S-NTRU might return into play if its the case
18:45:37 <m-relay> <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.
18:52:11 <m-relay> <s​yntheticbird:monero.social> SNIPPERRR!!!
18:52:12 <m-relay> <s​yntheticbird:monero.social> everyone take cover