16:55:38 <br-m> <rbrunner7> Meeting in a bit more than 1 hour
17:15:31 <Guest68> Won't be able to make it to todays meeting, still stuck at work - SNeedlewoods
17:32:57 <br-m> <rbrunner7> I hope they don't hold you hostage :)
18:00:02 <br-m> <rbrunner7> Meeting time. Hello! https://github.com/monero-project/meta/issues/1385
18:00:08 <br-m> <jpk68:matrix.org> Hello
18:00:16 <br-m> <jberman> waves
18:00:50 <br-m> <koe000:matrix.org> Hi
18:01:15 <br-m> <vtnerd> Hi
18:02:27 <br-m> <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
18:03:23 <br-m> <koe000:matrix.org> Me: multisig wip, might have a PR this week or next if things go well
18:03:42 <br-m> <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
18:03:57 <br-m> <rbrunner7> Cool, @koe000:matrix.org !
18:03:59 <br-m> <jpk68:matrix.org> *and then it's time for testing :)
18:04:35 <br-m> <koe000:matrix.org> The multisig stuff is on top of jeffro’s hotcold branch so merging will take a while.
18:04:47 <br-m> <jberman> stressnet fun, fixed an RPC serialization issue reported and diagnosed by @redsh4de:matrix.org, moving towards looking into recently reported issues
18:05:19 <br-m> <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 :)
18:06:20 <br-m> <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
18:06:44 <br-m> <rbrunner7> Mega deep? Hundreds of blocks or so?
18:06:53 <br-m> <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.
18:06:55 <br-m> <jberman> 200 blocks I think
18:07:49 <selsta> i'm currently trying to get our open PR list lower on the monero repo, if something is ready please ping me
18:08:04 <selsta> smaller
18:08:35 <selsta> will check carrot_core PR
18:08:45 <br-m> <jberman> I figured the hot/cold wallet impl might have an impact on carrot_core too, which is nearing completion 
18:09:08 <br-m> <jberman> but actually looks like not
18:09:56 <br-m> <koe000:matrix.org> Can make smaller follow-ups I imagine. The no-squashing rule means modified large prs are annoying to validate.
18:10:40 <br-m> <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
18:11:43 <br-m> <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
18:11:58 <br-m> <rbrunner7> What is the "no-squashing rule"? Something that you follow in the FCMP++ repo?
18:12:04 <br-m> <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
18:12:46 <br-m> <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.
18:14:23 <selsta> it's not a strict rule but it depends, like fixup should be squashed
18:14:28 <br-m> <rbrunner7> Maybe I misunderstood. You mean you have to squash to always arrive at a single commit per PR?
18:14:29 <br-m> <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
18:14:54 <selsta> there are cases where multiple commits in a single PR can make sense if they build upon each other
18:15:02 <br-m> <jberman> And Phases 2 & 3 PR's have architecture reviewed within that period as well
18:15:41 <br-m> <jberman> Then Phases 2 & 3 audits, and PR's fully reviewed after each round of audits
18:15:57 <br-m> <jberman> How does that sound?
18:16:47 <br-m> <rbrunner7> Who is expected to do "architecure reviews"?
18:16:57 <br-m> <rbrunner7> *architecture reviews
18:16:57 <br-m> <koe000:matrix.org> Be sure to ping me if you want my review on something.
18:18:06 <br-m> <jberman> koe jeffro vtnerd are good candidates I'd say
18:18:16 <br-m> <jberman> very nice to have you back koe :D
18:18:26 <br-m> <rbrunner7> Ah, I see, "our people", not externs mostly
18:19:11 <selsta> carrot_core depends on multiple PRs that require an audit before merging
18:19:51 <br-m> <jberman> good news is that audit has begun! :D
18:20:14 <br-m> <jberman> estimated completion date of 2 weeks + corrections round
18:21:01 <br-m> <rbrunner7> Nice.
18:22:13 <br-m> <rbrunner7> Alright, looks like we got FCMP++ work covered. Something else to discuss today?
18:22:57 <br-m> <jpk68:matrix.org> Would the I2P stuff be fine to mention here?
18:23:09 <br-m> <rbrunner7> Think so, yes.
18:24:09 <br-m> <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
18:24:37 <br-m> <rbrunner7> Where can we see that, in order to get able to give you feedback?
18:24:57 <br-m> <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
18:25:12 <br-m> <jpk68:matrix.org> rbrunner7: The two PRs are currently mirrored on GH by ofrnxmr
18:25:17 <br-m> <jpk68:matrix.org> #10523 and #10458
18:25:33 <br-m> <ofrnxmr> https://github.com/monero-project/monero/pull/10523
18:25:39 <br-m> <jpk68:matrix.org> Comments can be left on GitHub or Matrix, and I will try to respond on Matrix
18:25:59 <br-m> <rbrunner7> I get it that GitHub is out of reach for you personally?
18:26:23 <br-m> <jpk68:matrix.org> Yes, it is right now, haha
18:26:27 <br-m> <jpk68:matrix.org> I am still trying to get that solved
18:26:32 <br-m> <rbrunner7> Ok, no problem, just good to know
18:27:16 <tobtoht> I would like to gauge support for (finally) removing RPC payments. I resubmitted jeffro's removal PR from three years ago here: https://github.com/monero-project/monero/pull/10578
18:27:27 <br-m> <rbrunner7> Ok, let's see whether somebody comes around to comment. Probably not me, unfortunately, that's too far from my areas of knowledge ...
18:27:40 <br-m> <jpk68:matrix.org> No problem, thanks anyways :)
18:28:13 <br-m> <rbrunner7> Ah, yes, the daemon side is still there, right? Just the wallet code was removed until now.
18:28:22 <tobtoht> Correct
18:29:29 <br-m> <rbrunner7> Well, that gets a +1 from me. Unfortunate story that this feature did not get used, but it is like it is.
18:30:06 <br-m> <ofrnxmr> Wasnt that program "primo" using it (but dead, i guess)
18:30:32 <br-m> <rbrunner7> Yeah, gosts from the past still wandering around :)
18:31:19 <br-m> <rbrunner7> Will leave a comment at the PR
18:31:36 <br-m> <ofrnxmr> https://github.com/selene-kovri/primo
18:32:09 <br-m> <rbrunner7> 7 years ago, oh my. I feel old.
18:33:19 <br-m> <rbrunner7> Ok. Looks like we are through now. Thanks everybody for attending, read you again next week!
21:40:56 <br-m> <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?
21:41:03 <br-m> <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
21:43:29 <br-m> <jpk68:matrix.org> It does look like LTO was explicitly set to 'off', so maybe that one's there for a reason
21:51:36 <br-m> <jberman> @kayabanerve:matrix.org would have best insight there
21:57:34 <br-m> <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
22:04:47 <br-m> <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.
22:05:29 <br-m> <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.
22:21:17 <br-m> <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.
22:24:07 <br-m> <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 :)
23:06:38 <br-m> <jberman> took me some time, but found the OG commit: https://github.com/j-berman/monero/commit/5417919c136441ac30c3178881658c6decdbe33e
23:12:22 <br-m> <jpk68:matrix.org> Thanks. I take it there's some reason not to use LTO?
23:13:04 <br-m> <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
23:13:26 <br-m> <jpk68:matrix.org> Oh, nevermind, I didn't read the commit title
23:17:00 <br-m> <jpk68:matrix.org> Looks like 1.2 MiB can still be shaved off even without LTO...