<r​brunner7:monero.social> 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"

hurrah

<o​frnxmr:monero.social> My clocks are in UTC. Idk what dst is

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1290

<s​needlewoods_xmr:matrix.org> hey

<j​berman:monero.social> *waves*

<j​effro256:monero.social> Howdy

<r​brunner7:monero.social> Alright, on to the reports from last week. FCMP++ I suppose, right? :)

<s​needlewoods_xmr:matrix.org> still working on TODOs and bug fixes

<j​effro256:monero.social> 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

<j​effro256:monero.social> It also gets us closer to HW device integration, including live scanning

<j​berman:monero.social> 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

<r​brunner7:monero.social> "Carrot intergration" as quite in general, into the Monero codebase?

<r​brunner7:monero.social> And what is a "hybrid hierarchy"? If both old-style and new-style secret keys are present in a single wallet?

<r​brunner7:monero.social> If yes, can't that get quite confusing?

<r​brunner7:monero.social> From a UI/UX point of view I mean

<j​effro256:monero.social> Yeah I mean mainly where the wallet2 / old cryptonote code touch with the Carrot code

<j​effro256:monero.social> Yes, hybrid means both

<r​brunner7:monero.social> 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 ...

<j​effro256:monero.social> It might get confusing? Depends on the design

<r​brunner7:monero.social> Do you get then two different sets of sub-addresses with that? With the double the chance to mix up compared with today? :)

<j​effro256:monero.social> I would imagine that there's no reason to show the old receive addresses anymore after a wallet migration

<r​brunner7:monero.social> Ah, maybe I see, you want to support something like an "in-place wallet migration"?

<r​brunner7:monero.social> Without forcing people to create new wallets if they don't like that

<o​frnxmr:monero.social> Main advantage is not having to generate a new seed?

<r​brunner7:monero.social> Yeah, that, and all the history that is still at hand, in the same wallet as it always was

<r​brunner7:monero.social> 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

<j​effro256:monero.social> 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

<r​brunner7:monero.social> Ok, I already feel a little better :)

<j​effro256:monero.social> I'd imagine it would be the most helpful to hardware wallet users

<r​brunner7:monero.social> 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

<r​brunner7:monero.social> There was an interesting, and to me somewhat surprising CCS PR, from "perfect-daemon" / "anon": repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/621

<r​brunner7:monero.social> It has quite a number of upvotes already, and right now no downvote

<r​brunner7:monero.social> Any comment?

<j​effro256:monero.social> 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.

<j​effro256:monero.social> For example, "contribute to FCMP++ migration" is mentioned in the proposal. What does this mean practically? At the moment, I have no idea

<r​brunner7:monero.social> Hmm, what they will actually be working on might be a question that is not easy to answer right away?

<r​brunner7:monero.social> And "fulltime" could also be a bit difficult, depending on how the project develops and moves

<j​effro256:monero.social> Then they shouldn't have a CCS open IMO.

<j​effro256:monero.social> They probably have some things in mind that they want to work on, I'd just like for them to actually list it

<r​brunner7:monero.social> Sounds reasonable.

<o​frnxmr:monero.social> This isnt true afaik

<o​frnxmr:monero.social> They werent paid out because they never requested the payout. They were paid once they requested

<j​berman:monero.social> 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<clipped messag

<j​berman:monero.social> 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.

<j​berman:monero.social> 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

<o​frnxmr:monero.social> A payment they were werent awared, was one that was privately negotiated for the multisig fix

<j​effro256:monero.social> You suggest someone helps you out once and suddenly you're majorly struggling ig

<r​brunner7:monero.social> I don't understand.

<o​frnxmr:monero.social> i think it should go w/o saying that were lighthanded on all fronts

<o​frnxmr:monero.social> Shorthanded*

<j​effro256:monero.social> This is the issue that I was referencing. I don't want to minimize the opportunity for confusion by all parties involved

<j​effro256:monero.social> I *do* want to

<r​brunner7:monero.social> I can agree in principle, but the short-handed-ness is maybe distributed quite unevenly in time and space

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

<r​brunner7:monero.social> (to ofrnxmr )

<o​frnxmr:monero.social> 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

<r​brunner7:monero.social> Oh, let's hope we don't descend into drama here :)

citation monero-project/research-lab #101#issue-1228028838

<r​brunner7:monero.social> 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

we where shorthanded then and people had to work on reimplementing his closed source work

<r​brunner7:monero.social> Asking them for a candidate list what they intend, or at least could imagine, to work on is reasonable

<r​brunner7:monero.social> Are those ++ bulletproofs the ones that did not go into production after all?

true, this was pre audits

<r​brunner7:monero.social> Which makes the whole story even worse I guess

<r​brunner7:monero.social> 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.

<r​brunner7:monero.social> Ok, let's see how that develops further.

<r​brunner7:monero.social> Anything else left to discuss today?

<r​ucknium:monero.social> 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.

<r​brunner7:monero.social> Just to be sure: Are we here in a place that you would count as a "dev channel"?

<j​effro256:monero.social> This isn't a MRL meeting though?

<r​brunner7:monero.social> I hope so :)

<r​brunner7:monero.social> 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.

<r​ucknium:monero.social> I am saying try to get as much discussion in this channel instead of bringing it to MRL Wednesday.

<r​ucknium:monero.social> Or start having meetings in #monero-dev:monero.social :)

<r​brunner7:monero.social> I think we can agree on that :)

<r​brunner7:monero.social> Ok, looks to me we are through for today. Thanks everybody for attending, read you again next week!

<s​pirobel:kernal.eu> thanks

<j​effro256:monero.social> Ah makes sense, ;)

<s​needlewoods_xmr:matrix.org> thanks everyone

<j​effro256:monero.social> Thanks everyone