02:16:57 Naive questions: 02:16:57 With FCMP++, what will be revealed if ECC/SCIDH is broken? 02:16:57 Privacy? the addresses of senders and receivers, the amounts 02:16:57 or[... more lines follow, see https://mrelay.p2pool.observer/e/v46RpokLNEdQbmF6 ] 02:18:21 FCMP++ does not use CSIDH, that would be Jamtis :) 02:26:07 Fine, my question is, for monero, PQC updates are solving privacy or security issues? or both? 02:26:44 I will decide whether to update my wallets. 02:40:20 Grok says: With Jamtis, privacy holds but security breaks if ECDLP is broken.🥶 02:51:37 @yushanren:matrix.org: pq is presumably ensuring the curves involved at XMR aren't compromised by something with a ton of logical qubits. 02:52:01 https://scottaaronson.blog/?p=9718 02:55:12 FCMP++ improves PQ privacy (a quantum adversary would need your address in order to compromise your privacy, and you inherit this protection for new addresses in any wallet after the fork that are unused prior to the fork) 02:55:32 Jamtis-PQ would improve PQ privacy further (a quantum adversary that has your address would need to break both ECDLP and CSIDH in order to definitively see your received enotes) 02:55:36 Neither solve that a quantum adversary could print coins out of thin air undetectably 02:57:34 What will happen to the old transfers and addresses? 02:58:11 > a quantum adversary that has your address would need to break both ECDLP and CSIDH 02:58:11 if only a quantum adversary were unable to parse this search space for such keys at the first place (ECDLP and CSIDH, respectively) 02:58:43 @yushanren:matrix.org: Practically everything on the blockchain currently will be deanonymized at some point 02:59:08 @jpk68:matrix.org: this is a problem. 03:10:57 Yes, there should be a way to prevent compromised keys to move funds with old addresses. This is so painful. 03:12:31 You want to own you wallets with your keys. However, you also want people with your keys cannot move your funds. 03:58:10 https://github.com/monero-project/research-lab/issues/151#issuecomment-4608938308 > fireine: The three comments I wrote are my main critique of the write-up. Any responses to that? 04:04:38 Indeed, the response to all three critiques is the same: you're presumably critiquing the (yet unoptimized) Lean file as a design document when it's actually a proof of concept for an existing behavior. 04:05:53 this dialogue demonstrates that what tevador calls a "design choice" has a concrete consequence: an auditor with a view key can be shown a balance that differs from what the chain actually contains, which is either a feature or a bug depending on who you ask, but either way it exists and works today. 04:23:10 The source is the seed phrase. If it is weak, there is no secret. If it is not, you can always derive keys and add them to old ones. 04:27:38 @yushanren:matrix.org: I don't want to get too theoretical here. But key generation / management needs a good source of entropy. Indeed, you do not want a low entropy seed phrase or xpriv in general. The bigger problem is the fact that all keys are in the same search-space at the specific computational universe at which they exist. But at 2026 this isn't such an important problem. For now :) 04:37:50 No way to decrypt seed phase? 05:06:44 jpk68: twofish because it's the right size, efficient, well established, and had a usable C implementation. 08:37:00 fireine: You still haven't addressed the merit of my critique. For example, how would opt-in linkability work without introducing double spending vulnerabilities? 12:59:18 tevador: sorry for the delay. typhoon #6 in Japan and was checking up on some friends. I'll put that data in shortly. 13:19:49 > YEs, this is the most recent version 13:19:49 tevador we can't seem to find the key-management section at Appendix B? Is the key management / generation section at Jamtis interactive protocol yet unpublished? dabo⊙cse told me long ago that most companies in general get this wrong and think this might be a useful addition. All I see is forward secrecy propertie [... too long, see https://mrelay.p2pool.observer/e/4OCMuYkLZnFNb3kz ] 13:19:49 https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96?permalink_comment_id=5060622#gistcomment-5060622 13:30:21 To be brutally honest — even if Jamtis's interactive protocol generates ephemeral keys off-chain, consumer hardware entropy sources are historically unreliable and architecturally bounded, meaning the effective keyspace is smaller than the nominal cryptographic parameters assume. Against a permanent public ledger where harve [... too long, see https://mrelay.p2pool.observer/e/k5azuYkLWmhtUW1a ] 13:31:47 though I admit my projection is perhaps a bit pedantic. just pointing my policy finger at the structural incompatibility between the security assumptions of public-key cryptography in general (uniform random keyspace) and the physical reality of the deployment environment (bounded consumer entropy). 13:33:16 It’s not the problem with Monero, but the problem of all cryptos. 13:35:32 @fireine:matrix.org: As it says in the gist's title, it's a draft still 13:36:25 @jpk68:matrix.org: Indeed, tevador said nothing was yet unpublished so injected this data bc I had assumed there was nothing else to add. 13:37:04 for example, the data @freeman:cypherstack.com injected is yet unrefined 13:37:06 "consumer hardware entropy sources are historically unreliable and architecturally bounded, meaning the effective keyspace is smaller than the nominal cryptographic parameters assume." Can you point to papers on this problem? I'm interested. 13:40:10 @rucknium: https://mrelay.p2pool.observer/m/matrix.org/zCakDksMhuxZDdFTfaKcXAdZ.png (turing-award.png) 13:40:43 everything the Jamtis defender is relying on sits at the "?" column 13:42:50 avi's blackboard shows that even at theoretical computer science, exponential lower bounds are marked '!' only where proven and '?' everywhere cryptography actually relies on them - and consumer hardware entropy adds a third '?' that no one has answered. 13:44:15 I sometimes use dice for important stuff. Do we all get to use dice now? :D 13:44:39 I was looking for a paper citation instead of a photo of a blackboard. 13:46:04 @rucknium: this is a research chat. most mathematicians usually collaborate using blackboards. usually at the same physical location. 13:46:49 https://crypto.stanford.edu/RealWorldCrypto/slides/nadia.pdf 13:47:40 Thanks. 13:58:47 fireine: You are reading "JAMTIS-RCT [OBSOLETE]", which is obsolete as stated in the title. The correct link is: https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832 14:01:59 tevador: I linked a comment I made at the obsolete version but your new version still doesn’t have the key management section. 14:02:13 This is an important section. 14:03:32 Also here is a reply to your critique of CSIDH: https://github.com/monero-project/research-lab/issues/151#issuecomment-4610471041 14:04:12 Jamtis Appendix B is still a work in progress. 14:05:22 tevador: The lack of an explicit key management section is a problem bc if an auditor is skimming the spec they might miss a section they’d otherwise fail to scrutinize (this is smth that cannot be overlooked) 14:07:58 tevador: as is @freeman:cypherstack.coms Fraus implementation at view-key evasion | opt in linkability. 14:15:31 Does that mean you have no idea yet how to do opt-in linkability without double spending vulnerabilities? 14:22:53 tevador: I'll start by saying that, in part, I agree bc isogenies are genuinely exciting, and dismissing them purely because substantial cryptanalysis hasn't been done yet isn't a serious position (those people are idiots). You don't need a thousand people to confirm a shiny rock is a shiny rock. It's shiny. That said, the Eur [... too long, see https://mrelay.p2pool.observer/e/peHzuokLX0VyMXhv ] 14:23:21 tevador: the implementation is trivial. academic responsibilities rn and will put the data in soon. 14:25:21 tevador there is much more to unpack at that repo vs just that monolithic lean fragment. more on this later - but it builds at Fieckert's past work as well. 14:25:25 who also has repo access. 14:40:58 that being said, if you are interested at what our pq implementation in general might look like for monero specifically we might be interested in sharing iff it can be done via private channels (via email). but only if you don't strongly object to such data, tevador (assuming I get approval from reuben⊙fo to do so) 14:45:02 http://ecdsa.fail/ 14:45:03 Why would it need to be done via private channel? 14:46:11 @rucknium: ask reuben⊙fo 14:47:02 @fireine:matrix.org: @reuben:firo.org: Why would this ^ need to be done via private channel? 14:52:29 You're free to share it with them @fireine:matrix.org but don't know if I should make the repo public if I'm going to put in this position 14:54:39 @reuben:firo.org: https://mrelay.p2pool.observer/m/matrix.org/kigFkTxyaZHRNHcEHzCiZbqG.png (Screenshot 2026-06-03 at 10.49.38 AM.png) 14:54:44 That's how many years ago 14:54:50 @reuben:firo.org: the repo should probably stay private for now. 14:54:51 once it's complete I'll fire it off to you before sharing. 14:56:11 Thanks. I didn't mean to put pressure on anyone. I'm just trying to understand the context. 14:56:57 @rucknium: I also dmed you 15:00:24 can researchers stop researching in the research channel please. 15:05:27 MRL meeting in this room in two hours. 15:06:34 I'll need to delay the decision on helios/selene until next week, but we did receive 7 proposals 16:05:01 I'm actually online for once. Send praise and deposits to the following address ... 17:00:24 Meeting time! https://github.com/monero-project/meta/issues/1399 17:00:28 1. Greetings. 17:00:36 Hi 17:00:38 waves 17:00:47 hi 17:00:47 Hi 17:01:03 Hello 17:01:17 hi 17:01:23 Hello 17:01:25 Hello 17:02:12 2. Updates. What is everyone working on? 17:02:14 * br-m waves 17:03:20 Polyseed support for the Wallet RPC server, the last bigger chunk 17:03:20 me: posted zmq-pub code that leverages cbor instead of msgpack after feedback and perf testing 17:04:10 Hi 17:04:21 me: completed FCMP++ audit remediation tasks, chasing down windows GUI crashing on stressnet, PR review 17:04:31 and working on ssl stuff! almost forgot about that. Im going to address selstastuff and then start a pr to beta-stressnet 17:05:37 3. Post-quantum encryption (https://github.com/monero-project/research-lab/issues/151#issuecomment-4412416686) 17:05:46 No notable updates from me, I'm working on Jamtis Appendix B (interactive payment protocol). 17:05:56 I’ll shill episode 2 of plaintext on divisors: https://youtu.be/-Ae0AUBG2Mg 17:06:14 Hi, will be reviewing the jamtis-pq draft, maybe start implementing it 17:11:31 [waiting on someone to finish typing on Matrix side] 17:12:27 (nothing from me sorry) 17:13:19 sgp may have something to say. Or his elbow is on the keyboard. 17:13:43 4. Monero-PSK (https://gist.github.com/tevador/9169235b3c0c97e735f58a8c2ba92502) 17:14:12 I'm proposing to skip this agenda item unless spirobel is here. 17:14:30 Ok. Any other comments on PSK? 17:14:55 I think spirobel just needs to clarify his ideas on that front to move that forward 17:15:30 5. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/) 17:16:12 v2.0 seems to be going smooth for now. Spamming hasn't kicked into gear yet 17:16:15 My monitors for the new stressnet are up and running: https://stressnetnode1.redteam.cash/ https://stressnetnode2.redteam.cash/ https://stressnetconsensus1.redteam.cash/ https://stressnetconsensus2.redteam.cash/ 17:16:38 I'm working on a windows GUI binary crash at the moment 17:17:07 Just curious, can you use a proper debugger there now? 17:17:26 no, I don't have a good dev env for windows 17:17:51 but I think I'm close to getting at the cause of the issue 17:18:30 rbrunner: you can capture a crash dump with prodcump and run it through WinDbg. used that to produce the crash report for the issue 17:18:49 hola 17:18:58 Ah, I see. That makes sense. 17:21:01 More on stressnet? 17:21:28 6. FCMP++ integration audit (https://github.com/seraphis-migration/monero/issues/294) 17:23:35 Reminder context: Trail of Bits completed phase 1, minus a task item. We're working internally on managing that task item (would prefer to kick discussion of this til next week) 17:24:35 I also haven't had a good chance to deeply review Cypher Stack's audit (much appreciated for that work, thank you guys again) 17:24:45 But what has been reviewed so far has all "passed" so to speak. Neither ToB nor Cypherstack found issues beyond informational so far 17:25:28 Zcash just patched a critical counterfeiting bug via hard fork: https://forum.zcashcommunity.com/t/orchard-vulnerability-successfully-remediated/55976#p-248390-technical-details-5 . It looks like it was a problem with a code loop, not a problem with the mathematical theory. That shows how important the code integration audit is :) 17:26:11 By next week, I'll try to have all code prepped for phase 2 as well so that can move forward 17:26:38 Zcash has a safety net. They have a turnstile that prevents counterfeiting supply from increasing the total supply in the transparent pool. Monero does not have that. Thanks to selsta for pointing out the Zcash developments. 17:27:56 FWIW the equivalent bug would actually not be in the scope of this code integration audit, and it would still be something on the Rust side in @kayabanerve:matrix.org 's FCMP++ lib. And that side is getting (and has gotten) audited rigorously 17:28:00 uhm, i'm not sure if i would say our implementation audit at cypher stack is "passing" 17:28:20 we raised an issue about the view-all key 17:28:21 i'm not sure if this is the best time to bring it up 17:28:41 but we are concerned for a few reasons 17:28:50 namely, the view-all key advertised in the CARROT spec is not a view-all key. it's an opt-in view key 17:28:59 @brandon:cypherstack.com: Sure. Go ahead and bring it up. 17:29:08 That was unrelated to phase 1 of the integration audit 17:29:09 @brandon:cypherstack.com: Indeed, I wouldn't have lobbied for this if it was trivial. 17:29:54 so, for the folks listening, there is a way to construct a transaction to a wallet, which you've given the view key access to an auditor, but for which the auditor does not see the incoming transaction 17:30:10 this is similar to sending money to a wallet the auditor does not know about 17:30:17 however, it is distinct 17:30:23 Maybe I am not fully understanding, but I find this ironic because some community members were worried that the Carrot view key would give "viewers" too much information. Now, is this new finding a feature or a bug? 17:30:46 an auditor with your view key may see some outgoing transactions to yourself, but not incoming transactions, and conclude you have a negative balance 17:30:51 And I think it can do things that just sending money to a new wallet cannot 17:31:06 i view this as a bug, unconditionally, in the sense that the key was advertised as a view-all key, but it is not. 17:31:17 @brandon:cypherstack.com: bc it is. 17:31:26 the bug is buggy 17:31:29 Cuz it is lol 17:31:34 whether this practically impacts the security surface is a different question, because someone could always send money to a wallet the auditor doesn't know about 17:31:52 Otherwise everything runs perfectly ok with those "hide from view-all key holder" transactions? 17:32:33 Is @jeffro256:monero.social present? 17:32:51 Just throwing this out there: this could actually be nice to have, if it can work that way. None of the benefits with regards to hardware wallets/LWS seem to be removed, meanwhile it could also reduce FUD around mandatory key-sharing and whatnot 17:32:56 rbrunner: we haven't identified other broken parts yet, but we suspect that the same problem may just appear in multiple spots in carrot, soi it may be that there are many ways to do this 17:33:16 there is a simple fix which is to include a verifiable random function (VRF) proof that a certain piece of randomness was computed verifiably randomly, one for each transaction output 17:33:26 this would inflate FCMP transaction sizes, but would guarantee that view-all keys are view-all 17:33:39 @jpk68:matrix.org: this is a common attitude, but here's my concern 17:33:48 Ok, but probably otherwise no other disadvantages? E.g. perfect restore from seed with such transactions received, right? 17:34:25 advertising view access but not actually having it may piss off exchanges who are trying to comply with kyc/aml, and this may lead to them deciding that monero is no longer compliance-friendly. which is incorrect, because the new view keys are less broken than the current view keys lol 17:34:28 ... wouldn't that imply they sent to a different wallet, just one with overlapping other keys? 17:34:39 rbrunner: yeah we think so 17:34:56 Like, same internal view key, different view key 17:35:12 Interesting. 17:35:25 no, it just means they didn't use ScalarDerive on something appropriately, instead picking a random number 17:35:37 same wallet keys 17:35:43 I agree that's a bug, not a feature. People who don't want view-all keys existing shall use the old 2-key wallet format ... 17:36:17 With or without holes 17:36:29 @jberman: as a sort of pedantic point of order, I want to underline this as well 17:36:30 that what Freeman and surae are discussing is outside of the scope of the phase 1 integration audit except insofar as that Freeman found it while reviewing the underlying math while we were doing integration audit phase 1 17:36:40 rbrunner: which is what was stated. 17:36:43 perhaps you underestimate us lol 17:37:01 Was there a "Carrot the crypto and the math" audit that overlooked this? 17:37:02 So if the sender creates an unscannable TX, but the opening is communicated out-of-band, then...? 17:37:35 By another party, I mean 17:38:02 > <@brandon:cypherstack.com> advertising view access but not actually having it may piss off exchanges who are trying to comply with kyc/aml, and this may lead to them deciding that monero is no longer compliance-friendly. which is incorrect, because the new view keys are less broken than the current view keys lol 17:38:02 Understandable, and clearly the "marketing" around Carrot would need to change to match what it actually does. But does this imply that making Monero compliance-friendly (or at least perceived to be) is part of the objective here? I don't really agree with that, if it's the case 17:38:15 To be clear, I am not against Carrot in any way 17:38:32 I did a CARROT audit in the past, but explicitly searching for vulnerabilities wasn't in-scope, so I don't feel too bad 17:38:55 Better late than never, amirite.....? 😅 17:38:56 I'm still unclear on this scenario which causes the auditor to perceive a negative balance 17:39:27 @kayabanerve:matrix.org: same thing happens. the interesting thing here is that with the fcmp view keys (as-is), auditors actually have a chance to collect evidence of wrongdoing (if your apparent balance goes negative, for example) so in a way, the detectability in the case that a malicious user is not being very carefu [... too long, see https://mrelay.p2pool.observer/e/3MnDwIkLX215UC1Q ] 17:39:40 @kayabanerve:matrix.org: you have 100 xmr 17:39:42 you send 100 xmr less fees to yourself 17:39:45 The objective of the key isn't compliance friendliness. It's primarily to improve UX for cold/hot wallets, hw wallets, and multisig. So this wouldn't deviate from the primary goal imo 17:39:56 you randomly sample your own key data so that the transaction can't be scanned by someone with the view key 17:40:01 auditor sees you lose 100 xmr but not gain it again 17:40:06 jpk68: view-all keys do not only "please auditors". It has other solid uses. E.g. checking your paper wallet balance is still there without any danger 17:40:09 but you sent it to the same wallet it came from 17:40:35 Sure. That isn't a bug in CARROT. 17:40:56 But I wonder if exactly this could be abused. I show an auditor "look, I have a negative balance, so I'm deserving of golden parachute funds!!" when actually I'm just hiding them (or something like this) 17:41:39 @jberman: okay, if that's the case, then it's a matter of being careful to clarify this. this is not how monero view access has been advertised, for the most part, going back to the cryptonote whitepaper 17:41:47 I don't understand. Won't even the dumbest auditors see that there is no such thing like a negative balance with a cryptocurrency wallet? 17:42:00 If everything works correctly, that is 17:42:09 The ability for senders to not send you an output via CARROT, but the ability for you to manually import non-CARROT outputs and spend them in ways which interact with CARROT, is bs understandably outside the scope of CARROT. 17:42:09 If you have to manually import an opening, so does the auditor, is straightforward enough. 17:42:38 manually importing an opening is effectively operating a distinct wallet though 17:42:58 if the view keys are just for convenience for wallets and UX, then the problem is auditors using the view keys for auditing instead of wallets using them for backend convenience (or whatever) 17:43:15 There is no solution to prove your view key is for all of your wallets without linking to an identity 17:43:57 Except the view keys do identify all coins that wallet received. Your proposal requires a wallet with distinct rules to receive the coins with. 17:44:22 @kayabanerve:matrix.org: absolutely correct 17:44:32 the severity of this problem is ... debatable. there's nuance. 17:44:33 You're then noting manual importing can fuck with CARROT accounting, sure, but the bug isn't with the view key itself. 17:44:46 @kayabanerve:matrix.org: uhm no 17:44:56 rbrunner: Of course, and that's part of my argument. In my opinion, a huge part of the tangible benefit provided by Carrot is the ability to have so-called "view-all" keys, allowing for safer balance-checking without the need for the spend keys. I am sure this possibility for hiding transactions will not be part of core wallet [... too long, see https://mrelay.p2pool.observer/e/xsrXwIkLR2tBT2ky ] 17:45:04 i can opt out of the vie accesss, and it's advertised as view all 17:45:07 not true with a VRF deciding random transaction data 17:45:21 You can create a different wallet 17:45:25 A concern of mine, though, is transparency of General Fund wallets with this, along with similar things 17:45:41 @kayabanerve:matrix.org: no one ever claimed that creating a new wallet wouldn't evade auditors 17:45:45 view-all for a wallet does not mean view all for every wallet under this entity 17:45:47 Though it wouldn't be any worse than how it is currently 17:45:49 carrot claims that view-all is view-all, and it isn't 17:45:54 where this may come in handy is to keep in mind downstream for applications like swaps etc that are built on shared wallets using view keys as one method of accounting 17:46:02 @kayabanerve:matrix.org: view all also does not mean "optional" 17:46:22 @jpk68:matrix.org: yeah, i don't think it is worse than the current state of things 17:46:25 @jbabb:cypherstack.com: just to be more aware of the ways malicious counterparties can fudge the books for shared wallets 17:46:27 but that's my knee jerk 17:46:32 It is because you're proposing a non-carrot wallet and therefore a distinct wallet 17:46:59 @kayabanerve:matrix.org: no i'm proposing an actor who is semi-honest can fail to satisfy the claimed properties 17:47:10 How much would the fix impact scaling and transaction sizes? 17:47:11