17:03:17 Meeting in a bit less than 1 hour. People in the US beware, you enjoyed the end of DST, and the meeting is 1 hour "earlier" 17:26:02 hurrah 17:47:00 My clocks are in UTC. Idk what dst is 18:00:02 Meeting time. Hello! https://github.com/monero-project/meta/issues/1290 18:00:31 hey 18:00:38 *waves* 18:01:16 Howdy 18:01:52 Alright, on to the reports from last week. FCMP++ I suppose, right? :) 18:02:28 still working on TODOs and bug fixes 18:03:54 I'm working on a large refactor to the Carrot integration that should get us closer to wallet2 supporting Carrot-derived account secrets and addresses, as well as hybrid hierarchies 18:04:26 It also gets us closer to HW device integration, including live scanning 18:04:34 Prepared PR's for v1.4 of the stressnet fixing some solid issues affecting monerod, investigated OOM's by using valgrind to sync and found that FCMP++ verification was taking more memory than expected, moving forward with the latter for now, then aiming to get back to tx relay v2 and runaway spans during IBD that @boog900 idenitifed 18:04:51 "Carrot intergration" as quite in general, into the Monero codebase? 18:06:21 And what is a "hybrid hierarchy"? If both old-style and new-style secret keys are present in a single wallet? 18:08:17 If yes, can't that get quite confusing? 18:08:27 From a UI/UX point of view I mean 18:09:24 Yeah I mean mainly where the wallet2 / old cryptonote code touch with the Carrot code 18:09:29 Yes, hybrid means both 18:10:39 I guess you see some good reasons to do it, if only for symmetry if it's really needed, but well, my gut feeling is not exactly well with that ... 18:10:41 It might get confusing? Depends on the design 18:11:39 Do you get then two different sets of sub-addresses with that? With the double the chance to mix up compared with today? :) 18:12:23 I would imagine that there's no reason to show the old receive addresses anymore after a wallet migration 18:12:58 Ah, maybe I see, you want to support something like an "in-place wallet migration"? 18:13:20 Without forcing people to create new wallets if they don't like that 18:13:50 Main advantage is not having to generate a new seed? 18:14:27 Yeah, that, and all the history that is still at hand, in the same wallet as it always was 18:15:17 If the UI of the wallet app can just mostly forget the old keys, and they are only used strictly internally if needed, the problem probably isn't one 18:15:24 Yes, exactly. Nobody will ever be forced to upgrade their wallet, but the option should be there for people who don't want to update their seed phrases, assuming it's of an amenable seed type 18:16:13 Ok, I already feel a little better :) 18:16:14 I'd imagine it would be the most helpful to hardware wallet users 18:17:06 I guess in the grand scheme of FCMP++ things that addition of hybrid wallets is no big sweat, in comparison to all the other stuff that gets built 18:18:39 There was an interesting, and to me somewhat surprising CCS PR, from "perfect-daemon" / "anon": https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/621 18:18:54 It has quite a number of upvotes already, and right now no downvote 18:19:00 Any comment? 18:21:46 It needs details fleshed. There has already been confusion b/t this individual and CCS maintainers in the past, not expanding on what is actually going to be completed will inevitably lead to disagreements on whether to pay out. 18:22:45 For example, "contribute to FCMP++ migration" is mentioned in the proposal. What does this mean practically? At the moment, I have no idea 18:23:05 Hmm, what they will actually be working on might be a question that is not easy to answer right away? 18:23:44 And "fulltime" could also be a bit difficult, depending on how the project develops and moves 18:23:50 Then they shouldn't have a CCS open IMO. 18:24:06 They probably have some things in mind that they want to work on, I'd just like for them to actually list it 18:24:34 Sounds reasonable. 18:28:12 This isnt true afaik 18:28:44 They werent paid out because they never requested the payout. They were paid once they requested 18:29:28 I think we'll likely see some good code contributed as a result of the proposal, and I'm fine reviewing it. I'm hoping he'll be open to collaborate the same as he was with 7760 at least with me back in the day. Personally I think it's fine if he wants to take time to investigate what he thinks are the issues most worthy of working on, with what he listed in the CCS as his aim. I d on't think the CCS absolutely **needs** to be expanded on considering he's proven capable of finding significant issues after spending a while investigating in his own time / with his own focus. 18:29:32 Also I feel compelled to say.. I don't think that comment by hunting longs is a completely accurate portrayal of the state of the integration but I don't feel particularly compelled to argue / get into more drama on that front. I think it's likely a good bet that perfect daemon will contribute code that will improve the daemon in a meaningful way, and the daemon could use more hands on deck 18:29:35 A payment they were werent awared, was one that was privately negotiated for the multisig fix 18:31:08 You suggest someone helps you out once and suddenly you're majorly struggling ig 18:32:07 I don't understand. 18:32:19 i think it should go w/o saying that were lighthanded on all fronts 18:32:29 Shorthanded* 18:32:58 This is the issue that I was referencing. I don't want to minimize the opportunity for confusion by all parties involved 18:33:05 I *do* want to 18:33:23 I can agree in principle, but the short-handed-ness is maybe distributed quite unevenly in time and space 18:33:31 no address was provided for the final CCS payout until recently, yep. has anon apologised for making vtnerd read haskell while they kept their implementation closed source yet :P 18:33:38 (to ofrnxmr ) 18:34:17 Then this is a different issue. Multisig went through h1, was communicated thoroughly with many different parties, but the _payment_ was lost in the mix 18:34:18 Oh, let's hope we don't descend into drama here :) 18:34:29 citation https://github.com/monero-project/research-lab/issues/101#issue-1228028838 18:35:12 I have to say that I agree with jeffro256 mostly, clarity can't do harm if you ask me, but can help tremendously in many cases 18:35:22 we where shorthanded then and people had to work on reimplementing his closed source work 18:35:58 Asking them for a candidate list what they intend, or at least could imagine, to work on is reasonable 18:36:54 Are those ++ bulletproofs the ones that did not go into production after all? 18:37:20 true, this was pre audits 18:37:24 Which makes the whole story even worse I guess 18:38:33 I really think what we don't want, not for them, and not for us, is again disagreement and confusion at the end. Avoiding that should be possible, I suppose. 18:39:51 Ok, let's see how that develops further. 18:40:03 Anything else left to discuss today? 18:40:28 I would prefer as discussion of CCS proposal 621 to happen in dev channels instead of MRL meetings. If necessary, it can be discussed in MRL, but it's a dev issue. 18:41:46 Just to be sure: Are we here in a place that you would count as a "dev channel"? 18:41:59 This isn't a MRL meeting though? 18:42:08 I hope so :) 18:42:47 I brought it up mostly with a feeling that yes, it's mostly a dev thing, not a research thing, so ok to discuss here today. 18:43:25 I am saying try to get as much discussion in this channel instead of bringing it to MRL Wednesday. 18:43:45 Or start having meetings in #monero-dev:monero.social :) 18:43:46 I think we can agree on that :) 18:44:49 Ok, looks to me we are through for today. Thanks everybody for attending, read you again next week! 18:45:46 thanks 18:46:44 Ah makes sense, ;) 18:46:48 thanks everyone 18:46:49 Thanks everyone