05:29:18 <m-relay> <r​brunner7:monero.social> Well, that's the crux: You will find sane and maybe also convincing arguments for this "saving is unrestricted" exception, and a handful of others. I call this "micro-optimization": You look at each case only on its own, and try to come up with the best possible implementation for each of them independently. But perfection in detail very often leads to an overall mess because ther<clipped mess
05:29:18 <m-relay> <r​brunner7:monero.social> e won't be simple rules anymore that you can apply universally, but lots and and lots of exceptions.
05:30:31 <m-relay> <r​brunner7:monero.social> Without deep technical and background knowledge you as a dev using such an API you won't be able to deduce yourself how each case must work, and you either have to memorize, or contantly look up things.
05:31:56 <m-relay> <r​brunner7:monero.social> That's why I am clearly on the side of "saving is restricted" here.
16:58:49 <m-relay> <r​brunner7:monero.social> Meeting in about 1 hour
17:08:53 <m-relay> <j​berman:monero.social> I caught a pretty bad illness and am recovering (on the mend), won't able to make today's meeting unfortunately. I rebased this PR last week ( https://github.com/seraphis-migration/monero/pull/89 ) and mostly did PR reviews
17:10:45 <m-relay> <j​pk68:matrix.org> https://www.youtube.com/watch?v=srvhyKi1qs8
17:10:57 <m-relay> <j​pk68:matrix.org> Sorry, didn't mean to send that
17:11:09 <m-relay> <r​brunner7:monero.social> Thanks for the report, jberman . Wish you well.
18:00:14 <m-relay> <r​brunner7:monero.social> Meeting time. Hello! https://github.com/monero-project/meta/issues/1366
18:00:22 <m-relay> <s​needlewoods_xmr:matrix.org> Hi
18:00:50 <m-relay> <j​effro256:monero.social> Howdy
18:01:02 <UkoeHB> hi
18:01:11 <m-relay> <v​tnerd:monero.social> Hi
18:02:06 <m-relay> <r​brunner7:monero.social> Alright, on to the reports. jberman cannot attend, reported before the meeting that last week was mostly reviews for him.
18:03:09 <m-relay> <v​tnerd:monero.social> Updated lws+lwsf to match the changes to carrot. Also updated the pr for zmq to fcmp++-stage
18:03:10 <m-relay> <s​needlewoods_xmr:matrix.org> apart from review comments in regards to [#10378](https://github.com/monero-project/monero/pull/10378) I mainly worked on fixing functional tests with the new wallet-rpc
18:03:56 <UkoeHB> Me: distracted by personal matters last week. This week looking at a hackerone report and will actually finish carrot_core review.
18:04:40 <m-relay> <j​effro256:monero.social> Me: wrote Keccak256 and Ed25519 field operations in Slang, a shader language , and pushed operations to a GPU using Vulkan. Just doing unit testing right now, not performance testing . At some point I wanna test the performance of the ECDH using precomputed points, the view tag check, and the amount commitment recomputation
18:05:14 <m-relay> <r​brunner7:monero.social> Just to relax a bit from all that hard C++ and Rust coding I guess :)
18:05:55 <m-relay> <r​brunner7:monero.social> So that's in a "proof of concept" phase right now
18:06:10 <m-relay> <r​brunner7:monero.social> and I guess may still fail
18:07:32 <m-relay> <j​effro256:monero.social> Yeah absolutely , there's been a lot of talk over the years about scaling Monero validation by using the GPU . Will be interesting to see if its feasible in real life
18:07:41 <m-relay> <j​effro256:monero.social> But could definitely flop too
18:08:42 <m-relay> <r​brunner7:monero.social> I think this will be closely watched in some circles!
18:09:29 <selsta> not sure if this meeting is also for new releases but we are making good progress on v0.18.5.0
18:10:07 <selsta> it will only contain bug fixes but a lot of them so I deemed it worthy of a larger release
18:10:10 <m-relay> <r​brunner7:monero.social> Thanks for the news, selsta, good to hear. What's the main attraction of that release?
18:10:11 <m-relay> <s​needlewoods_xmr:matrix.org> 👍️
18:10:30 <m-relay> <r​brunner7:monero.social> Absolutely.
18:12:31 <m-relay> <r​brunner7:monero.social> Ok, if we are already through with the reports, I have a question, that I think jeffro256 will be able to answer easily: Is there already an implementation / PR of the 'wallet2' and maybe also 'account' classes that support and handle the new Carrot key hierarchy? I was suspecting this first, but could not find a smoking gun inside yet: https://github.com/seraphis-migration/monero/pull/52
18:15:28 <m-relay> <r​brunner7:monero.social> And I was wondering how it will turn out if 3 parties or even more will make changes at the same time in the wallet classes, SNeedlewoods for their rewrites, jeffro256 and jberman for Carrot and FCMP++, and I myself for Polyseed support.
18:15:49 <m-relay> <r​brunner7:monero.social> Wondering whether we can do something in the direction of project management to minize conflicts.
18:15:56 <m-relay> <r​brunner7:monero.social> *minimize
18:16:35 <m-relay> <j​effro256:monero.social> The crypto is implemented , and most of the supporting code in carrot_core and carrot_impl , respectively . But it is not integrated into wallet2
18:17:02 <m-relay> <j​effro256:monero.social> That hot / cold PR supports the old key hierarchy in CARROT/FCMP++
18:17:17 <m-relay> <r​brunner7:monero.social> I see
18:17:31 <m-relay> <j​effro256:monero.social> What kind of conflicts do you for see?
18:17:41 <m-relay> <r​brunner7:monero.social> Do you see yourself going on and putting Carrot support into `wallet2`?
18:17:47 <m-relay> <s​needlewoods_xmr:matrix.org> I rarely touch wallet2 and a while ago I based my Wallet API work on some fcmppp branch and there wasn't too many conflicts
18:17:55 <m-relay> <s​needlewoods_xmr:matrix.org> for testing*
18:18:34 <m-relay> <r​brunner7:monero.social> Mostly repeated rebases and merge conflicts. But anyway, I guess the answer is that not much can be done except just "letting it run". For example, we can't predict the order things will get merged.
18:18:47 <m-relay> <j​effro256:monero.social> At some point if it is popular
18:19:17 <m-relay> <r​brunner7:monero.social> What do you mean with "popular"?
18:19:31 <m-relay> <j​effro256:monero.social> Well, technically , CARROT support is already fully in there
18:20:02 <m-relay> <j​effro256:monero.social> But I haven't integrated support for the new *key hierarchy*
18:20:23 <m-relay> <r​brunner7:monero.social> Isn't that a pretty fundamental piece of support?
18:20:50 <m-relay> <j​effro256:monero.social> Depends on if you want to use the new key hierarchy or not
18:20:55 <m-relay> <j​effro256:monero.social> You don't need to
18:21:01 <m-relay> <j​babb:cypherstack.com> I do :)
18:21:19 <m-relay> <r​brunner7:monero.social> Now I am confused. We all want to have the option for sure, no?
18:21:35 <m-relay> <j​effro256:monero.social> We can ship CARROT/FCMP++ without the new key hierarchy
18:21:57 <m-relay> <j​effro256:monero.social> That's what the stressnet is doing rn
18:22:04 <m-relay> <r​brunner7:monero.social> Yeah, I know that technically we can, but the thought to actually *do so* really never crossed my mind ...
18:22:18 <m-relay> <j​effro256:monero.social> I mean yes, I want people to have the option
18:22:40 <m-relay> <j​effro256:monero.social> But there's the UX issue of how to introduce that option to users
18:22:54 <m-relay> <j​babb:cypherstack.com> With recent discussions re: adding some Jamtis features to CARROT, the propspect of delaying the new key hierarchy makes more sense to me
18:23:18 <m-relay> <r​brunner7:monero.social> I think jberman made a list somewhere what everything is still on the way to the Carrot and FCMP++ hardfork. IMHO "support for new Carrot key hierarchy" absolutely belongs there.
18:24:05 <m-relay> <r​brunner7:monero.social> Josh Babb: Good point. Hopefully those discussions can start soon.
18:24:43 <m-relay> <j​babb:cypherstack.com> I previously would've wholeheartedly agreed on that, rb, but it seems if we take that path that we may end up with 3 key hierarchies unless I misunderstand
18:25:15 <m-relay> <j​babb:cypherstack.com> I mean: if we rush to make CARROT available now, it seems we'll end up with users on the legacy path, CARROT, and then eventually Jamtis or similar
18:25:25 <m-relay> <j​babb:cypherstack.com> am I misunderstanding that?
18:26:47 <m-relay> <r​brunner7:monero.social> I think this possibility is on the table. But anyway, I wouldn't call the introduction of the new Carrot key hierarchy "rushed". The Carrot "paper" is out for many months, and I think also reviewed.
18:27:15 <m-relay> <j​babb:cypherstack.com> of course, poor wording.
18:27:27 <UkoeHB> I will do my best to finish up carrot_core today or tomorrow and get jamtis feature discussion going asap.
18:28:08 <m-relay> <j​babb:cypherstack.com> a spoonful of Jamtis makes the CARROT go down...
18:28:33 <m-relay> <r​brunner7:monero.social> People might vote for dropping all non-PQ related research and dev work after the FCMP++ hardfork, so next thing might be a PQ Jamtis that is not yet fully worked out ...
18:28:54 <m-relay> <j​pk68:matrix.org> Just my two cents: I think the need for quantum-resistance is a good argument for releasing Carrot as it is, because it can happen sooner. It does provide something in terms of forward-secrecy
18:29:07 <m-relay> <j​effro256:monero.social> Maybe , but I kind of always thought that that may be the best path: have an option for "blending in" with old users with tons of functionality (new hierarchy in CARROT spec), only missing a couple points. Then a full address scheme which doesn't try to be backwards compatible and really packs all the features and gives users a hard break (JAMTIS, maybe with PQ encryption)
18:29:09 <m-relay> <j​pk68:matrix.org> Forgive me if I got a few details wrong ;)
18:30:29 <m-relay> <r​brunner7:monero.social> Yes, we don't have a lack of possible future paths, we have a bit too many :)
18:30:46 <UkoeHB> Ok instead I will start prepping the discussion now and finish carrot_core review after :)
18:31:08 <m-relay> <r​brunner7:monero.social> That sounds like a good idea to me
18:33:21 <m-relay> <r​brunner7:monero.social> I think that experience shows it anyway takes quite some time until the "wallet app ecosystem" catches up with new capabilities in the Monero core software. Right now I think we should make the new Carrot key hierachie in some form available already together with the FCMP++ hardfork. But that's to discuss of course, with more info on the table.
18:34:57 <m-relay> <s​needlewoods_xmr:matrix.org> as a user I'd also like to see the new Carrot key hierarchy together with FCMP++
18:36:06 <m-relay> <j​babb:cypherstack.com> agreed, and I should be clear that I just prefer that we see if CARROT can get some more Jamtis features in it before the HF.  I wouldn't want to delay it if that can't happen in a timely fashion
18:37:11 <UkoeHB> Imo if more features are added, they don’t need to be fully supported immediately. Including the key hierarchy. Just need enough to match the the existing wallet api.
18:37:28 <m-relay> <r​brunner7:monero.social> Agreed. If we can get in more before the hardfork, that would be terrific, and we should take the chance. Depends on the trade-offs, however.
18:38:34 <m-relay> <j​effro256:monero.social> Okay I'll consider moving the timeline up for the new hierarchy integration
18:39:00 <m-relay> <r​brunner7:monero.social> Would be good to know details about what that would take, certainly.
18:40:39 <m-relay> <r​brunner7:monero.social> Another subject: Where do we stand regarding supporting hybrid wallets or not? I guess we won't easily get any more comments on the corresponding issue ...
18:41:16 <m-relay> <r​brunner7:monero.social> And what is there looks like a "loose consensus" to not support to me. Not sure how other people look at this.
18:42:45 <m-relay> <j​pk68:matrix.org> I am clearly far from the most qualified to talk about this, but I really don't think we should keep delaying the hardfork. People are getting pretty impatient and the fact that it could be Q3/Q4 is already kind of alarming
18:42:49 <m-relay> <r​brunner7:monero.social> Of course that's connected with new hiearchy integration
18:42:55 <m-relay> <j​pk68:matrix.org> This was discussed on the last episode or two of MoneroTalk
18:43:14 <m-relay> <r​brunner7:monero.social> You mean hardfork timing?
18:43:15 <m-relay> <j​pk68:matrix.org> I am clearly far from the most qualified to talk about this, but I really don't think we should keep delaying the hardfork. People are getting pretty impatient and the fact that it could be Q3/Q4 is already kind of alarming to them
18:43:53 <m-relay> <r​brunner7:monero.social> That would be pretty "outside" view ...
18:43:55 <m-relay> <j​pk68:matrix.org> I was adding onto my previous comment, apologies
18:44:38 <m-relay> <r​brunner7:monero.social> Say again, *what* was discussed there?
18:44:44 <UkoeHB> Delays seem more to do with mispredicted timelines than things being pushed back. I predicted it would take this long back when the first CCS showed up.
18:46:28 <m-relay> <r​brunner7:monero.social> UkoeHB: I agree. We are on our way, not really wasting time or doing unnecessary things. A little bit of progress every week.
18:46:35 <m-relay> <j​pk68:matrix.org> General dev/research news (as seen from whatever's posted on Twitter) is/was discussed; the fact that the hardfork could be delayed again is evidently a cause of frustration for a number of people
18:47:03 <UkoeHB> @jeffro256: most important is that wallets can construct txs properly for all supported address formats. Generating new wallets and providing APIs for new features can safely wait for future updates if needed.
18:47:32 <m-relay> <j​pk68:matrix.org> I am aware that hard timelines were never really given, but it seemed that the hardfork date would most likely be announced around the time of MoneroTalk
18:47:56 <m-relay> <r​brunner7:monero.social> *MoneroTopia?
18:48:05 <m-relay> <j​pk68:matrix.org> Yes, sorry :)
18:48:10 <m-relay> <j​pk68:matrix.org> I am aware that hard timelines were never really given, but it seemed that the hardfork date would most likely be announced around the time of MoneroTopia
18:48:29 <UkoeHB> "the fact that the hardfork could be delayed again" No one has proposed delaying for carrot changes, although you are right it is theoretically possible.
18:49:25 <m-relay> <j​pk68:matrix.org> My point is, it has already taken quite a long time (not that there's anything wrong with that), and I just feel like delaying it yet again would be a bad idea
18:50:39 <m-relay> <r​brunner7:monero.social> If/when we discuss inlcuding some additional Jamtis or Jamtis likecfeatures into Carrot, time to implement and deploy will certainly play a role in discussions - among other things.
18:51:19 <m-relay> <r​brunner7:monero.social> Let's see how things look at next week's meeting then.
18:51:55 <m-relay> <r​brunner7:monero.social> Alright, do we have to discuss something else today?
18:52:08 <m-relay> <v​tnerd:monero.social> Yeah adding features this late ... Yikes
18:52:45 <m-relay> <j​pk68:matrix.org> As rbrunner said last week... a bird in the hand is worth two in the bush ;)
18:52:53 <m-relay> <r​brunner7:monero.social> Isn't that a true and tested strategy in IT? :)
18:53:57 <m-relay> <r​brunner7:monero.social> Ok, we are nearing the hour, and it seems we are through for today. Thanks everybody for attending, read you again next week!
18:54:30 <m-relay> <s​needlewoods_xmr:matrix.org> thanks everybody
18:54:40 <UkoeHB> thanks