<rbrunner7> Meeting in a bit more than 1 hour

Won't be able to make it to todays meeting, still stuck at work - SNeedlewoods

<rbrunner7> I hope they don't hold you hostage :)

<rbrunner7> Meeting time. Hello! monero-project/meta #1385

<jpk68:matrix.org> Hello

<jberman> waves

<koe000:matrix.org> Hi

<vtnerd> Hi

<rbrunner7> Alright, on to the reports about last week. Me: Made some more progress with Polyseed, and got a problem explained with Polyseed based background wallets that I will soon start to investigate

<koe000:matrix.org> Me: multisig wip, might have a PR this week or next if things go well

<jpk68:matrix.org> Made several random patches to the daemon and GUI; made more progress on I2P work (which I would consider to be mostly done). Just have to fix a few bugs/issues and then it

<rbrunner7> Cool, @koe000:matrix.org !

<jpk68:matrix.org> *and then it's time for testing :)

<koe000:matrix.org> The multisig stuff is on top of jeffro’s hotcold branch so merging will take a while.

<jberman> stressnet fun, fixed an RPC serialization issue reported and diagnosed by @redsh4de:matrix.org, moving towards looking into recently reported issues

<rbrunner7> Stressnet had a good start, from what I am reading in the room, right? Compared with all the bad things that could have happened :)

<jberman> I'd say so. The current bugs I think are either simple to solve or known/understood. There was a mega deep reorg over the weekend that caused issues and I think I know why, and am looking into it now

<rbrunner7> Mega deep? Hundreds of blocks or so?

<koe000:matrix.org> jberman: I think we need a timeline/plan for merging to the Monero repo, otherwise there will be a crunch/delays. eg carrot_core is just sitting and gtg afaik.

<jberman> 200 blocks I think

i'm currently trying to get our open PR list lower on the monero repo, if something is ready please ping me

smaller

will check carrot_core PR

<jberman> I figured the hot/cold wallet impl might have an impact on carrot_core too, which is nearing completion

<jberman> but actually looks like not

<koe000:matrix.org> Can make smaller follow-ups I imagine. The no-squashing rule means modified large prs are annoying to validate.

<jberman> I agree @koe000:matrix.org. On FCMP++ stuff, I've been thinking I would begin to set up the PR's for the follow-up phases, and tbh would love to have the architecture of those PR's reviewed before audits (e.g. of the tree building approach). I think that would be nice to avoid bad audit

<jberman> Beta is kind of getting a little in the way of things / makes it a little hard to make progress on review front, but I do generally think it would be good to get moving on upstream PR's sooner rather than later

<rbrunner7> What is the "no-squashing rule"? Something that you follow in the FCMP++ repo?

<jberman> I can discuss a more concrete plan for FCMP++ stuff, and when @jeffro256:monero.social is available I think it would be good for him to lay out a plan for Carrot

<koe000:matrix.org> rbrunner7: Monero repo merged PRs need one reviewed commit each. The maintainer can’t squash and the author can’t submit multiple commits.

it's not a strict rule but it depends, like fixup should be squashed

<rbrunner7> Maybe I misunderstood. You mean you have to squash to always arrive at a single commit per PR?

<jberman> I can shoot to have all the PR's for the FCMP++ integration opened within 2 weeks, we get architecture reviewed on those PR's within 2 weeks after that, then we have those PR's audited. That should cover the timeline for when we finish with Audit Phase 1. So within 4-6 weeks, I'd say we aim to get Phase 1 PR's merged as well

there are cases where multiple commits in a single PR can make sense if they build upon each other

<jberman> And Phases 2 & 3 PR's have architecture reviewed within that period as well

<jberman> Then Phases 2 & 3 audits, and PR's fully reviewed after each round of audits

<jberman> How does that sound?

<rbrunner7> Who is expected to do "architecure reviews"?

<rbrunner7> *architecture reviews

<koe000:matrix.org> Be sure to ping me if you want my review on something.

<jberman> koe jeffro vtnerd are good candidates I'd say

<jberman> very nice to have you back koe :D

<rbrunner7> Ah, I see, "our people", not externs mostly

carrot_core depends on multiple PRs that require an audit before merging

<jberman> good news is that audit has begun! :D

