16:59:12 Meeting in 1 hour. Now also Europeans can enjoy the great civilizational achievement of daylight saving time. 17:01:07 truly one of the great pillars 17:14:55 f*ck daylight saving. everything should be UTC and people should get used to have morning a 10pm 17:15:19 Imajing still having DST, in 2026!!! 17:19:29 SyntheticBird: That's the spirit. I am jet-lagged a bit from getting up 1 hour too early in regard to my inner clock 18:00:05 Meeting time. Hello! https://github.com/monero-project/meta/issues/1360 18:00:14 Hi 18:00:45 Hello 18:01:04 Hi 18:01:09 Hi 18:01:34 Hi 18:03:07 Howdy 18:03:24 *waves* 18:03:27 doing well thanks, howdydo? 18:03:48 Alrigh, plenty of people today, nice. What are your reports from last week? 18:04:04 `grep "\" src/wallet/wallet_rpc_server.cpp -c` returns 0 18:04:08 Now focus is on functional_tests, find and fix bugs not covered by tests, clean up code and notes 18:04:14 Also just posted a final report on my [current CCS proposal](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/634#note_35515) and began to write a [new CCS proposal](https://paste.debian.net/hidden/561205b1) 18:05:11 I myself wanted to continue to work on Polyseed, but did not find the necessary free time ... 18:05:28 Reviewing carrot_core. Pointed out some limitations of the PQ turnstile design to jeffro256. 18:06:14 me: completed the monerod hang-on-exit PR and submitted it ( https://github.com/monero-project/monero/pull/10382 ), various FCMP++ integration cleanup / upstream monerod cleanup tasks 18:08:01 Next, will write an issue advocating for more jamtis features now instead of later. Won’t do any other work on it without strong buyin. 18:09:12 Not sure I understand. You mean if your proposals don't find strong support you are ready to move on from Carrot into other topics? 18:10:05 Yes, either review carrot_impl or start on multisig. 18:10:28 Me: talking to Koe about CARROT/Jamtis, talking to vtnerd about LWS, reviewing H1 issues, talking to auditors about the FCMP++ integration, talking to Ledger about HW development, rebased the knowledge proofs PR and working on completing the remaining tasks 18:11:05 do you happen to take your breath in between ? 18:11:13 Just curious anyway, what is an example for one of the Jamtis features that you would want Carrot to learn, UkoeHB? 18:11:44 rbrunner7: encoded address index + filter-assist key 18:12:37 Any success with contacting Trezor? 18:12:41 Ah, ok. I remember quite vidid discussions about Seraphis indexes, probably without ever reaching a clear consensus :) 18:13:15 I can't remember if you said you emailed the dev or the company :) 18:13:31 btw sgp_ is about to do an audit blitz reaching out to some more candidates soon, would be good to coordinate comms 18:13:32 Mostly complaints about adding bytes. 18:14:45 I emailed the company a few months ago, but they never really followed up until someone else who had personal connections poked them about it recently, very grateful 18:14:46 It sounds like mx25519 has not been touched by any audit. jberman/jeffro256 can you work it into the audit cycle? 18:15:41 ^ My previous comment is about Ledger. Trezor said that they would forward it to a product manager and never got back 18:16:30 I liked the address indexes and filter-assist key. I'm open to re-opening a discussion on them, with strong emphasis on still ensuring FCMP++ launches within a timely manner 18:16:39 I wonder what their lead development times would be to be fully ready with a new FCMP++ capable firmware when we hardfork. 18:16:42 I think mx25519 would be a good candidate for the optional follow-up PR which covers the more complex wallet-specific crypto like the point checking by fast halving 18:17:54 mx25519 seems like a good candidate to be reviewed in an isolated audit by auditors proficient in C & crypto 18:18:03 At the least, basically anyone can verify that `mx25519` hits the standard test vectors for X25519 and doesn't use branching in the assembly 18:18:11 Fair 18:18:26 They need to be proficient in assembly though mainly 18:18:35 true, yes 18:18:44 Are the text vectors considered adequate for validity? 18:18:53 seems a marginally distinct skillset enough to warrant a distinct audit 18:19:12 edit out the marginally* 18:19:38 Could that mean another Carrot "crypto" review if we change anything non-trivial like indexes and/or another key like that? 18:19:48 There's an x64 impl, an x64 with mulc/adc extensions impl, an ARM64 impl, and a portable C impl. 18:20:28 UkoeHB: IDK, so I would leans towards "no" 18:20:33 rbrunner7: likely yes 18:20:39 But it's a baseline test for completeness 18:21:31 I see. But could heavily build on what already happened there review-wise, I guess 18:21:47 Yes 18:22:33 If there’s buy-in, I will write a PR on carrot_core with the changes so the full scale can be more accurately seen. But let’s wait until the points in favor are laid out. 18:23:35 Ukoe makes really good arguments for basically shifting the new key hierarchy into Jamtis, but I am personally against it for the moment, especially if we go for hard separation in issue https://github.com/seraphis-migration/monero/issues/306. Perhaps I could write up an issue showing pros and cons of both 18:24:31 Just wanted to ask whether anybody see a benefit if we discuss h306 here today, or do we just let that collect comments and votes for some time more :) 18:24:59 Not sure how many other contributors have not commented 18:25:21 I think jberman is the most prominent there 18:26:14 I meant to write up a comment, but I'm still pretty strongly in the camp of hard separation. I think tevador's arguments strenghthend the argument for separation and I was already for separating 18:26:31 (as did rbrunner's) 18:27:04 So maybe a short comment from you will already do, do make your mark clearly in a place that is visible also to people who don't follow meetings and discussions here 18:27:24 I will 18:27:59 jeffro256: I'm curious if you have some cons top-of-mind rn on bringing in the address index + filter-assist key 18:28:31 The new comments from jeffro convinced me that on the side of the the implementation on the side of core wallet code the hybrid scheme can work, and we would probably able to pull it through, but that does almost nothing to diminish my fears of potential chaos in the wallet apps 18:28:49 sneedlewoods_xmr also 18:29:26 Right, I think so far there is only a "like" from them somewhere, but no comment 18:30:51 Ok, looks like we just come back to this next week, and then we can maybe chat about how to reach something like a "loose consensus" on this 18:31:24 yes, I +1'ed rbrunner, not sure if I have anything worth to add 18:31:30 Cannot fail to remark that heavy "pro" votes are somewhat lacking ... 18:32:34 Cons against adding address index + filter assist key is mainly two things. One, the added complexity to the addressing protocol which is already complicated. And two, the privacy implications of having people be on two completely separate distinguishable address formats. Most users probably won't be using the filter-assist tier, and would get the main benefits of the new key hier archy without needing a change in address format. Also, the main benefit of address indexes I think is lost if one changes the way that they scan, in such a way that they can save all txs which may potentionally belong to them. Think of background scanning, but even more selective. 18:33:17 There would be a need of change of address format? 18:33:26 Like in "public Monero addresses" 18:33:28 ahhh right new filter-assist tier requires a new key pair ya? 18:33:35 so addresses would be longer too 18:34:07 Yes, adding address indicies + filter-assist requires a new 8 byte field and 32-byte elliptic curve point in the address, respectively 18:34:28 So there's no way of incorporating the new address index without making the new address indistinguishable from old either 18:34:41 Not that I know of 18:35:08 Hmmm ... that seems to go against one of the core achievements of Carrot, at least as I see them, that addresses magically don't have to change to still get solid benefits 18:35:30 The PQ scheme will do that anyway, it’s inevitable with current plans. Now is better than later for racing against adversaries. 18:35:53 Yes. But might be some years out, I guess? 18:36:36 Ok my argument is weak * in any case, GitHub is better for laying out the case. 18:36:37 I figured even Carrot addresses won't work in a fully PQ scheme 18:37:41 Yes, that proposal of Tevador which seems quite concrete already has longer addresses, do I remember correctly? 18:38:23 What do you mean by "fully" PQ? 18:38:35 I think there is it: https://github.com/monero-project/research-lab/issues/151 18:38:53 A scheme that includes PQ key exchange 18:39:04 (but is not limited to) 18:39:24 Yes, the change would be moving new features from PQ scheme to now, and then PQ would just add PQ. So there’d be two address changes instead of one, but the features would be now instead of later (or never). 18:40:01 Could develop into interesting trade-offs then :) 18:40:29 Let's see whether our decision processes will be able to cope with those ... 18:40:39 As for the address distinguishability problem, there is an argument is Koe's favor towards "ripping the bandaid off" now if we plan to support Jamtis later. Since if the new key hierarchy already exists and is used, then Jamtis is implemented, the only people who would really need to move to Jamtis would be the filter-assist light wallet users. Then one can categorize a Jamtis use r as *probably* a filter-assist user 18:42:30 Filter assist or using random address generation (assuming 16 byte indices). Or enterprise with advance index usage. 18:43:19 rag might be favored by the most privacy conscious. 18:43:53 Yup 18:44:13 Which really covers the two biggest camps: mobile and privacy focused 18:44:19 Personally I think the con of new distinguishable address is a legitimate con that does weigh in to my calculation here pretty solidly (especially when weighed together with keeping a sane timeline for FCMP++) 18:45:03 I do think there will be support to incorporate it once we have no choice to migrate to a new distinguishable address type 18:45:37 These features were relatively popular when it was discussed / proposed for Seraphis + Jamtis 18:45:51 I am quite unsure here. I just looked up the English translation of a famous German saying and found "a bird in the hand is worth two in the bush". That what comes to my mind right now with all those wonderful things that we could implement, but maybe should not, to protect a sane timeline 18:46:08 this 18:46:37 I just don't have technical arguments but gosh its how i felt 18:48:23 Alright, I hope people will find time soon to lay out things clearly in some GitHub issues, so people can look at that and "meditate" over it 18:48:45 I also do strongly favor advancing PQ research after FCMP++/Carrot 18:48:59 so it's not like a hand wavy thing 18:49:15 I think that's a critical direction 18:49:22 So that could maybe start earlier if we finish early with the hardfork to FCMP++ :) 18:51:06 Alright, let's see how proposals and opinions here develop further over the coming week. 18:51:08 Anything left for this very meeting? 18:51:36 not for this meeting, but would appreciate some feedback on this PR https://github.com/monero-project/monero/pull/10378 18:51:37 what are your opinions on: 18:51:38 a) Should `get_tx_proof`, `get_spend_proof` & `get_reserve_proof` get restricted? I didn't see a good reason to do so. 18:51:40 b) Should `relay_tx` get restricted? I'm leaning towards no, because even though it's a "state-changing" command, you can't really do anything with it without getting the raw tx from an unrestricted wallet-rpc (or some other unrestricted wallet) first, AFAICT. 18:51:42 c) In [10271](https://github.com/monero-project/monero/pull/10271) it was argued that there is no privacy loss in allowing `get_transfers` & `get_transfer_by_txid`, because `get_tx_key` is unrestricted anyways. I did restrict it in my PR, do you think it should stay unrestricted? 18:52:10 Alright, will try to find time to have a look 18:52:58 So it looks like we can close for today. Thanks everybody for attending, read you again next week! 18:53:11 Thanks everyone, good meeting, cu 18:54:55 Thanks 22:50:00 i would argue that get_tx_key and get_*_proof don't need to be restricted