16:57:13 Meeting in a bit more than 1 hour 18:00:01 Meeting time. Hello! https://github.com/monero-project/meta/issues/1369 18:00:11 Heyx 18:00:17 Hi 18:00:25 hello 18:01:53 Howdy 18:01:54 *waves* 18:02:39 Ok, let's start with the reports from last week. Me: Started to work on implementing Polyseed in the core software in earnest. 18:03:02 squashed, rebased and pushed the wallet-rpc ([src](https://github.com/monero-project/monero/compare/master...SNeedlewoods:seraphis_wallet:x_remove_wallet2_from_rpc), commit 1-3 are old PRs, [4th](https://github.com/monero-project/monero/commit/193d6d4cae5563643073203644991adab42d72b8) commit are new changes for the Wallet API and [5th](https://github.com/monero-project/monero/comm it/c2d32d974c682f8da74d4cccea9f396917d8562b) commit are the wallet-rpc changes) 18:03:06 but didn't make a PR yet, because I'm still having issues with some functional tests (`k_anonymity` works most of the time if I put a `sleep(10)` in front of `refresh()`) 18:03:06 Other tests that still fail: `multisig`, `transfer` 18:03:21 👋 18:04:28 me: finished carrot_core review, research/discussion on Jamtis-PQ, started looking at multisig for the hf 18:04:38 me: FCMP++ integration audit talks with candidates, working on benchmarking the latest FCMP++ lib with changes to GBP's applied 18:04:57 ME: H1 reports, worked on carrot_core review with ukoe, reviewing some PRs, talking with audit candidates, taxes 18:05:50 Hello 18:07:35 Quite a lot of discussions going on regarding Carrot, implementing the Carrot key hierarchy or not, and Jamtis-PQ. Not sure it makes sense to discuss something here today, but anyway, a question to the room: Is my impression correct that "sentiment" is shifting away from implementing the Carrot key hierarchy? 18:09:36 I plan on implementing it, just not necessarily before the first FCMP++ release binary 18:10:01 It is not a blocker, but I still plan on at least having the option for release available 18:10:38 I don't have too much of an opinion on it at this time except that I would strongly prefer that the Carrot key hierarchy does not take up time that could be spent on tasks for the fork 18:12:49 Alright. Maybe you saw it already, Tevador made an update of their Jamtis gist. I marvelled at the proposed key hierarchy here: https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832#44-key-hierarchy 18:13:08 Have to admit that looking at this makes me a bit uneasy ... 18:13:09 I don't plan to work on it, would prefer to focus on other things down the line (Jamtis-PQ, fee discretization, scanning optimizations, etc.). Related, I'd rather not do multisig for any new protocols and instead just continue with bare minimum support for existing/new legacy multisig wallets. 18:14:25 koe000: Would that mean no multisig for Carrot from you for the time being? 18:14:51 It means only multisig for Legacy-Carrot. 18:15:22 Ah, yes, that. 18:16:19 Multisig is frankly too difficult and too unused to justify full support and improvements with current talent availability. 18:17:13 Multisig for Legacy-Carrot will have a better UX than today because no more need for key data exchange after each transfer, right? 18:17:47 Should be the same UX, legacy-carrot doesn't have view-received. 18:17:54 ^^^ 18:18:12 Will it does have view-received, but it doesn't have view-balance 18:18:14 *well 18:18:25 We're close to the finish line here on FCMP++/Carrot fork, I think focusing our immediate effort on fork blockers will significantly help get this across the line and complete Monero's most significant upgrade by sheer work alone 18:18:32 Right sorry 18:19:06 Legacy wallets cannot calculate key images without interaction, regardless of CARROT 18:19:40 CARROT by itself only allows *new* key hierarchies which have those better UX properties 18:19:44 Maybe this will develop into a good dynamic as soon as the first testnet with the candidate FCMP++ / Carrot code is running. 18:20:54 I understand the argument about multisig: Somebody built a really nice GUI tool for doing Monero multisig, *finally* you could say, and it got almost zero attention 18:22:13 But anyway, I think we have a certain responsibility to at least keep multisig working after the FCMP++ hardfork 18:22:25 Yes the goal is to keep it working. 18:22:29 Haveno uses it, for one 18:22:30 What is meant by "full support" for multisig? Support in the core implementation? 18:23:28 Doesn't monero-oxide maintain one for Serai 18:23:28 *an implementation of multisig 18:24:20 (for the record, I assume you're talking about [this](https://github.com/freigeist-m/monero-multisig-gui/tree/master/)) 18:24:45 Full support as in: good docs with security attributes described, all addressing protocols supported, best-in-class multisig protocols implemented for best UX, upgrading from 'experimental' status to 'official' status, availability of talent for ongoing support and development. 18:25:14 SNeedlewoods: Exactly that one, thanks for the link 18:27:32 The latest Jamtis has such an inflation of secrets and keys that it will take quite some effort to just memorize them all to be able to follow discussions :) 18:28:01 I really wonder whether some day somebody will come along and present a system with similar properties that is 10 times less complex ... 18:28:29 Probably not, but one can dream :) 18:29:55 Alright, after these reports, and confirming that we are shooting for keeping multisig working more or less within the current capabilities - do we have to discuss something else today? 18:30:54 Doesn't look like it. So thanks everybody for attending, read you again in 1 week! 18:31:27 Thanks 18:31:31 thanks everyone, see you 18:31:32 Thanks 18:31:34 Thanks 18:32:31 Thanks everyone 18:33:08 Great 18:33:54 Really looking forward to have *z_ur (unlock-received post-quantum key)* in my Monero wallets, chuckle 18:34:57 rbrunner7: Each of the keys has a purpose. AFAICS you cannot remove any of the keys without losing features. 18:37:15 I don't doubt, and don't get me wrong, I don't want to ridicule anything. I am in awe about the construct, just uneasy about the complexity. I think to achieve any meaningful simplification one would have to find a radically different approach. 21:28:29 The complexity of Jamtis-PQ is more reason to add the carrot key hierachy as temporary solution to provide more quantum secrecy. Since churning with legacy-carrot is not safe against QAs and there is no confirmation that churning to an intermediate wallet is a suitable QA defense according to Jeffro. 21:28:30 Appreciate the research Tevador. Can’t wait for Jamtis‑PQ!