<jberman> estimated completion date of 2 weeks + corrections round

<rbrunner7> Nice.

<rbrunner7> Alright, looks like we got FCMP++ work covered. Something else to discuss today?

<jpk68:matrix.org> Would the I2P stuff be fine to mention here?

<rbrunner7> Think so, yes.

<jpk68:matrix.org> Great, thanks. If anyone is interested, it would be super useful to have some feedback on general implementation details, though it isn't urgent of course

<rbrunner7> Where can we see that, in order to get able to give you feedback?

<jpk68:matrix.org> In terms of how it's supposed to integrate into the daemon (like how SOCKS does), I am not super experienced with that, so others might have opinions on it

<jpk68:matrix.org> rbrunner7: The two PRs are currently mirrored on GH by ofrnxmr

<jpk68:matrix.org> #10523 and #10458

<ofrnxmr> monero-project/monero #10523

<jpk68:matrix.org> Comments can be left on GitHub or Matrix, and I will try to respond on Matrix

<rbrunner7> I get it that GitHub is out of reach for you personally?

<jpk68:matrix.org> Yes, it is right now, haha

<jpk68:matrix.org> I am still trying to get that solved

<rbrunner7> Ok, no problem, just good to know

I would like to gauge support for (finally) removing RPC payments. I resubmitted jeffro's removal PR from three years ago here: monero-project/monero #10578

<rbrunner7> Ok, let's see whether somebody comes around to comment. Probably not me, unfortunately, that's too far from my areas of knowledge ...

<jpk68:matrix.org> No problem, thanks anyways :)

<rbrunner7> Ah, yes, the daemon side is still there, right? Just the wallet code was removed until now.

Correct

<rbrunner7> Well, that gets a +1 from me. Unfortunate story that this feature did not get used, but it is like it is.

<ofrnxmr> Wasnt that program "primo" using it (but dead, i guess)

<rbrunner7> Yeah, gosts from the past still wandering around :)

<rbrunner7> Will leave a comment at the PR

<ofrnxmr> github.com/selene-kovri/primo

<rbrunner7> 7 years ago, oh my. I feel old.

<rbrunner7> Ok. Looks like we are through now. Thanks everybody for attending, read you again next week!

<jpk68:matrix.org> Copy-pasted from the stressnet channel: is there any particular reason the fcmp_pp_rust library doesn't use more aggresive optimizations?

<jpk68:matrix.org> I was able to reduce the size of the built library by 15 MiB by enabling LTO, stripping symbols, and settings codegen-units to 1

<jpk68:matrix.org> It does look like LTO was explicitly set to 'off', so maybe that one's there for a reason

<jberman> @kayabanerve:matrix.org would have best insight there

<jpk68:matrix.org> I could also be completely wrong/misled here (I have very little Rust experience), but it seems that the crate's build settings are such that it can't compile without std, which should ostensibly be possible considering that the std-shims crate exists for that purpose

<kayabanerve:matrix.org> @jpk68:matrix.org: I have no idea about this and would ask for a citation. This sounds like we're discussing how Monero, the node, builds it which presumably isn't in my territory.

<kayabanerve:matrix.org> @jpk68:matrix.org: If you're referring to fcmp_pp_rust, you probably shouldn't be trying to publicly consume that and should use the Rust libraries it consumes directly.

<jpk68:matrix.org> @kayabanerve:matrix.org: What I'm talking about is the fact that the Cargo.toml file doesn't set lto = true in release mode.

<jpk68:matrix.org> @kayabanerve:matrix.org: I understand that; my point was just that if you wanted to build the Monero codebase in an environment where std was not available, or wanted to benefit from the potential size/speed gains of not using it (contrived scenario, I know), then that option might be useful. You would know better than me though, of course :)

<jberman> took me some time, but found the OG commit: j-berman/monero 5417919

<jpk68:matrix.org> Thanks. I take it there's some reason not to use LTO?

<jpk68:matrix.org> If not (and if you're fine with it), I can submit a PR adding some optimization settings to the release profile

<jpk68:matrix.org> Oh, nevermind, I didn't read the commit title

<jpk68:matrix.org> Looks like 1.2 MiB can still be shaved off even without LTO...